Architecting Agent-Ready Metadata for Autonomous Systems

From Semantic Discovery to Schema-Level Enforcement (Part 1 of 2)

AI agents act on definitions immediately. In regulated financial workflows, metadata that only describes meaning is no longer sufficient. Meaning must be encoded formally, so that contradictions are caught by a reasoner before an agent acts, not by an auditor after it has.

Position in the Technical Blueprint for SimBI

This is the opening piece of the Technical Blueprint, a whitepaper published as a series in which each piece builds on the one before. It starts with metadata: what a governed concept is, in machine terms, and how far its constraints can be enforced. Identity follows: who and what acted on that meaning, covering the invocation, the agent, the dataset and the transformation. Suitability and appropriateness then build on both: whether the data is fit for the use an agent is putting it to, and whether the operation is fit for its purpose.

The metadata piece is published in two parts. This part covers formal meaning and its limits. The second part covers closed-world validation, definition versioning, runtime delivery to agents and a worked trading-book example, and closes with design requirements.

Executive Summary

Financial institutions are moving AI agents into credit, risk and reporting workflows. In those workflows, an ambiguous definition cannot be reconciled by an analyst when AI agents act on it instantaneously. Metadata designed for human search, such as labels, descriptions and catalog tags, leaves interpretation to the reader. Agent-ready metadata removes that latitude by encoding meaning in open W3C standards: SKOS for controlled vocabularies and the mappings between them, and OWL 2 for classes and the logical constraints that hold between them.

The effect of structure on agent accuracy is measurable, and it persists as models improve. In an enterprise insurance benchmark, GPT-4 answered 16.7% of business questions correctly when querying a SQL schema directly, and 54.2% when the same questions were posed over a knowledge-graph representation of the same data [18]. Adding a deterministic ontology check on generated queries, with LLM repair, raised accuracy to 72.55% [19]. In a 2026 rerun of an extract of the same benchmark, with every question inside a semantic layer’s modeled scope, Claude Sonnet 4.6 and GPT-5.3 Codex scored 98.2% and 100% through the semantic layer, against 90.0% and 84.1% with direct SQL generation [30].

This article sets out the formal mechanism using market risk as the worked example. FIBO, the industry reference ontology, does not define market risk. Section 3 shows how an institution extends FIBO to define it and anchors a risk metric to Release-level FIBO classes. Section 4 sets out what an OWL reasoner can enforce against agent outputs, and what it cannot. Section 5 reviews where the industry stands. The second part of this article turns from logical consistency to completeness, versioning and runtime delivery.

1. From Semantic Discovery to Schema-Level Enforcement

Operationalizing AI agents across credit scoring, risk monitoring and regulatory reporting changes what the metadata beneath those systems must do. Traditional metadata was designed for people. A data steward who reads the label “market risk” and its description can infer what is meant, check with a colleague, and resolve an ambiguity before it reaches a report. An agent has no such step, it acts on the context it is given. Frontier models can usually infer what a label means, but “usually” still adds room for error, context drift and hallucination make inference unreliable for high-risk decisions.

Agent-ready metadata is a persistent, machine-readable layer that fixes meaning across systems. A definition of market risk consumed by one agent must be interpreted identically by a different agent operating in a different system. Each agent must be able to retrieve the definition, its labels and its relationships in structured form, so that nothing is left to inference. The objective is semantic consistency, preventing small definitional inconsistencies from compounding into operational failures once agents act on them at scale.

Table 1 summarizes the difference between the two models.

Table 1: Comparative requirements for metadata architecture

Feature	Traditional metadata (human-centric)	Agent-ready metadata (machine-explicit)
Primary consumer	People, through catalog search and user interfaces	AI agents, through APIs and protocols such as the Model Context Protocol (MCP)
Contextual model	Implicit; meaning is inferred by the reader	Explicit; meaning is encoded in a formal vocabulary and ontology
Precision	General categorization and tagging	Typed classes, relationships and logical constraints
Ambiguity handling	Tolerates drift; people reconcile differences	Contradictions detected by a reasoner; gaps flagged by validation
Functional layer	Discovery and retrieval	Integrated suitability and appropriateness logic, is this data valid for this decision? (Blueprint Section 3)
Lineage persistence	Periodic snapshots	Continuous, versioned lineage records (Blueprint Section 2)

2. The Underlying Structure: SKOS and OWL 2

Agent-ready metadata does not require new standards. The W3C published the necessary ones more than a decade ago, and the financial industry already maintains a reference ontology built on them.

• SKOS (Simple Knowledge Organization System) is an RDF vocabulary for concept schemes: taxonomies, thesauri and controlled vocabularies. It records preferred labels, definitions, hierarchy (skos:broader, skos:narrower) and mappings between schemes [20].
• OWL 2 (Web Ontology Language) is a formal ontology language. It defines classes, properties and logical constraints, such as disjointness, that a reasoner can check automatically [21].
• FIBO (Financial Industry Business Ontology) is maintained by the EDM Council with the Object Management Group and expressed in OWL. It supplies the shared financial vocabulary [1].

