Interoperability Is an Architectural Choice, Not a Schema Project
Why the next decade of digital trust will be won in the architecture of capture, not in schema committees
[Update: While this article was in draft/edit stage I noticed that Paul published a wonderful post on the same topic. I’d encourage you to read that as well.]
Most digital transformation programmes still behave as if shared data models guarantee shared reality. If only we could get everyone onto the same schema, the argument goes, then systems will connect, processes will align and risk will magically decrease. Two decades of standards work, middleware spend and failed “golden record” projects suggest otherwise.
The problem is not a lack of schemas. The problem is that we chose the wrong place in the stack to fight for interoperability.
Data models are fragile. They are shaped by local regulation, institutional history, organisational politics and specific business processes. They age quickly and they fork under pressure. Every “canonical” model ends up surrounded by extensions, exceptions and implementation guides that contradict one another. The more we double down on models as the interoperability layer, the more we pay for mapping, reconciliation and manual remediation.
Architecture is different. Architecture is about how data is captured, constrained, contextualised, provenanced and committed before it starts moving. It is about the contracts enforced at the point of issuance, the overlays that carry semantics and the registries and assurance networks that make those commitments independently verifiable. Architectures can host multiple models. Models cannot compensate for a weak architecture.
The core claim of this essay is simple:
Interoperability does not live in schemas. It lives in capture architecture and the surrounding trust fabric.
Once you take that seriously, the usual agenda flips. Instead of chasing another round of schema harmonisation, you start investing in capture patterns, overlays, trust registries, assurance networks and first-person credentials. Instead of treating interoperability as an integration problem between databases, you treat it as a commitment problem between institutions, systems and agents.
This essay develops that argument in three moves.
First, it explains how we got stuck in schema thinking and why that approach is structurally incapable of delivering the kind of interoperability modern systems need. Second, it reframes interoperability as a commitment problem anchored in capture. Third, it sketches an architecture-first approach built on overlays, trust registries and assurance networks, and unpacks the political economy that comes with it.
By the end, the question is no longer “which schema should we standardise on,” but “what trust architecture do we want to build, who governs it and how do we make it operational across institutions, sectors and jurisdictions.”
1. How We Got Stuck: The Schema Harmonisation Delusion
1.1 The 20-year schema project
Across healthcare, finance, public administration, logistics and manufacturing, a familiar pattern has repeated for more than two decades.
A domain realises that its data is fragmented. Hospitals cannot exchange patient records reliably. Tax authorities cannot reconcile filings across agencies. Banks cannot see a unified view of risk across products. Logistics networks cannot see end-to-end flows. The diagnosis is framed as “lack of standardisation,” and the solution is almost always the same: design a canonical data model and force everything through it.
Working groups form. Expert committees meet for years. Draft schemas are published and republished as comments flow in from implementers, vendors and regulators. Over time, the “core” model accumulates optional fields, jurisdiction-specific extensions and versioned profiles. Parallel efforts sprout: one group handles clinical concepts, another billing, a third imaging or devices. The original promise of a single, shared view is replaced by a forest of related but incompatible variants.
On paper, this looks like progress. There are specifications, reference implementations and conformance statements. In practice, organisations continue to build local models that only loosely follow the canonical one. Integrations rely on hand-written mappings and brittle assumptions. Every new use case results in either a new profile or a creative misuse of an existing field.
This is not a failure of intelligence or sincerity. It is the natural outcome of trying to make a single model stand in for a constantly shifting, politically contested reality. Local practice will always outpace any central schema. Policy will always change faster than standards bodies can revise their documents. Incentives will always push implementers to bend the standard to fit their installed base rather than refactor systems to match the standard.
The result is a quiet form of institutional fatigue. Everyone knows the models do not really align. Everyone knows “standard-compliant” usually means “roughly mapped with caveats.” Yet projects continue to treat model harmonisation as the primary route to interoperability, because the alternatives are rarely articulated in a way that feels actionable.
1.2 The n² integration debt
Once data leaves its system of origin, every mismatch between models shows up as a mapping problem.
A field exists in one schema but not in another. The same field name carries different meanings across departments. Enumerations and code lists do not line up. Temporal assumptions differ. Derived fields lack clear lineage. Each mismatch becomes a small integration project.
Integration teams write transformation logic, set up ETL pipelines, maintain lookup tables and build monitoring dashboards. Individually, these mappings are tolerable. System A to System B is just another interface. System B to System C is another. Resources are allocated, timelines are padded and everyone hopes that after this round of integration, the landscape will stabilise.
It never does, because the combinatorics do not care about hopeful roadmaps.
As soon as there are more than a handful of systems, the number of pairwise relationships grows quadratically. Ten systems imply forty-five potential mappings. Adding one more system does not just add one integration; it adds a new row and column in the matrix. Any change in one system’s model ripples across all its links. The more local and fragile the models are, the more churn hits the network.
Vendors step into this chaos with middleware, “integration platforms” and prebuilt connectors. Some of this is genuinely useful, but none of it removes the structural reality that we are pouring effort into point-wise reconciliation of design decisions that were never aligned at the architectural layer. Every new product demo that promises “no-code integration” is, at its core, a promise to hide this reconciliation tax, not to remove its cause.
The internal costs are easy to observe:
Dedicated schema mapping teams who act as interpreters between business units.
Integration backlogs that never shrink because each new initiative adds more mappings than it retires.
“Golden record” projects that consume time and budget without ever delivering a stable, trusted source of truth.
The external costs are less visible but more corrosive:
Smaller players, especially in emerging markets, are locked out because they cannot afford the integration tax.
Large incumbents use proprietary data models and connector ecosystems as a subtle form of lock-in.
Innovation slows because new entrants must first untangle the existing model morass before they can offer differentiated services.
This n² integration debt is not an inevitable price of complexity. It is a consequence of the decision to place the interoperability burden on schemas and mappings instead of on capture architecture and verifiable context.
1.3 Why treating the model as the interoperability layer is a category error
The schema-first mindset rests on a seductive idea: if we can define a model that is rich enough and flexible enough, then everything else will follow. Systems will read each other’s data. Analytics will produce harmonised insights. Compliance reporting will be straightforward. Governance will have clear lines of sight.
The problem is that models are the wrong level of abstraction to carry that burden.
Models are:
Domain-specific. A healthcare model encodes clinical, operational and regulatory assumptions. A financial model encodes risk, capital and reporting logic. These are not easily merged.
Temporal. Models embed assumptions that were true when they were designed. As practice changes, those assumptions become outdated, yet the model remains frozen in production systems.
Institutional. Every large model is the fossil record of a negotiation between powerful actors. Choices about what is “core” versus “optional” are political decisions.
Architecture, by contrast, is concerned with how data moves through systems and how commitments are formed:
How is information captured.
What constraints and validations are applied at capture time.
How is provenance recorded.
How are semantics expressed and versioned.
How are commitments anchored so they can be verified later.
An architecture can host multiple models over time. It can allow different domains to project their own semantics onto a common capture substrate. It can accommodate policy change by evolving overlays instead of throwing away entire schemas. When interoperability is framed at the architectural level, models become clients of the architecture, not the architecture itself.
Confusing the two also hides a crucial distinction: syntax versus commitments.
Two systems might agree that a field called income is a decimal number with two places. That syntactic agreement does not tell us:
Whether the income is gross or net.
Which time period it refers to.
Whether it is self-declared or verified by a third party.
Which rules were applied in its calculation.
Whether it is valid for tax decisions, credit underwriting, welfare eligibility or internal reporting only.
All of those questions sit outside the model as typically documented. They live in policies, contracts, user interfaces, code and institutional memory. When those commitments are not captured and made portable at issuance, interoperability collapses into syntax-only alignment. That is not sufficient for high-stakes automation.
1.4 Markets built on schema fog
This is not just a technical nuisance. It has real economic and social consequences.
Markets clear based on information. Prices, risk, eligibility and access are functions of the data that flows through underwriting models, credit engines, risk frameworks and decision systems. If that data is captured under ambiguous semantics, without explicit provenance and without stable constraints, we are building markets on schema fog.
Consider a credit ecosystem where banks, fintechs and data aggregators all maintain their own income and employment models. On the surface, everyone uses similar terms. In reality, each institution attaches different semantics to those fields, uses different capture flows and applies different validation logic. One lender treats gig work as income with a haircut. Another ignores it entirely. A third recognises it only for certain professions and locations.
Now overlay this with regulators, auditors and rating agencies who expect system-wide views of risk. They receive aggregated metrics built on these heterogeneous models and are expected to assess stability. Every time numbers diverge or trends look odd, the response is to demand more detailed templates, more reporting schemas and more frequent submissions.
At no point does the ecosystem pause to ask whether the underlying capture architecture supports the kind of trust and comparability everyone assumes.
During benign periods, the system muddles through. Divergent semantics are papered over by conservative assumptions, manual overrides and local knowledge. During stress events, the mismatches surface, often brutally. Models misfire. Capital buffers are misjudged. Correction comes late and at high cost.
The same pattern appears anywhere entitlements, services or rights are mediated by data:
Welfare systems that cannot coordinate benefits across agencies because each uses different eligibility models.
Healthcare systems that cannot share patient histories effectively, leading to duplicated tests, missed signals and safety incidents.
Mobility and logistics networks that cannot reconcile tracking data, resulting in disputes, fines and inefficient routing.
The common thread is a reliance on model harmonisation as the primary path to interoperability. The hidden assumption is that if we can just align the schemas, everything else will follow. The evidence points the other way. As long as the architecture of capture, context and commitments is left implicit, schemas will diverge and the cost of reconciling them will compound.
Interoperability, in this light, is not a documentation problem. It is a structural problem about where in the stack we anchor trust.
2. Interoperability as Commitment, Not Format
2.1 Reframing the target
When organisations claim “our systems interoperate,” they usually mean “our systems can parse each other’s data.” That is a low bar. A system can accept a JSON payload, recognise the field names, store the values and still have no idea what commitments it can safely make based on that input.
Interoperability, in any meaningful sense, starts when a receiving system can make machine-actionable commitments. It needs answers to basic questions:
Who asserted this claim.
Under which rules and policies.
With what liability.
For which purpose and within which context.
On what basis and with what validation.
A field called employment_status might be encoded as an enumeration with values like full_time, part_time or contract. The schema can constrain the datatype and permitted values. It cannot say whether this status was declared by the person, confirmed by an employer, inferred from payroll data or imported from a government registry. It cannot say whether the status is valid for tax purposes, for benefits eligibility or only for internal HR reporting.
If a bank uses that field to underwrite credit, it is making a commitment: to price risk, assign limits and defend those decisions to regulators and courts. It cannot afford to discover later that the same employment_status value meant different things across product lines or data sources. Interoperability in this context means that the commitments made by the bank are aligned with the commitments embedded at capture, across time and across systems.
Once you see it that way, the key question stops being “can I read your message?” and becomes “can I rely on your commitments?” That is a different design problem. It moves attention from field names and datatypes to capture processes, provenance records, policy overlays and verifiable anchors. Formats remain necessary, but they are not the primary locus of trust.
2.2 The trust substrate: four layers
To reason clearly about interoperability as commitment, it helps to sketch a trust substrate that lives beneath models, APIs and applications. One useful way to think about it is in four layers.
Layer 0: Identity and cryptographic primitives.
This is where keys, identifiers and signatures live. Whether a system uses decentralised identifiers, certificates or other schemes, the essential function is the same. We need a way to bind statements to entities in a way that can be verified independently, without trusting every intermediary.
Layer 1: Capture architecture.
This is the heart of the matter. It decides:
What can be asserted.
How assertions are structured.
Which constraints and validations run at the point of capture.
How provenance is bound to each captured field or credential.
How semantics, policies and presentation are packaged into overlays, instead of being hard-wired into a monolithic schema.
Most systems today treat this as a side-effect of UI design and backend implementation. An architecture-first view treats it as a first-class concern.
Layer 2: Domain models and schemas.
This is where industry data models, taxonomies and reporting templates live. They provide shared vocabulary within sectors and make it easier to coordinate. They are valuable, but from an architectural standpoint they are clients of the capture substrate.
Layer 3: Applications, workflows and AI systems.
User interfaces, decision engines, orchestration logic, analytics pipelines and agents operate here. They read captured data, apply business logic and generate new actions. This layer is volatile because business needs, regulations and technologies evolve continuously.
If Layer 0 and Layer 1 are solid, the upper layers can be experimental and diverse without breaking trust. Different domains can evolve their own models. Different applications can interpret data through their own lenses. New AI systems can be introduced and retired without corrupting provenance. When Layer 1 is weak or implicit, every new model and application becomes a potential source of divergence that cannot be reconciled without heroic integration work.
Interoperability is effectively determined at Layer 1. That is where we decide whether the same captured event can safely be interpreted in multiple contexts, and whether those interpretations can be traced and audited over time.
2.3 Structural vs semantic interoperability
Every standards document talks about “structural and semantic interoperability.” In practice, these are rarely separated cleanly.
Structural interoperability is about the skeleton of data. Systems share expectations about which fields exist, the types of those fields, basic constraints and how records are grouped or related. If two systems agree that an object called Person has a date_of_birth field which is an ISO date and cannot be blank, they have achieved a degree of structural interoperability.
Semantic interoperability is about meaning. Does Person include legal entities or only natural persons. Does date_of_birth refer to the registered date in the civil registry or the date declared when records are incomplete. Are leap-day births treated with special rules in pension calculations. These questions depend on jurisdiction, institution and purpose.
When both structure and semantics are collapsed into a single canonical schema, any change in semantics becomes a change in the model. When regulations redefine a category or a court ruling changes the interpretation of an attribute, you have to version the schema, propagate that change across all systems and retrofit existing records. That is rarely feasible at scale. Implementers resort to hacks: overloading fields, inventing informal conventions, burying new meanings in code.
A more resilient approach is to treat structure and semantics as related but separable layers.
The structural layer is stable and minimal. It specifies fields, datatypes, relationships and generic constraints. The semantic layer is expressed as overlays that bind meanings, policies and interpretations to the structure for specific communities, jurisdictions or use cases.
This separation delivers three important properties.
First, multiple semantic communities can share the same capture substrate without being forced into a single worldview. A regulator, an insurer and a research institution can agree on the structural representation of a clinical event while maintaining their own overlays that interpret and constrain that event differently.
Second, semantics can evolve without structural churn. When regulations change, overlays can be updated, versioned and attached to new capture events. Historical records remain structurally consistent and their semantics can be reconstructed by looking at which overlay was active at capture time.
Third, disagreement becomes safer. Not all domains will converge on the same meanings, and that is acceptable as long as the boundaries between overlays are clear and machine-readable. Systems can see when they are crossing from one semantic regime to another and adjust their reasoning accordingly.
None of this is possible if we insist that the schema is the single source of truth for both structure and semantics. Once semantics are lifted into explicit overlays, the schema becomes a neutral backbone. Interoperability becomes less about forcing everyone onto the same model and more about ensuring everyone can see which semantics they are dealing with at any moment.
2.4 How poor capture architecture operationalises harm
When capture architecture is treated as an afterthought, the consequences are not just inefficiency and integration cost. They include systematic harm.
Take a welfare system that captures a field asking whether a person is “economically active.” The structural representation is straightforward. A boolean or short enumeration; a drop-down in a form; a schema that says the field is mandatory. On the surface, two agencies using the same field type and code list appear structurally interoperable.
The harm surfaces appear when you ask semantic questions.
Who qualifies as “economically active” in this context. Does unpaid care work count. What about informal day labour, seasonal agricultural work or platform-mediated gigs. Is the status self-declared, inferred from contribution records or verified through employers. How often is it refreshed. What happens when reality diverges from the captured value.
If these questions are not made explicit and encoded as overlays tied to the capture event, practice degrades. Frontline staff make ad hoc decisions. Local offices invent unwritten rules. Two people in identical circumstances are treated differently because they interact with different case workers or fall under different offices.
The harm is not restricted to that one system. The “economically active” flag becomes part of the person’s data trail. Credit systems, background checks and eligibility engines ingest it as if it were a neutral fact. From their perspective, it is just another field in a schema. If the flag is false, they may down-score creditworthiness, limit access to programmes or trigger enhanced scrutiny. Ambiguity at capture turns into compound disadvantage as the flag flows through multiple decision layers.
Similar patterns appear in healthcare. A diagnostic code captured under one billing regime is reused in research datasets or risk models under another. The capture context, payment incentives and local coding practices are rarely visible downstream. Researchers treat codes as proxies for clinical reality when they often encode a blend of clinical judgment, reimbursement logic and documentation behaviour. Models trained on such data can reinforce bias, misidentify risk or trigger unnecessary interventions.
In law enforcement and security contexts, flags such as “person of interest,” “known associate” or “potential extremist” may be captured with vague criteria, weak oversight and limited appeal mechanisms. If those labels are reused in other systems without explicit semantics and robust provenance, people can be denied services, blocked from travel or placed under surveillance based on classifications they never see and cannot contest.
All of these harms share a common root. The capture architecture treated semantics, policies and provenance as informal context rather than as first-class, portable artefacts. Systems may have excellent schemas and detailed data dictionaries. They may be fully “interoperable” by conventional measures. They are still dangerous because the commitments attached to each captured field are opaque, unstable and non-verifiable.
An architecture-first stance insists that, at the point of capture, systems record not only values but also:
The applicable semantic overlays, including definitions and intended use.
The validation rules that ran and their outcomes.
The authority under which the capture took place, including delegation chains.
The time-bounded parameters and revocation conditions for derived statuses.
Anchored in a way that can be verified independently, these elements make downstream guessing unnecessary. Systems can see what kind of claim they are dealing with, under which semantics it was captured and how much weight to give it in their own decisions. They can detect when a claim is reused outside its intended context and treat that as a governance issue rather than silently proceeding.
Harm does not disappear, but it becomes traceable and governable instead of being buried inside undocumented mappings and brittle models.
3. Architecture-First Patterns and the Political Economy of Interopability
3.1 Overlays Capture Architecture: the core pattern
Overlays Capture Architecture is one concrete way to operationalise an architecture-first view.
The move is simple, precise and unambiguous. Stop encoding everything into the schema. Make capture the anchor for both structure and semantics, and express semantics, presentation and policy as overlays that can be attached, versioned and governed.
You start with a neutral capture substrate. It is the minimum viable container for a statement: identifiers, fields, basic types, timestamps, provenance hooks, signatures. It is deliberately boring. Its job is to be stable, auditable and efficient.
On top of this substrate you attach overlays, each focused on a specific concern:
Structural expectations and constraints.
Human-readable labels in particular languages.
Jurisdiction-specific business rules.
Display and branding rules for different channels.
Risk scores or policy conditions.
Mappings to domain-specific models or legacy schemas.
In conventional designs, these concerns are either jammed into a single schema or scattered across code, documents and local lore. Overlays pull that scattered meaning into explicit artefacts that can be versioned, signed and composed.
The constraint is that overlays operate against the same stable capture substrate. They reference the same fields, the same identifiers and the same provenance anchors. That yields a powerful property: you can achieve structural interoperability without enforcing semantic uniformity.
Different institutions can agree that a credential, record or message shares the same underlying structure and provenance guarantees. They do not have to agree on every aspect of its meaning. Each can publish overlays that reflect its regulatory environment, risk appetite or product design. When they exchange data, they are not just swapping values. They are exchanging values plus a bundle of overlays that make those values interpretable in a machine-actionable way.
Imagine a digital identity credential used across a federal system with multiple languages and local brands. The capture substrate defines that the credential includes an identifier, name, date of birth and residency attribute. One overlay specifies labels and instructions in German. Another in French. Another in Italian. Another in Romansh. Further overlays define visual layouts for each canton, and yet another describes how “residency” is interpreted for tax versus access to municipal services.
Everyone shares the same capture substrate. No one is forced into a single semantic regime. Overlays make it possible to maintain local autonomy without creating an explosion of incompatible schemas.
The same pattern generalises to finance, logistics, education, health, energy and mobility. Wherever multiple institutions need to act on the same facts but interpret them differently, overlays offer a structured escape from schema wars.
Once overlays exist as first-class artefacts, they can be:
Anchored to trust registries that specify who is allowed to publish or endorse them.
Signed and versioned so that you can reconstruct, after the fact, which overlay was active at capture.
Referenced by applications and AI systems to decide how to treat data in specific contexts.
Interoperability shifts from reliance on a privileged schema to reliance on a stable capture substrate plus a governable ecosystem of overlays.
3.2 From data interoperability to trust interoperability
Overlay-based design makes it easier to name the real target. The goal is not data interoperability. The goal is trust interoperability.
Data interoperability ensures that systems can exchange and parse information structures. Trust interoperability means that systems, regulators and affected people can reason about the legitimacy, scope and risk of those structures across institutional boundaries.
To achieve that, additional components are needed.
You need trust registries. These are governed lists of who is authorised to issue which types of statements under which policy frameworks, with what binding to law or regulation. A registry might state that a ministry can issue residency attestations, a bank can issue income statements, a laboratory can issue health certificates, and each acts under specific statutory or contractual authority.
You need assurance networks. These record and anchor capture events, signatures and overlays in a way that can be verified independently. Their implementation may involve blockchains, append-only logs or other mechanisms. What matters is that they provide a way to check that a captured statement and its overlays are intact, current and not revoked, without relying on point-to-point API calls.
You need wallets and agents operating on behalf of people and organisations. A credential is not just a record; it is a snapshot of a captured commitment plus overlays plus pointers into trust registries and assurance networks. A wallet that manages these artefacts is the front end to the trust fabric.
When someone presents a credential from their wallet to a relying party in this architecture, three checks can occur in a disciplined way.
The relying party verifies, through the assurance network, that the credential was issued as claimed, has not been tampered with and is not revoked. It checks, via trust registries, that the issuer had the authority to make that statement at the time of capture and that the overlay in use fits its risk and compliance policies. It uses overlays to interpret fields correctly for the decision at hand instead of guessing based on field names or bespoke mappings.
At that point, the relying party can make its own commitment—to open an account, grant access, approve a claim, configure an AI agent—grounded in a verifiable chain of capture events, semantics and authority.
That is trust interoperability in practice.
The difference becomes even more pronounced with agentic AI systems. Agents deciding whether to act on behalf of users or institutions need more than raw data. They need to know which overlays apply, what usage constraints exist, which risk frameworks are in play and how liability is apportioned. Trust interoperability gives them a way to discover and enforce those constraints, rather than forcing them to infer meaning from JSON structures.
3.3 The political economy of architectural choices
Architecture is never neutral. It determines who can set meaning, who can compose meaning and who must consume meaning on someone else’s terms.
A schema monopoly is the most direct expression of this power. When a single actor or small club controls the canonical model, everyone else must conform or accept penalties. Deviations become “extensions” or “customisations,” with all the associated integration and reputational costs. The monopolist dictates not only technical detail but also implicit policy, because the schema encodes assumptions about categories, thresholds and what counts as a legitimate field of concern.
Sometimes this is deliberate. Sometimes it is just path dependence. A schema born inside a powerful institution spreads because it exists and is well-documented, not because it is conceptually sound. Over time, vendor ecosystems, procurement frameworks and training programmes build around it. The architecture of trust ends up subordinated to the architecture of one institution’s database.
An architectural commons is different.
The capture substrate is shared. Mechanisms for publishing and governing overlays are open. Trust registries and assurance networks are governed with clear rules for participation, dispute resolution and change management. No single institution owns the semantic universe. Communities, regulators, industry groups and individual organisations can all publish overlays, subject to transparent governance.
Power moves from controlling the schema to competing on overlays, services and policy bundles.
A regulator might publish an overlay defining how creditworthiness must be computed for a specific segment, specifying permissible data sources, risk ranges and fairness constraints. A fintech might publish its own overlay for internal scoring, innovating within regulatory boundaries. Civil society groups might publish overlays representing alternative classifications or flagging potential harm conditions, giving individuals tools to audit how they are represented.
The capture substrate remains stable. The assurance network records who published which overlays, under what authority and when. Trust registries record which overlays a given relying party claims to honour. The politics move into the overlays, where they can be contested, versioned and audited.
This has direct implications for compliance and explainability.
When regulators ask, “Why was this decision taken?,” a schema-first system can point to field values and application logic. Investigations become forensic exercises in reconstructing meaning from incomplete documentation and the memories of staff. An architecture-first system can show the captured credential, the overlays active at the time, the trust registries through which authority flowed and the risk frameworks bound to the decision. It can show when overlays were updated and how those updates would alter decisions under counterfactual scenarios.
Architecture becomes the channel through which governance flows, rather than an obstacle to be worked around.
3.4 Design patterns for architecture-first interoperability
Translating this into practice requires concrete patterns that teams can adopt.
Capture-first design.
Instead of starting from existing systems and their interfaces, start from real-world events and the commitments they entail. Design the capture artefacts—credentials, records, messages—with explicit provenance and overlays. Then map existing systems into this substrate. Legacy schemas become sources; capture artefacts become the interface.
Structural core, semantic overlays.
Define a minimal structural core and force semantic variation into overlays. Keep fields, types and relationships stable. Express country-specific rules, risk models, UI labels and reporting classifications as overlays. Version overlays, not the structural substrate, wherever possible.
Registry-anchored authority.
Never rely on implicit authority. Every issuer, overlay publisher and assurance network participant should have entries in one or more trust registries. Overlays reference registry identities of their owners. Relying parties express their acceptance policies in terms of registries and overlays, forming a verifiable graph of authority.
Policy-aware agents and AI.
Assume that future systems will include agents acting on behalf of people and organisations. Design overlays so they can encode usage constraints, consent boundaries, risk grades and fairness requirements in a machine-actionable way. Treat trust registries and assurance networks as first-class dependencies in AI and orchestration frameworks.
Migration by wrapping rather than replacement.
Legacy cannot be wished away. Define capture substrates and overlays for high-impact use cases. Build adapters that construct these artefacts from existing databases and APIs, anchoring them in assurance networks and registries. Require new systems to speak the capture-native language. Retire old systems gradually, as dependent processes are migrated.
These patterns reposition interoperability work away from one-off integration projects and towards a continuous architectural programme: defining, governing and evolving the trust substrate.
3.5 Implementation scenarios
A few scenarios illustrate how this plays out.
National digital identity and entitlements.
In a schema-first model, a national ID system publishes a core schema. Welfare, tax, banking and mobility all extend it for their own purposes. Each extension diverges. Integrating across them becomes a permanent reconciliation exercise.
In an architecture-first model, the ID system defines a capture substrate for person identity attributes. Overlays for residency, civil status and demographic features are published and anchored. Welfare, tax, banking and mobility each publish overlays that interpret the same captured attributes differently, under their regulators’ oversight. The same credential can be presented to different relying parties with different overlays applied, without creating incompatible schemas.
Cross-border KYC and KYB.
Today, banks rely on messaging standards, bilateral agreements and bespoke APIs. Each jurisdiction defines beneficial ownership, residency and risk classifications differently. Schema alignment is aspirational. Onboarding is slow and manual.
With overlays and registries, each jurisdiction publishes its semantic overlays for KYC/KYB, bound to statutes and enforcement regimes. Banks agree on a shared capture substrate for identity, ownership and activity. They consume the overlays relevant to customer jurisdiction, product type and risk appetite. Assurance networks anchor issuance and updates. Regulators publish overlays defining acceptable risk models and data usage across borders.
Data spaces and supply chains.
A shipment moves from manufacturer to freight forwarder to port to customs to warehouse to retailer. Each actor uses its own systems and schemas. Enforcing a single model across all is unrealistic.
A capture substrate defines core shipment events and attributes. Overlays for customs declarations, insurance, trade finance, regulatory reporting and ESG disclosures build on that substrate. Assurance networks capture events in real time. Trust registries record who may issue which overlays. New actors adopt the substrate and relevant overlays, integrating into the data space without renegotiating everything from scratch.
Agentic AI as orchestration fabric.
An agent that rebalances portfolios, manages cash across banks, books logistics services or interacts with government portals needs more than APIs. It needs to know which credentials it can rely on, what policies govern data use and how to justify its actions.
In an architecture-first environment, the agent queries trust registries to discover legitimate issuers. It inspects overlays to understand constraints and risk. It verifies credentials against assurance networks. Its behaviour is parameterised by the trust fabric, not by brittle, one-off integrations.
3.6 Strategic recommendations for future development
From here, the roadmap is more strategic than technical.
For policymakers and regulators, the action is to treat capture architecture, overlays, trust registries and assurance networks as public infrastructure. That means:
Funding and mandating architecture-first approaches in national digital identity, financial regulation, health data governance and sectoral data spaces.
Issuing guidance that focuses on capture patterns, verifiability and semantics governance rather than prescribing schemas as if they were natural law.
Designing audit and supervisory frameworks that assume access to overlays, registry entries and assurance logs, not just raw data dumps.
For CIOs, CDOs and enterprise architects, the imperative is to stop treating schema harmonisation as the primary route to interoperability. The budget lines currently spent on endless mappings and tactical integrations should be redirected towards:
Capture-first design for new flows and products.
Overlay tooling and lifecycle management.
Integration with trust registries and assurance services.
Refactoring legacy systems to emit capture-native artefacts, even if they remain schema-centric internally.
If most of your interop roadmap is described as “connecting system X and system Y,” you are still operating in the old paradigm. The new paradigm is “expressing event Z as a captured, overlayed, verifiable artefact that any compliant system can consume.”
For ecosystem builders and standards bodies, success metrics need to change. Instead of counting how many organisations have adopted a canonical model, count:
How many independent overlay publishers exist.
How many jurisdictions participate in shared capture substrates.
How much verifiable data flows through common assurance networks.
How many agentic systems treat the trust fabric as a dependency rather than a bolt-on.
The underlying choice is stark.
We can continue to pour effort into schema projects, integration backlogs and manual reconciliation and accept that as the cost of doing business. Or we can acknowledge what the last decades have taught us: models are necessary but not sufficient, and they are the wrong place to anchor interoperability.
If we shift the focus to architecture—capture substrates, overlays, trust registries, assurance networks and first-person credentials—then schemas stop being battlefields and become tools. Markets can price and allocate based on verifiable commitments instead of schema fog. Harm surfaces become visible and contestable. Governance gains a live channel into the systems it is supposed to oversee.
The next decade will not be won by whoever publishes the most elaborate data model. It will be won by whoever builds and governs the most robust trust architecture: a fabric in which different models, jurisdictions and agents can disagree safely, transact reliably and explain themselves when it matters.