DM Explains · No. 041 · Architecture
Context federation: why AI systems share data without a single source of truth
Instead of pouring every sensor reading and user signal into one central store, independent context brokers negotiate and share just what's needed — trading a bit of coordination overhead for scalability, privacy and resilience.
· 15 min read
Read me first
Context federation genuinely does let AI systems share situational data across organisations without a central database, but only when every broker agrees, in advance, what it's willing to share and how fresh that data has to be.
A smart-city digital twin: city sensors, a hospital and a transport authority each run their own broker — 1 sensors keep raw readings local → 2 brokers auction a Context Level Agreement, freshest wins → 3 pub/sub topics disseminate at city scale, avoiding the centralised bottleneck → 4 ODRL policy gates what the hospital may see → 5 the overlay translates transport schema into hospital terms without merging stores → 6 MCP-style fusion combines sensor, image and record modalities, lifting diagnostic accuracy up to 9.8% → 7 an edge cache answers repeat queries locally, cutting dropout 54% → shared live view reaches each authority's dashboard.
A hospital's AI agent needs imaging data from one department, device sensor readings from another, and patient history from a partner clinic. None of these systems can simply dump their records into one shared database — not for lack of willingness, but because the departments are run by different teams, under different rules, with different owners.
The obvious fix is to force everything into one central repository. That creates a bottleneck, a privacy liability and a single point of failure. The less obvious fix is to leave the data where it is and get the systems holding it to talk to each other directly, sharing only what's needed, when it's needed. That's context federation.
Everyday picture. Instead of everyone reporting everything to Amma so she can tell the household what's going on, Papa keeps his work schedule in one notebook and Dadi keeps medicine times in another. They share only specific pages with each other when it's actually needed — Meera checking the fridge chart to see who last walked Bruno, rather than asking the whole house.
Where the picture breaks. In the house, trust is implicit because everyone is family. Context federation needs explicit written policies, like Context Level Agreements, because the brokers sharing data often belong to organisations that have never met.
Why it exists now
The problem is old: ubiquitous computing researchers have flagged privacy and security as unresolved challenges in context-aware systems for years, precisely because collecting and processing sensitive context data across systems creates risk of unauthorised access and misuse (Context-Aware Systems in Ubiquitous Computing, DOI/Engrxiv). The first practical federated context broker, built to test whether distributing brokers could outscale a centralised one under load, came out of a doctoral thesis presenting exactly that comparison (Federated broker model for context provisioning, EThOS/British Library).
What's new is scale and stakes. Smart cities, digital twins and multi-agent AI systems now need to combine sensor streams, patient records and device telemetry that sit across organisational boundaries, not just across departments in one company. Recent work has pushed federation from single-domain pub/sub research into cross-organisation, multi-modal settings: a 2024 overlay for letting entire data federations talk to each other, a 2025 approach for governing digital twin data sharing with standard access-control policies, and a 2025 paper applying the Model Context Protocol — a schema-driven interoperability layer originally built for AI agents and tools — to federate multi-modal health data. None of this needed a new kind of database. It needed agreed ways for independently-owned brokers to negotiate, route and govern what they share.
How it works
Local acquisition
Keep raw data where it's born
What it is. Each domain — a hospital, a city sensor network, a mobile device — runs its own context broker that collects raw data from sensors, applications or users locally.
Why it exists. Context Information Services typically provide infrastructure for the collection, management and dissemination of context information about users, devices or environments (A Collaborative Framework for QoC-driven Context Information Provision, 2014). Keeping that collection local avoids routing all raw data through one pipeline and exposes less sensitive data externally.
Where it breaks. If every domain hoards data with no sharing mechanism, there's no context awareness at all — just a lot of isolated notebooks nobody else can read.
How that's handled. The broker exposes a negotiated, limited view to other brokers rather than its full raw store.
In technical terms
In technical terms: each domain's broker acts as a Context Information Service, aggregating sensor and application data behind a single local interface that other brokers query rather than reaching into the source systems directly.
QoC negotiate
Pick the freshest voice, not the loudest
Illustrative: the smart city's transport authority needs hospital-area congestion data → 1 discovers the hospital's and city's brokers → 2 auctions a Context Level Agreement, hospital wins reliability → 3 ODRL policy clears only anonymised flow counts → 4 subscribes to the 'traffic-near-hospital' topic → 5 pub/sub delivers updates to transport and city brokers alike → 6 both cache locally, cutting overhead by roughly 40-60% versus a merged database
What it is. Before data flows, brokers negotiate a Context Level Agreement describing how fresh, accurate and trustworthy the context on offer actually is.
Why it exists. A consumer broker often has several possible providers for the same kind of data. Rather than a central authority vetting each one, a proposed framework has cloud-based context brokers negotiate these agreements via an auction-based selection algorithm, so the consumer picks the best offer on quality-of-context grounds (A Collaborative Framework for QoC-driven Context Information Provision, 2014).
Where it breaks. Negotiation adds latency and complexity that's wasted in small, low-stakes systems where one trusted source already exists — auctioning a decision nobody is contesting.
How that's handled. Negotiation only triggers where more than one provider plausibly competes; single-source links skip it.
In technical terms
In technical terms: Quality of Context attributes — freshness, accuracy, trust — are scored and compared through an auction mechanism, with the winning Context Level Agreement binding the provider to a specific delivery quality.
Pub/sub routing
Scales where hubs buckle
What it is. Once a provider is chosen, context flows between brokers over publish/subscribe channels — a messaging pattern where publishers broadcast on topics and subscribers receive updates on topics they care about, without a central hub relaying every message.
Why it exists. A federated broker architecture for large-scale context dissemination was presented specifically to avoid the bottleneck of a single relay point (A Federated Broker Architecture for Large Scale Context Dissemination, IEEE). The same thesis that built the first practical federated broker found it scaled better under increasing load than a centralised baseline, and also found its mobile context broker component significantly cut average energy consumption on mobile devices during context-awareness tasks (Federated broker model for context provisioning, EThOS/British Library).
Where it breaks. Pub/sub topologies can still leave brokers out of sync — there's no guaranteed single, up-to-the-second snapshot across all of them.
How that's handled. The freshness attributes negotiated in step two set the tolerance for how stale a subscription's data is allowed to be before it's flagged.
In technical terms
In technical terms: subscriptions and notifications route broker-to-broker over topic channels rather than through a central dispatcher, which is what let the federated model in the thesis outscale the centralised one under load.
Policy governance
Rules replace a referee
What it is. Standardised data models and access-control policies decide who may read or write which piece of context, replacing a single gatekeeping authority.
Why it exists. A 2025 case study on federating digital twin ecosystems used NGSI-LD — a data model and API standard for linked context information — paired with ODRL-based access-control policies to govern sharing across heterogeneous digital twin environments (Enabling secure and trusted digital twin federations with data spaces, University of Salento repository, 2025).
Where it breaks. Writing and maintaining shared policy standards across organisations is a governance project in its own right, not a purely technical one — getting a hospital and a city authority to agree on an access policy can take longer than building the broker.
How that's handled. NGSI-LD gives the data a common shape so policies written in ODRL can be checked mechanically rather than argued over case by case.
In technical terms
In technical terms: NGSI-LD represents context as linked entities with properties and relationships; ODRL expresses permission and constraint rules against those entities, so an access decision becomes a policy match rather than a manual approval.
Cross-federation overlay
Translate, don't merge
What it is. An overlay layer lets entirely separate federations — each with its own brokers, data models and policies — exchange context without unifying their underlying systems.
Why it exists. The CCDUIT overlay models each federation as a property graph and routes context across federations through policy-matched publish/subscribe topics. Experimental evaluation found this cut operational overhead for data management and sharing across federations by roughly 40% to 60%, as of 2024 (CCDUIT: A Software Overlay for Cross-Federation Collaboration Between Data Spaces, IEEE, 2024).
Where it breaks. The overlay itself becomes new infrastructure to trust, secure and maintain — a translator everyone now depends on.
How that's handled. The overlay only translates topic schemes and policy matches; it never merges the underlying data models, so a failure in the overlay degrades cross-federation sharing without corrupting any single federation's own data.
In technical terms
In technical terms: each federation is represented as a property graph; CCDUIT matches policies and routes across graphs via pub/sub topics rather than reconciling schemas into one model.
Multi-modal fusion
One protocol, many data types
What it is. Schema-driven protocols let distributed AI agents combine imaging data, text records and sensor streams into a single decision, even when each data type comes from a different federated source.
Why it exists. A 2025 framework applied the Model Context Protocol to federated health data and reported, against a baseline federated-learning approach, an improvement in diagnostic accuracy of up to 9.8% and a 54% reduction in client dropout rates (Secure Multi-Modal Data Fusion in Federated Digital Health Systems via MCP, arXiv, 2025).
Where it breaks. This is a single paper's results on specific datasets, not a broadly validated finding across domains — it shows the direction a schema-driven protocol can push things, not a guaranteed outcome elsewhere.
How that's handled. Treat the figures as evidence worth testing on your own data, not as a number to plan a budget around.
In technical terms
In technical terms: the Model Context Protocol supplies a schema that agents use to request and exchange structured, typed context across modalities, so fusion happens against a shared interface rather than custom integration code per data type.
Edge caching
Ask once, remember locally
What it is. Brokers near the edge — on a mobile device, say — cache frequently requested context locally rather than querying across the federation every time.
Why it exists. The same thesis that built the first federated broker tested cache-replacement policies within a context caching component and found the Mobile Context Broker significantly reduced average energy consumption on mobile devices during context-awareness functions (Federated broker model for context provisioning, EThOS/British Library).
Where it breaks. Cached context can go stale, reintroducing the freshness problem that QoC negotiation in step two was meant to solve.
How that's handled. Cache entries carry the same freshness attributes negotiated upstream, so a stale cache hit is detectable rather than silently served as current.
In technical terms
In technical terms: cache-replacement policies decide which cached context entries to evict as new requests arrive, trading memory and staleness risk against repeated cross-federation queries.
Compared with what came before
| Central context store | Context federation | |
|---|---|---|
| Who owns the data | One system, one authority | Each domain keeps its own |
| Scaling under load | Bottlenecks at the hub | Experimentally shown to scale better than a centralised baseline (EThOS thesis) |
| Consistency | One snapshot, always current | No guaranteed single up-to-the-second view |
| Trust mechanism | Central vetting | Negotiated agreements and policy matching |
| New overhead | None beyond the store itself | Negotiation, routing, governance, overlay translation |
A single central store wins on simplicity and consistency; it just doesn't survive contact with multiple owners, multiple organisations, or load at city scale. Federation gives up a guaranteed single snapshot in exchange for autonomy, resilience and the ability to scale past one hub — a trade that only pays off once there's more than one owner in the room.
Where it breaks
Federation makes sense when ownership is already distributed; it's a poor fit when it isn't.
Not a cure for weak data governance
NGSI-LD and ODRL give organisations a common language for access policy, but writing those policies is still a negotiation between people and institutions, not a technical switch to flip. A federation with no agreed governance is just several silos pretending to cooperate.
Negotiation and policy-matching overhead is wasted in small, low-stakes systems where a single trusted source already exists — auctioning among providers nobody is actually contesting. Pub/sub routing scales well but doesn't guarantee a single consistent view across brokers at every instant, so applications that need a globally consistent snapshot at all times are fighting the architecture rather than using it. And the privacy and security challenges that motivated federation in the first place — unauthorised access, misuse of sensitive context — don't disappear just because the data is distributed; distributing it only changes where the attack surface sits.
Numbers to carry
| Figure | What it measures |
|---|---|
| 40% to 60% reduction | Operational overhead cut by the CCDUIT cross-federation overlay, as of 2024 |
| Up to 9.8% improvement | Diagnostic accuracy gain from an MCP-based multi-modal federated health framework vs baseline federated learning, as of 2025 |
| 54% reduction | Client dropout rate cut by the same MCP-based framework vs baseline federated learning, as of 2025 |
| First practical implementation | A federated context broker scaling better than a centralised baseline, from a doctoral thesis (EThOS/British Library) |
Myths worth killing
| Commonly repeated | What is actually true |
|---|---|
| "Federation means no database at all" | Each broker still runs its own local store; federation is about how brokers share across those stores, not about removing storage |
| "It's the same as federated learning" | Federated learning shares model updates while keeping training data local; context federation shares the situational data itself, independent of any training process |
| "One overlay means one unified data model" | CCDUIT and similar overlays translate and route between federations; they don't merge the underlying data models |
| "More brokers always means more consistency risk" | It means a different consistency trade-off, not an automatic downgrade — freshness attributes in Context Level Agreements are designed to make staleness visible rather than silent |
Worked example
- A city sensor broker, a hospital broker and a transport authority broker each keep their own raw context locally — traffic sensors, patient monitors, transit feeds.
- The hospital broker needs live traffic data to predict ambulance arrival times, so it queries for a traffic context provider and negotiates a Context Level Agreement specifying how fresh the data must be.
- The city broker, selected through the negotiation, pushes updates to the hospital broker over a publish/subscribe topic rather than through a shared hub.
- An access-control policy, written in ODRL against NGSI-LD entities, confirms the hospital broker is permitted to read anonymised traffic density but not raw camera feeds.
- When the transport authority's own federation needs patient-flow forecasts from the hospital, a cross-federation overlay matches the request against both sides' policies and routes it without merging the two federations' data models.
- An AI agent at the hospital fuses the traffic feed, patient records and device telemetry through a shared schema to forecast emergency bed demand — illustratively, if the agent's forecast window needs data no older than five minutes and the cached traffic feed is eight minutes old, the cache is flagged stale and a fresh query is triggered instead of serving the cached figure.
- The hospital's mobile devices cache the fused forecast locally so staff checking it repeatedly don't trigger a new cross-federation query each time.
Should you use it?
Context federation earns its overhead when context genuinely sits across organisations or domains that cannot or will not centralise it, when more than one possible provider exists for the same kind of data, or when the system has to survive scale and network boundaries that would overload one hub. It is a poor fit for a small, single-organisation system where a central store already meets latency and privacy needs, or for anything that genuinely requires one globally consistent snapshot at every instant.
The cheapest first experiment is not an overlay or a protocol — it's writing one Context Level Agreement between two systems that already exchange data informally, and measuring whether negotiated freshness actually changes anything downstream.
Say it in the room
"Federate when ownership is already distributed and more than one source could plausibly answer the same query; centralise when one team, one store, one snapshot is enough."
Lines to carry
- "No single source of truth, many negotiated views."
- "Federation trades coordination for autonomy."
- "Share the page, not the notebook."
- "Trust needs a policy when it isn't family."
- "First-stage question: does more than one owner exist?"
- "An overlay is infrastructure too — it needs its own trust."
FAQ
Is this just a fancier name for microservices talking to each other?
Not quite. Microservices typically share one organisation's data model and trust boundary. Context federation is built for brokers that belong to different organisations, with different policies and no shared database to fall back on — the negotiation and governance layers exist precisely because that shared trust isn't assumed.
Does federation mean giving up on data consistency?
It means giving up on a guaranteed single, instantaneous snapshot across every broker. Freshness is instead negotiated explicitly through Context Level Agreements, so a consumer knows how stale the data it's getting is allowed to be, rather than assuming it's always current.
How is this different from federated learning?
Federated learning shares model updates — gradients or weights — while keeping training data local. Context federation shares the situational data itself, or a negotiated view of it, between brokers, independent of whether any model is being trained at all.
Do I need the Model Context Protocol to do context federation?
No. Pub/sub routing and policy-based governance predate MCP by years. MCP is one recent way to let AI agents specifically fuse multi-modal context across federated sources, demonstrated with promising but early, single-paper results in healthcare as of 2025.
What's the actual cost of adding more brokers?
Negotiation overhead — every new provider relationship needs a Context Level Agreement, and every cross-federation link needs a policy match. The dossier's measured figure for one overlay is a 40% to 60% cut in operational overhead versus not using the overlay, but that's a saving relative to doing cross-federation sharing badly, not a free lunch versus not federating at all.
Glossary
- Context broker — a software component that collects, stores and distributes situational data about users, devices or environments.
- Context federation — an architecture where multiple independent context brokers cooperate and share data across domains instead of using one central store.
- Quality of Context (QoC) — attributes describing how good a piece of context information is, such as how fresh, accurate or trustworthy it is.
- Context Level Agreement (CLA) — a negotiated agreement between a context consumer and provider specifying the quality of context that will be delivered.
- Publish/subscribe (pub/sub) — a messaging pattern where publishers broadcast information on topics and subscribers receive updates on topics they're interested in, without direct connections.
- Data space — a governed environment for sharing data between organisations under agreed rules, often using standard data models and access-control policies.
- NGSI-LD — a data model and API standard for representing and exchanging linked context information, often used in digital twin and smart city systems.
- ODRL — Open Digital Rights Language, a standard for expressing policies about how data may be used, including access permissions.
- Digital twin — a virtual representation of a physical object, system or process, kept updated with real-world data.
- Federated learning — a machine learning approach where models are trained across many devices or servers holding local data, without centralising the raw data itself.
- Model Context Protocol (MCP) — a schema-driven interoperability protocol allowing AI agents and tools to exchange structured context across systems.
- Edge caching — storing frequently used data closer to where it is needed to reduce repeated network requests.
- Overlay (software overlay) — an additional software layer placed on top of existing systems to add new functionality, such as translating between different data federations.
Sources
- A Federated Broker Architecture for Large Scale Context Dissemination — IEEE
- A Collaborative Framework for QoC-driven Context Information Provision — DOI, 2014
- Federated broker model for context provisioning in large-scale distributed context-aware systems — EThOS / British Library
- Enabling secure and trusted digital twin federations with data spaces — University of Salento repository, 2025
- Context-Aware Systems in Ubiquitous Computing: Techniques, Applications, and Challenges — DOI / Engrxiv
- CCDUIT: A Software Overlay for Cross-Federation Collaboration Between Data Spaces — IEEE / DOI, 2024
- Secure Multi-Modal Data Fusion in Federated Digital Health Systems via MCP — arXiv, 2025