The two standards do different jobs. SKOS governs the vocabulary, defining what a term means, where it sits in a taxonomy, and how one business unit’s term relates to another’s. OWL governs the logic, mapping which statements about real-world things can and cannot be true together. Keeping the layers distinct avoids a common error when a taxonomy is converted into an ontology, whereby every taxonomy entry is turned into a class and every broader-narrower link into a subclass axiom. A risk taxonomy will typically file “value at risk” under “market risk”, because that is where a reader would look for it. As a subclass axiom, the same link asserts that every value-at-risk figure is a market risk, which is false. A value at risk figure is a measure of market risk, not a kind of it. A reasoner would then draw inferences from that axiom without any means of detecting that it is wrong. SKOS broader and narrower links record where a concept is filed, not what kind of thing it is, and Section 3.1 keeps the two apart.

2.1 The vocabulary layer

Market risk is a useful example because its meaning varies across an institution. Trading, treasury and finance all use the term, and each may measure and derive it differently. That divergence can be legitimate depending on the scope, but divergence that is invisible to an agent is not.

In SKOS, an enterprise risk taxonomy defines market risk as a concept within a concept scheme. The definition below is taken verbatim from the Basel Framework (MAR11.1), with the regulator cited as its source [22]:

ent:RiskTaxonomy a skos:ConceptScheme ;
    skos:prefLabel "Enterprise Risk Taxonomy"@en .

ent:MarketRisk a skos:Concept ;
    skos:inScheme   ent:RiskTaxonomy ;
    skos:prefLabel  "Market Risk"@en ;
    skos:definition "The risk of losses arising from movements in market prices."@en ;
    dct:bibliographicCitation "BCBS, Basel Framework, MAR11.1"@en ;
    skos:broader    ent:FinancialRisk ;
    skos:narrower   ent:InterestRateRisk , ent:FXRisk , ent:EquityRisk , ent:CommodityRisk ;
    skos:related    ent:CreditRisk .

2.2 Mapping legitimate divergence

Where business units define market risk differently, each maintains its own concept scheme and maps its concept to the enterprise concept with a SKOS mapping property. skos:exactMatch declares two concepts interchangeable; skos:closeMatch declares them similar but not identical [20, §10]. An agent can then distinguish “same label, close meaning” from “same meaning”, rather than treating identical terminology as identical meaning.

treasury:MarketRisk a skos:Concept ;
    skos:inScheme   treasury:RiskTaxonomy ;
    skos:prefLabel  "Market Risk"@en ;
    skos:scopeNote  "Banking-book interest-rate and FX exposure only."@en ;
    skos:closeMatch ent:MarketRisk .

trading:MarketRisk a skos:Concept ;
    skos:inScheme   trading:RiskTaxonomy ;
    skos:prefLabel  "Market Risk"@en ;
    skos:exactMatch ent:MarketRisk .

This is consistent with supervisory expectations. BCBS 239 does not require a single data model, but requires robust automated reconciliation where several are in use [25, ¶33, fn 16]. Explicit mappings are that reconciliation, expressed in a form an agent can read.

3. Extending FIBO: Defining Market Risk and Anchoring a Risk Metric

FIBO does not define market risk. The current production release (version IRI 20261001, source as of 15 October 2026) contains no MarketRisk class and no general-purpose risk measure such as value-at-risk [24]. The nearest term, valueAtRisk, is a Provisional property in the collective investment vehicles ontology. It applies to fund investment restrictions and is expressed as a percentage, so it is not suitable for a portfolio-level risk metric.

This is by design rather than an omission. FIBO standardizes the things a risk calculation operates on: positions, instruments, rates and prices. The institution’s risk taxonomy and its metrics remain the institution’s to define. The design choice is to define them as an extension that imports FIBO and anchors to its Release-level classes, not as a parallel model that duplicates them.

The architecture does not prescribe the ontology. It consumes whatever the institution already governs: FIBO, internal risk and finance taxonomies, or definitions exposed by an existing data catalog. The extension below illustrates how an institution would define a concept that its reference ontology lacks. The controls in Sections 3.4 and 4 apply in the same way to any ontology supplied in this form.

Table 2: FIBO anchor classes used by the extension (all at Release maturity)

FIBO class	FIBO definition (verbatim)	Role in the extension
fibo-fbc-pas-fpas:Position	“financial exposure resulting from owning, borrowing, shorting, or entering into a contract (e.g., derivatives)”	The unit to which market risk is attributed
fibo-fbc-pas-fpas:FinancialExposure	“the extent to which an individual or organization is open to risk of suffering a loss in a transaction, or with respect to some investment or set of investments”	Parent of Position; FIBO’s own link to the notion of loss
fibo-fbc-fi-fi:FinancialInstrument	“written contract that gives rise to both a financial asset of one entity and a financial liability of another entity”	What a position is held in
fibo-fnd-acc-cur:InterestRate, ExchangeRate, Price	“amount charged, expressed as a percentage of principal…”; “rate at which one currency can be exchanged for another”; “amount of money, goods, or services … given in exchange for something else”	The observable market figures that risk factors track
fibo-fnd-oac-own:Portfolio	“collection of holdings assembled and maintained as a unit for management purposes to achieve strategic objectives”	The aggregation level for the metric

