Contextual ontologies

A plain ontology says Payment has an amount. A contextual ontology also records whose amount, in what units, from which system, under which standard, with how much confidence — so the same canonical concept stays trustworthy even when a dozen different sources feed it in a dozen different shapes.

It is an additive layer on top of normal bindings, not a separate feature: the same Payment object type, the same silver_table binding — plus context, transforms, contracts, anchors, and aliases that travel with every value the binding projects.

The problem it solves

Your canonical ontology has one Payment concept. But the real world feeds it from many places, and each one means something subtly different:

If you flatten all three into one amount column and throw the rest away, every downstream consumer is now working with ambiguous data. "Show me all outgoing payments over €10 000 booked in BE last quarter" returns a different answer depending on which feed wrote a row last — and nobody can explain why. Your AI confidently reasons over numbers that don't mean the same thing.

A contextual ontology keeps the canonical concept and the provenance, so divergence is recorded and explainable rather than silently averaged into a golden record.

When you need it

Reach for a contextual ontology when any of these is true:

• More than one source feeds the same concept. Two payment rails, three CRMs after an acquisition, a legacy system running alongside its replacement.
• The same data crosses standards or formats. ISO 20022 vs ISO 8583 vs a vendor CSV; FpML vs FIX; HL7 v2 vs FHIR.
• Meaning flips with direction or perspective. "Counterparty", "Debtor", "Obligor" mean different parties on an inbound vs outbound transaction, or from the buy-side vs sell-side.
• You operate across jurisdictions. Currency minor units, date semantics, and regulatory labels differ by country even for "the same" field.
• Compliance or AI must explain an answer. If you have to show which source and mapping produced a number — for an auditor, a regulator, or a grounded AI citation — you need the provenance a contextual ontology records.
• A local team's vocabulary differs from the canonical model. The KYC team's "Party" and the payments team's "Party" are not the same canonical concept; context disambiguates them.

If you have a single, clean source per concept and never need to explain provenance, plain bindings are enough — don't add this layer just because you can.

What a contextual ontology adds

Five building blocks, all optional and additive. You can adopt one without the others.

How it shows up at read time

Because the context travels with the binding, every read of a contextual concept returns the typed object plus its 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"]
  }
}

Two Payment rows from two different feeds are now distinguishable and explainable, instead of two indistinguishable numbers in one column.

Try it / build it