Ontologies contextuelles

Une ontologie simple indique que Payment possède un amount. Une ontologie contextuelle enregistre aussi à qui appartient ce montant, dans quelles unités, depuis quel système, selon quelle norme et avec quel niveau de confiance. Le concept canonique reste ainsi fiable même lorsque de nombreuses sources l'alimentent sous des formes différentes.

Il s'agit d'une couche additive au-dessus des liaisons normales, et non d'une fonctionnalité séparée : le même type d'objet Payment, la même liaison silver_table, auxquels s'ajoutent le contexte, les transformations, les contrats, les ancres et les alias qui accompagnent chaque valeur projetée par la liaison.

Le problème résolu

Votre ontologie canonique contient un concept Payment. Dans le monde réel, plusieurs sources l'alimentent et chacune lui donne un sens légèrement différent :

Si vous aplatissez ces trois champs dans une seule colonne amount et supprimez le reste, chaque consommateur en aval travaille désormais avec des données ambiguës. « Affichez tous les paiements sortants supérieurs à 10 000 € comptabilisés en BE au dernier trimestre » renvoie une réponse différente selon le flux qui a écrit une ligne en dernier, sans que personne puisse expliquer pourquoi. Votre IA raisonne alors avec assurance sur des nombres qui n'ont pas le même sens.

Une ontologie contextuelle conserve le concept canonique et sa provenance. Les divergences sont donc enregistrées et explicables au lieu d'être silencieusement fondues dans un enregistrement de référence.

Quand l'utiliser

Utilisez une ontologie contextuelle si au moins une de ces conditions est vraie :

• Plusieurs sources alimentent le même concept. Deux rails de paiement, trois CRM après une acquisition, ou un ancien système exploité en parallèle de son remplaçant.
• Les mêmes données traversent plusieurs normes ou formats. ISO 20022 et ISO 8583, un CSV fournisseur, FpML et FIX, HL7 v2 et FHIR.
• Le sens change selon la direction ou le point de vue. « Counterparty », « Debtor » et « Obligor » désignent des parties différentes selon qu'une transaction est entrante ou sortante, ou selon le point de vue acheteur/vendeur.
• Vous opérez dans plusieurs juridictions. Les unités monétaires, les sémantiques de date et les libellés réglementaires diffèrent selon le pays, même pour un champ apparemment identique.
• La conformité ou l'IA doit expliquer une réponse. Si vous devez montrer quelle source et quel mapping ont produit une valeur — pour un auditeur, un régulateur ou une citation d'IA ancrée — vous avez besoin de cette provenance.
• Le vocabulaire local diffère du modèle canonique. Le « Party » de l'équipe KYC et celui de l'équipe paiements ne désignent pas nécessairement le même concept canonique ; le contexte les distingue.

Si chaque concept ne possède qu'une source unique et propre et que vous n'avez jamais à expliquer sa provenance, les liaisons simples suffisent. N'ajoutez pas cette couche sans besoin réel.

Ce qu'ajoute une ontologie contextuelle

Cinq éléments, tous facultatifs et additifs. Vous pouvez en adopter un sans utiliser les autres.

Lister et résoudre les alias avec le SDK d'ontologie

Utilisez @scrydon/ontology-sdk/client lorsqu'une application a besoin du répertoire d'alias publié et filtré selon l'habilitation, plutôt que des définitions d'authoring :

const directory = await ontology.aliases.list({
  ontology: "payments",
  objectType: "Party",
});

const result = await ontology.aliases.resolve({
  alias: "Debtor",
  context: {
    sourceSystem: "core_banking_x",
    standard: "ISO20022",
    messageType: "pacs.008",
    direction: "inbound",
    jurisdiction: "BE",
    businessProcess: "payments",
  },
});

list lit l'ontologie default lorsque ontology est omis. Un filtre property doit toujours être accompagné de son objectType parent. resolve recherche toutes les ontologies publiées visibles par l'appelant, sauf si vous en sélectionnez une ; un revisionId épinglé exige donc aussi ontology.

L'objet de contexte est strict : seules les six clés ci-dessus sont acceptées, chaque valeur est nettoyée et bornée, et toute clé inconnue échoue à la validation. La résolution renvoie tous les candidats applicables, classés selon la précision du contexte, la confiance, la provenance (manual, imported, puis ai_suggested) et une identité finale stable. Une confiance absente vaut 0 ; Scrydon ne choisit jamais silencieusement un candidat à votre place.

Comportement à la lecture

Le contexte voyage avec la liaison. Chaque lecture d'un concept contextuel renvoie donc l'objet typé et sa provenance :

{
  "id": "Payment:PMT-2025-0001",
  "properties": {
    "amount": 12345.56,
    "currency": "EUR",
    "direction": "outgoing",
  },
  "provenance": {
    "confidence": 0.96,
    "bindingContext": {
      "sourceSystem": "core_banking_x",
      "standard": "ISO20022",
      "messageType": "pacs.008",
      "jurisdiction": "BE",
    },
    "lossyProperties": ["amount", "settlementTimestamp"],
  },
}

Deux lignes Payment provenant de deux flux restent ainsi distinctes et explicables, au lieu de devenir deux nombres indifférenciés dans une seule colonne.

Essayer et construire