3.1 The extension

The extension is a separate, versioned ontology that imports the FIBO modules it depends on. In this example, it adds three things: market risk factors, book-level position classes, and a risk measure.

Each prefix abbreviates a full IRI, so that a term can be written as fibo-fbc-pas-fpas:Position rather than spelled out in full. The declarations below cover every example in this article: the W3C vocabularies, the three FIBO modules the extension builds on, the OMG Commons modules that FIBO itself uses for quantities and identifiers, and the institution’s own namespace, ent:.

@prefix owl:  <http://www.w3.org/2002/07/owl#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix xsd:  <http://www.w3.org/2001/XMLSchema#> .
@prefix fibo-fbc-pas-fpas: <https://spec.edmcouncil.org/fibo/ontology/FBC/ProductsAndServices/FinancialProductsAndServices/> .
@prefix fibo-fnd-acc-cur:  <https://spec.edmcouncil.org/fibo/ontology/FND/Accounting/CurrencyAmount/> .
@prefix fibo-fnd-oac-own:  <https://spec.edmcouncil.org/fibo/ontology/FND/OwnershipAndControl/Ownership/> .
@prefix cmns-qtu: <https://www.omg.org/spec/Commons/QuantitiesAndUnits/> .
@prefix cmns-id:  <https://www.omg.org/spec/Commons/Identifiers/> .
@prefix ent:      <https://example.com/ontology/risk/> .

Each FIBO namespace is also its ontology IRI: FIBO publishes every module under the same IRI as the namespace of its terms, so a prefix with nothing after the colon names the module itself and can be passed directly to owl:imports.

ent: a owl:Ontology ;
    owl:versionIRI <https://example.com/ontology/risk/2026-10/> ;
    owl:imports fibo-fbc-pas-fpas: , fibo-fnd-acc-cur: , fibo-fnd-oac-own: .

The import loads whichever FIBO release is current; importing a module’s version IRI instead pins the extension to a single release, which Part 2 returns to. With the ontology declared, the extension defines its market risk factors, book-level position classes and risk measure:

# Link from OWL classes to the SKOS vocabulary in Section 2
ent:riskType a owl:AnnotationProperty .

# 1. Market risk factors, anchored to FIBO market observables
ent:MarketRiskFactor a owl:Class ; ent:riskType ent:MarketRisk .
ent:tracks a owl:ObjectProperty ; rdfs:domain ent:MarketRiskFactor .

ent:InterestRateFactor rdfs:subClassOf ent:MarketRiskFactor ,
    [ a owl:Restriction ; owl:onProperty ent:tracks ;
      owl:someValuesFrom fibo-fnd-acc-cur:InterestRate ] .
ent:FXRateFactor rdfs:subClassOf ent:MarketRiskFactor ,
    [ a owl:Restriction ; owl:onProperty ent:tracks ;
      owl:someValuesFrom fibo-fnd-acc-cur:ExchangeRate ] .
ent:PriceFactor rdfs:subClassOf ent:MarketRiskFactor ,
    [ a owl:Restriction ; owl:onProperty ent:tracks ;
      owl:someValuesFrom fibo-fnd-acc-cur:Price ] .

# 2. Book-level positions, specializing FIBO Position
ent:TradingBookPosition rdfs:subClassOf fibo-fbc-pas-fpas:Position .
ent:BankingBookPosition rdfs:subClassOf fibo-fbc-pas-fpas:Position .
ent:TradingBookPosition owl:disjointWith ent:BankingBookPosition .

# Each transaction gives rise to at most one booked position
ent:arisesFrom a owl:ObjectProperty , owl:InverseFunctionalProperty ;
    rdfs:domain fibo-fbc-pas-fpas:Position .

ent:sensitiveTo a owl:ObjectProperty ;
    rdfs:domain fibo-fbc-pas-fpas:Position ;
    rdfs:range  ent:MarketRiskFactor .
ent:includesPosition a owl:ObjectProperty ;
    rdfs:domain fibo-fnd-oac-own:Portfolio ;
    rdfs:range  fibo-fbc-pas-fpas:Position .

# 3. The risk measure, as a FIBO-compatible quantity value
ent:RiskMeasure rdfs:subClassOf cmns-qtu:ScalarQuantityValue .
ent:ValueAtRisk rdfs:subClassOf ent:RiskMeasure ; ent:riskType ent:MarketRisk .

ent:measures a owl:ObjectProperty ;
    rdfs:domain ent:RiskMeasure ; rdfs:range fibo-fnd-oac-own:Portfolio .
ent:confidenceLevel a owl:DatatypeProperty ;
    rdfs:domain ent:ValueAtRisk ; rdfs:range xsd:decimal .
ent:horizonDays a owl:DatatypeProperty ;
    rdfs:domain ent:ValueAtRisk ; rdfs:range xsd:positiveInteger .

ent:riskType is an annotation property. It connects the OWL classes to the SKOS concept from Section 2 without turning that concept into a class, which keeps the ontology within OWL 2 DL and therefore decidable by a standard reasoner.

3.2 How the metric is resolved

Consider an agent asked to report a one-day, 99% value-at-risk for a trading portfolio against an internal limit. Every step of its resolution is a declared class or property:

• The portfolio is a fibo-fnd-oac-own:Portfolio. Its scope is the set of positions linked by ent:includesPosition, each typed as ent:TradingBookPosition.
• Each position is linked by ent:sensitiveTo to the market risk factors that move its value.
• Each factor ent:tracks a FIBO InterestRate, ExchangeRate or Price.
• The result is an ent:ValueAtRisk individual that ent:measures the portfolio, with ent:confidenceLevel 0.99 and ent:horizonDays 1, classified under ent:MarketRisk.

The agent does not infer which positions are in scope, which observable factors drive them, or what “value-at-risk” means. The calculation itself, whether historical simulation or a parametric model, remains in the risk engine. The ontology governs the inputs, the scope and the meaning of the output, which is the part an agent would otherwise have to guess.

3.3 Maturity gating

FIBO marks each ontology as Release, Provisional or Informative. Release ontologies are those “considered to be stable and mature from a development perspective”; Provisional ontologies are “under development” [1]. The extension anchors only to Release classes, and agents should be permitted to assert only against Release classes and approved extension classes. The Provisional valueAtRisk property illustrates the point: it is close in name to what is needed, but it is neither stable nor fit for this purpose. Provisional content can be offered to an agent as context. It should not be a basis for assertions that drive decisions.

3.4 Serialisation: JSON-LD and schema validation

Agents and the systems around them exchange JSON, not Turtle. JSON-LD lets an ordinary JSON payload carry its meaning, the @context maps each key to an IRI in the governed ontology, so the same document is both a JSON object an existing system can parse and an RDF graph a reasoner can check [26]. The value-at-risk result from Section 3.2, as an agent would emit it:

{
  "@context": "https://example.com/ontology/risk/2026-10/context.jsonld",
  "@id": "ent:VaR-20261027-TB-EQ-01",
  "@type": "ent:ValueAtRisk",
  "measures": "ent:Portfolio-TB-EQ-01",
  "confidenceLevel": "0.99",
  "horizonDays": "1"
}

The context is referenced by a versioned IRI, not embedded or left floating. For example, it states that measures is ent:measures with an IRI value and that confidenceLevel is an xsd:decimal. Pinning the context matters as much as pinning the ontology because the same keys under a different context mean something different.

This gives three levels of check, each suited to a different layer of an existing estate:

1. JSON Schema or XSD at the interface [27]: structure, required keys, datatypes and permitted values. Most API and integration layers already validate JSON payloads this way, and institutions exchanging ISO 20022 messages validate them against the published XSDs. EMIR Refit trade reports, submitted in ISO 20022 XML since 29 April 2024, are a live example: they carry transaction (UTI), instrument (ISIN or UPI) and counterparty (LEI) identifiers [29]. This layer plugs into what institutions run today.
2. SHACL on the expanded graph: constraints against the ontology that a payload-level schema cannot express, for example, that a risk type is drawn from the governed concept scheme rather than an ungoverned label (part 2 of this blueprint section).
3. OWL reasoning on the graph: logical consistency with the ontology’s axioms (Section 4, below).

JSON Schema validates keys and shapes, but it does not validate meaning. This is where pinning the context comes in, because a payload can satisfy its JSON Schema and still mean something different if it is bound to a different context. For that reason the JSON Schema and the SHACL shapes should be derived from the same governed definition and versioned with it, so that the interface check and the semantic check cannot drift apart.

4. What the Reasoner Enforces, and What It Does Not

A reasoner rejects any assertion that contradicts what the ontology already states. Two examples show how. The first concerns trade data, and the second returns to the risk metrics defined in Section 3.

Example 1: Counterparty Name Mismatch

A derivative transaction carries a Unique Transaction Identifier (UTI), a single reference that stays with the trade for its life so that every party and regulator identifies it the same way. FIBO models the UTI as a trade identifier, adapting its definition from ISO 23897 and the CPMI-IOSCO technical guidance [24][28].

The first example has three elements. The first is an interest-rate swap, ent:Txn-A001, and the fictitious UTI that identifies it. The second is the counterparty the swap is booked against, ABC Bank plc, identified by the LEI on the trade confirmation. GLEIF reference data maps each LEI to exactly one legal entity and its registered name. The third is an agent’s proposal, made while assessing the bank’s exposure to the ABC group, that the counterparty is ABC Bank AG, a different group entity with a similar name.

# The transaction, identified by its UTI (fictitious value)
ent:UTI-A001 a fibo-fbc-pas-fpas:UniqueTransactionIdentifier ;
    rdfs:label "EXAMPLE0000000000000SWAP20261027A001" ;
    cmns-id:identifies ent:Txn-A001 .

# Enterprise axioms: a bilateral trade has one counterparty,
# and a legal entity has one LEI
ent:hasCounterparty a owl:ObjectProperty , owl:FunctionalProperty .
ent:hasLEI a owl:ObjectProperty , owl:FunctionalProperty .

# GLEIF reference data: each LEI maps to one registered name (fictitious values)
ent:ABCBank-plc rdfs:label "ABC Bank plc" ; ent:hasLEI ent:LEI-001 .
ent:ABCBank-AG  rdfs:label "ABC Bank AG"  ; ent:hasLEI ent:LEI-002 .
[ a owl:AllDifferent ; owl:distinctMembers ( ent:LEI-001 ent:LEI-002 ) ] .

# Booked counterparty, resolved from the LEI on the trade confirmation
ent:Txn-A001 ent:hasCounterparty ent:ABCBank-plc .

# Assertion proposed by an agent that matched the name "ABC Bank"
ent:Txn-A001 ent:hasCounterparty ent:ABCBank-AG .

Because ent:hasCounterparty is functional, meaning it can take only one value for a given trade, the reasoner infers that ent:ABCBank-plc and ent:ABCBank-AG are the same entity. Because ent:hasLEI is also functional, that one entity would have to hold a single LEI, so ent:LEI-001 and ent:LEI-002 would be the same code. The GLEIF reference data says they are different, so the ontology with the proposed assertion is inconsistent. An OWL 2 DL reasoner detects this deterministically.

The agent matched on the name, which group entities often share apart from their legal form, while the LEI is what identifies the entity. The reasoner exposes the mismatch between the name the agent matched and the LEI on the trade. Without the reference data stating that the two LEIs differ, the reasoner would merge the two entities silently, as Section 4.1 explains.

Example 2: Risk Metric Classification

The second example returns to the risk metrics. The extension treats value at risk as a market risk measure, and the enterprise keeps market and credit risk measures apart. A risk report column headed “CVaR” can mean conditional value at risk, a market risk measure, or credit value at risk. An agent that reads it the second way asserts a credit classification for a figure the risk engine published as market risk, for the portfolio from Section 3.2.

# Enterprise axioms: market and credit risk measures are disjoint
ent:MarketRiskMeasure rdfs:subClassOf ent:RiskMeasure .
ent:CreditRiskMeasure rdfs:subClassOf ent:RiskMeasure .
ent:MarketRiskMeasure owl:disjointWith ent:CreditRiskMeasure .
ent:ValueAtRisk rdfs:subClassOf ent:MarketRiskMeasure .
ent:ConditionalValueAtRisk rdfs:subClassOf ent:MarketRiskMeasure .

# The figure as the risk engine published it
ent:CVaR-20261027-TB-EQ-01 a ent:ConditionalValueAtRisk ;
    ent:measures ent:Portfolio-TB-EQ-01 ;
    rdfs:label "CVaR" .

# Assertion proposed by an agent that read "CVaR" as credit value at risk
ent:CVaR-20261027-TB-EQ-01 a ent:CreditRiskMeasure .

Conditional value at risk is a market risk measure, and no figure can be both a market and a credit risk measure, so the reasoner rejects the assertion.

The important point is where the knowledge sits. The agent is not relied upon to know that two group entities are distinct, or that a measure cannot be both market and credit risk. The ontology states it, and the reasoner enforces its consequences. OWL reasoners use only the disjointness and distinctness that have been stated explicitly [21], so the constraints must be modelled and cannot be assumed. Both examples reject an assertion that contradicts the ontology. A risk figure that contradicts nothing but is incomplete is a different matter, and is discussed in the next section.

4.1 The open-world limit

OWL reasoning operates under the open-world assumption, under which a fact that is not stated is unknown, not false [21, §2]. This has three practical consequences for validating agent outputs.

• Domain and range axioms produce inferences, not errors. If an agent states that a value-at-risk figure ent:measures something not declared as a portfolio, the reasoner infers that it is a portfolio. It raises an inconsistency only if that inference conflicts with another stated axiom, such as a disjointness. Whether the referenced portfolio exists, and is what the payload claims, is resolved further down the pipeline against the systems of record, not by the metadata layer.
• Missing values are not violations. A value-at-risk figure with no confidence level, no horizon, no owner and no definition version is logically consistent. The missing facts are simply unknown.
• There is no unique-name assumption. Two differently named values for a property restricted to a single value are inferred to be the same individual rather than reported as a violation, unless they are explicitly declared different.

An OWL reasoner therefore catches assertions that are logically impossible. It does not catch assertions that are incomplete or malformed, and in a regulated workflow those are the more common failure. JSON Schema closes part of the gap at the interface by rejecting a payload with no confidence level. It cannot establish that the payload’s keys carry the meanings the ontology assigns, or that its values are drawn from governed concepts. Closing the rest of the gap requires closed-world validation of the expanded graph with the W3C Shapes Constraint Language (SHACL), which Part 2 sets out.

4.2 Design scenarios

The examples in this section translate directly into test scenarios for the metadata layer. Each identifies the check that should catch it and the expected outcome. They are design-stage scenarios, not results from a production system. A metadata check is an input to the decision, not the decision itself, so the outcomes are those the decision layer returns. It returns INDETERMINATE when a mandatory input is missing or cannot be interpreted, DENY when a fully interpreted input breaks a rule, and ESCALATE when a human must approve before anything executes.

Table 3: Design scenarios for the metadata layer

Scenario	Check that catches it	Expected outcome
Value-at-risk result with pinned context and ontology versions, using Release-level classes only	Passes every layer	Accepted for evaluation
Value-at-risk payload with no confidence level	JSON Schema	Cannot be evaluated (INDETERMINATE)
Risk type supplied as a free-text label rather than a governed concept	SHACL	Cannot be evaluated (INDETERMINATE)
Agent resolves a trade’s counterparty to the wrong group entity (similar name, different LEI)	OWL reasoner (functional property, distinct entities)	Rejected (DENY)
Agent classifies a market risk figure labelled “CVaR” as a credit risk measure	OWL reasoner (disjointness)	Rejected (DENY)
Agent proposes moving a transaction between books	Change control [23, RBC25.14–25.16]	Escalated for approval (ESCALATE)

5. State of Practice

The components of agent-ready metadata are already in use, including shared ontologies, executable definitions, governed semantic layers, and metadata delivered to agents. Though, they are rarely assembled together. The initiatives below fall into four groups, each of which addresses part of the problem.

5.1 Industry ontologies and executable standards

FIBO (EDM Council):

FIBO is the reference vocabulary for finance, and the EDM Council notes that AI is driving renewed interest in it [1]. Most institutions use FIBO as a reference model to which internal definitions are mapped, rather than as a runtime store that agents query directly. Named, end-to-end production case studies are not well cited.

ISDA Common Domain Model (CDM) and Digital Regulatory Reporting (DRR):

This is the closest existing example of a definition applied identically by independent systems. The CDM, now hosted by FINOS as an open standard, is a machine-readable and machine-executable model of how trades are represented and managed across their lifecycle. DRR encodes the reporting rules themselves as executable code on top of the CDM, so that firms share one interpretation of a rule rather than each translating the prose [2]. JPMorganChase has stated that its derivatives business uses the CDM and DRR for regulatory reporting [3], and Natixis CIB announced its adoption of DRR in April 2026 [4]. In a FINOS industry report, one bank reported a 100% trade-repository acknowledgement rate under MAS rules, and another reported 98.2% under EMIR Refit, after implementing DRR [5].

Legend (Goldman Sachs):

Goldman Sachs open-sourced its internal data modelling and governance platform through FINOS in 2020. Before release, Deutsche Bank, Morgan Stanley and RBC Capital Markets used a shared instance to prototype collaborative modelling to extend the CDM [6]. Competing banks have agreed on shared, machine-readable definitions where the incentive was strong enough.

5.2 Regulators standardizing machine-readable data

United States: Financial Data Transparency Act (FDTA):

The joint data standards final rule was published in the Federal Register on 25 June 2026 and took effect on 1 October 2026 [7]. It establishes common identifiers, with the Legal Entity Identifier (LEI) as the entity standard, and principles-based requirements for machine-readable schemas and taxonomies. It does not change any reporting requirement by itself; each agency applies the standards to its own collections through later action [7][8].

European Union: BIRD and IReF:

The ECB’s Banks’ Integrated Reporting Dictionary (BIRD) defines a common data dictionary, data model and transformation rules for producing regulatory reports. It is voluntary, but it underpins the Integrated Reporting Framework (IReF), which the ECB Governing Council moved into implementation in April 2026 [9]. A public consultation is expected in 2027, and first IReF reporting is not expected before the early 2030s [9][10].

Identifiers and taxonomies are becoming machine-readable by mandate. Regulators have not yet specified how an AI agent should consume them, or how it should be held to them.

5.3 Platforms delivering semantics to agents

Microsoft Fabric IQ:

Fabric IQ adds an ontology of business entities, relationships and rules on top of Fabric data, and can expose that ontology to external agents as an MCP server [11][12]. The ontology capability is in preview, and its rules are expressed in natural language rather than as formal axioms.

Palantir Ontology:

Palantir pairs semantic objects with governed actions and security policies, so that an agent can change state only through an action that carries its own permissions and validation [13]. Semantics and enforcement sit in the same layer, but the ontology is proprietary to the platform.

Collibra and Atlan:

Both catalog vendors provide MCP servers that expose glossaries, lineage, classifications and data contracts as tools an agent can call [14][15]. The content is largely descriptive: it tells the agent what a term means, but it does not prevent the agent from asserting something logically inconsistent.

Open Semantic Interchange (Apache Ossie):

Launched by Snowflake in September 2025 with Salesforce, dbt Labs, BlackRock, RelationalAI and others, OSI is an open, vendor-neutral format for exchanging semantic-model and metric definitions between tools [16]. An initial specification was published in January 2026, and the project entered the Apache Incubator as Apache Ossie in July 2026 [17]. Its scope is portability of metric and semantic-model definitions, not formal ontological reasoning.

Table 4: Industry initiatives (as of October 2026)

Initiative	Type	What it gives agents	Status
FIBO (EDM Council / OMG)	Open OWL ontology	Shared, formal financial vocabulary with axioms	Mature, mostly used as a reference model
ISDA CDM + DRR (FINOS)	Executable open standard	Definitions and rules as code, applied identically across firms	In production for derivatives reporting
Legend (Goldman Sachs / FINOS)	Open modelling platform	Collaborative, governed data models	Open source since 2020
FDTA joint data standards (US)	Regulation	Mandated identifiers (including LEI) and machine-readable taxonomies	Effective 1 Oct 2026, agency rules to follow
BIRD / IReF (ECB)	Regulatory data model	Common dictionary and transformation rules	IReF in implementation, reporting early 2030s
Fabric IQ (Microsoft)	Platform ontology	Ontology exposed to agents via MCP	Ontology in preview
Ontology (Palantir)	Platform ontology	Objects plus permissioned actions	Generally available, proprietary
Collibra / Atlan MCP	Catalog integration	Glossary, lineage and contracts as agent tools	Available
OSI / Apache Ossie	Open interchange specification	Portable metric and semantic-model definitions	Apache Incubator

5.4 Evidence that structured meaning improves agent accuracy

The most cited result is the data.world benchmark built on an insurance-domain enterprise schema. GPT-4 answered business questions correctly 16.7% of the time when querying the SQL database directly, and 54.2% of the time when the same questions were posed over a knowledge-graph representation of that database [18]. A follow-up study added a deterministic ontology-based check on generated queries, with LLM repair, and raised accuracy to 72.55% [19].

dbt Labs has since rerun an 11-question extract of the same benchmark against its own semantic layer, attempting each question 20 times per model [30]. On the original, minimally modelled schema, direct text-to-SQL accuracy rose from 32.7% with GPT-4 in November 2023 to 64.5% with both Claude Sonnet 4.6 and GPT-5.3 Codex in March 2026. The semantic layer rose from 60.5% to 72.7%. That figure is an effect of scope. In 2026 the semantic layer answered every question it could express correctly, and none of the three that needed joins outside its model. After dbt added three models so that all eleven questions fell within scope, the semantic layer scored 98.2% (Claude Sonnet 4.6) and 100% (GPT-5.3 Codex), against 90.0% and 84.1% for direct SQL generation. An August 2026 checkpoint with newer models, each at its best reasoning-effort setting and five attempts per question, narrows the gap further, to 90.9% for direct SQL against 94.5% to 100% through the semantic layer [30].

Several caveats apply. Both benchmarks are small and single-domain. data.world built the original, and dbt is evaluating its own product, so neither is an independent test. The interventions also differ, since the original tested a knowledge graph queried with SPARQL and the rerun was with a semantic layer. The 2026 in-scope figures are not directly comparable with the 2023 results, because the schema changed between them. Read together, the results are directional evidence that explicit, governed meaning improves agent accuracy, and better models have narrowed that advantage without removing it.

5.5 The unassembled combination

Each group solves part of the problem:

• Standards bodies provide formal meaning (FIBO) and executable meaning (CDM and DRR), but in narrow domains and mostly outside agent runtimes.
• Regulators are mandating machine-readable identifiers and taxonomies, but not how agents consume them or are held to them.
• Platforms deliver semantics to agents, either as descriptive context (catalogs, OSI) or inside a proprietary ontology (Palantir, Fabric IQ).

No public material reviewed for this article combines all three properties that agent-ready metadata requires. These are an open, standards-based ontology, deterministic enforcement of its constraints against agent outputs at runtime, and a lineage record of which definition, at which version, governed each agent decision.

6. What Follows

This part has established formal meaning and its limits. The second part of Section 1 completes the metadata layer:

• Closed-world validation with SHACL: cardinality, closed shapes and severity-tiered validation reports that close the open-world gap in Section 4.1.
• Versioning of meaning: ontology version IRIs and FIBO maturity levels, so that an agent is bound to a specific definition version rather than to “latest”.
• Runtime delivery: exposing definitions as MCP resources and validation as MCP tools with schema-declared outputs.
• A worked example on the trading-book boundary: classification, evidence and reclassification under Basel RBC25.
• Design requirements for the metadata layer.

The next piece of the blueprint turns to identity. A validated definition is only half of an auditable decision. The other half is attribution, recording which invocation, which agent, acting under whose authority, relied on which definition version. Identity and delegation provide that link.

References

• [1] EDM Council, FIBO specification and development process, https://spec.edmcouncil.org/fibo/
• [2] ISDA, Common Domain Model (CDM), https://www.isda.org/isda-solutions-infohub/cdm/
• [3] JPMorganChase, “JPMorganChase implements revolutionary open source solution to transform regulatory reporting”, https://www.jpmorganchase.com/about/technology/blog/jpmc-launches-finos-open-source-solution
• [4] ISDA, “Natixis CIB Adopts ISDA’s Digital Regulatory Reporting Solution”, April 2026, https://www.isda.org/a/5T6iE/Natixis-CIB-Adopts-ISDA-Digital-Regulatory-Reporting-Solution.pdf
• [5] FINOS, “Industry Perspectives on the ISDA DRR”, November 2025, https://www.finos.org/hubfs/Projects%20+%20SIGs/CDM%20-%20Common%20Domain%20Model/ISDA%20+%20DRR%20White%20Paper/Industry-Perspectives-on-the-ISDA-DRR-Unlocking-Efficiency-Accuracy-and-Strategic-Value.pdf
• [6] Linux Foundation, “Goldman Sachs Open Sources its Data Modeling Platform through FINOS”, October 2020, https://www.linuxfoundation.org/press/press-release/goldman-sachs-open-sources-its-data-modeling-platform-through-finos
• [7] Federal Register, “Financial Data Transparency Act Joint Data Standards”, 25 June 2026 (91 FR 38246), https://www.federalregister.gov/documents/2026/06/25/2026-12787/financial-data-transparency-act-joint-data-standards
• [8] SEC, FDTA Joint Data Standards fact sheet, https://www.sec.gov/files/33-11420-fact-sheet.pdf
• [9] Deutsche Bundesbank, Integrated Reporting Framework (IReF), https://www.bundesbank.de/de/service/meldewesen/bankenstatistik/inte-grated-reporting-framework-iref-611262
• [10] Banque de France / ESCB, “IReF Status update July 2026”, https://www.banque-france.fr/system/files/2026-08/ESCB_Integrated_Reporting_Framework_IReF-Status_update_July-2026.pdf
• [11] Microsoft Learn, “What Is Ontology (Preview)?”, https://learn.microsoft.com/en-us/fabric/iq/ontology/overview
• [12] Microsoft Learn, “Agent Integration Options for Ontology (Preview)”, https://learn.microsoft.com/en-us/fabric/iq/ontology/concepts-agent-integration
• [13] Palantir, Foundry Architecture Center, https://www.palantir.com/docs/foundry/architecture-center/overview
• [14] Collibra, MCP Server, https://www.collibra.com/products/mcp-server
• [15] Atlan, “From Metadata to Meaningful Action: Atlan MCP”, https://blog.atlan.com/announcements/atlan-mcp-ai-metadata/
• [16] Salesforce, “The Agentic Future Demands an Open Semantic Layer”, https://www.salesforce.com/blog/agentic-future-demands-open-semantic-layer/
• [17] Salesforce, “Ending Semantic Drift”, https://www.salesforce.com/blog/ending-semantic-drift-unified-business-logic-foundation/
• [18] Sequeda, J., Allemang, D. and Jacob, B., “A Benchmark to Understand the Role of Knowledge Graphs on Large Language Model’s Accuracy for Question Answering on Enterprise SQL Databases”, 2023, arXiv:2311.07509, https://arxiv.org/abs/2311.07509
• [19] Allemang, D. and Sequeda, J., “Increasing the LLM Accuracy for Question Answering: Ontologies to the Rescue!”, 2024, arXiv:2405.11706, https://arxiv.org/abs/2405.11706
• [20] W3C, SKOS Simple Knowledge Organization System Reference, Recommendation, 18 August 2009, https://www.w3.org/TR/skos-reference/
• [21] W3C, OWL 2 Web Ontology Language Primer (Second Edition), Recommendation, 11 December 2012, https://www.w3.org/TR/owl2-primer/
• [22] BCBS, Basel Framework MAR11, Definitions and application of market risk, MAR11.1, https://www.bis.org/committees/bcbs/basel-framework/standard/mar/11/inforce/2023-01-01/published/2020-03-27
• [23] BCBS, Basel Framework RBC25, Boundary between the banking book and the trading book, https://www.bis.org/committees/bcbs/basel-framework/standard/rbc/25/inforce/2023-01-01/published/2020-03-27
• [24] EDM Council, FIBO ontology source, production version IRI 20261001 (repository commit 2d73435, 15 October 2026), https://github.com/edmcouncil/fibo
• [25] BCBS, Principles for effective risk data aggregation and risk reporting (BCBS 239), January 2013, https://www.bis.org/publ/bcbs239.pdf
• [26] W3C, JSON-LD 1.1: A JSON-based Serialization for Linked Data, Recommendation, 16 July 2020, https://www.w3.org/TR/json-ld11/
• [27] JSON Schema, Draft 2020-12, https://json-schema.org/draft/2020-12
• [28] CPMI-IOSCO, Harmonisation of the Unique Transaction Identifier: Technical Guidance, February 2017, https://www.bis.org/cpmi/publ/d158.pdf; ISO 23897:2020, Financial services: Unique transaction identifier (UTI)
• [29] REGIS-TR, EMIR Refit brochure, https://www.regis-tr.com/dam/downloads/emir/refit-brochure.pdf

---

Series: The Architecture of Governed AI Systems

1. Governance is the Precondition for Scalable AI Agents
2. Metadata for AI Agents vs Human Metadata
3. Identity for AI Systems: The Missing Layer of AI Governance
4. Data Lineage as the Trust Backbone of AI Systems
5. Semantic Layers: The Hidden Infrastructure Behind Scalable AI
6. AI Gateways: The Control Plane for Model Access
7. How to Evaluate AI Agents: Building a Governance Framework
8. AI Policy Engines: How to Operationalize AI Governance for Financial Institutions
9. Institutional Traceability: The Operating System of AI Governance