Who Owns Your Context Layer?

In June, France’s domestic intelligence agency ended a ten-year relationship with the analytics platform it had relied on since the 2015 Paris attacks. The replacement is a French firm, and the prime minister gave the reason in one phrase: France cannot accept strategic dependencies on companies “capable of turning off the tap.” Germany’s federal intelligence service made the same call. Spain has since directed its state-backed companies the same way.

Intelligence agencies got there first, but the logic is not about intelligence. It is about any organization building critical capability on infrastructure whose owner can change the terms, the access, or the availability. A refinery, a mine, or a power utility building its operational context layer, the semantic model its AI decisions will depend on for twenty years, faces the same exposure. An analytics dependency is painful to unwind. A context layer woven into how your operation makes decisions is close to structural.

So the procurement question for context infrastructure has changed. For the past two years it was “which platform has the best features?” The better question now: whatever happens to this vendor, what do I still own?

The consolidation makes it urgent

The industrial context layer is consolidating into large OEM stacks. Schneider Electric’s $3.1 billion agreement to acquire Cognite in June is the largest recent example, following a run of context and data-platform acquisitions across the sector, and more will follow. Consolidation is normal in industrial software, and it often serves customers well.

But it changes the diligence. The vendor you select this year can have a different owner next year, with different priorities, a different roadmap, and a different attitude to the other vendors’ equipment in your plant. None of that is hypothetical anymore, and none of it is in your control. What is in your control is how much of your operational knowledge survives that kind of event untouched.

The analysts are saying the same thing. ARC Advisory Group, writing days after the acquisition, put it directly: the industry’s largest players are consolidating around unified context layers, and buyers must act now to secure their own architecture before vendor lock-in tightens. The prescription is worth reading in full: assemble your own data foundation, and mandate open protocols over walled gardens.

Two tests, and most platforms pass only one

There are two separate questions hiding inside “sovereignty,” and vendors tend to answer whichever one they pass.

The first is jurisdictional: whose laws, whose government, whose kill switch? This is the test France applied, and buyers in Europe, the Middle East, and Asia are applying it with increasing force.

The second is architectural: if you export everything tomorrow, what do you actually get? Can your ontology, your identity mappings, your decision history leave in a form another system can read? A platform can sit in your country, inside your firewall, run by your nationals, and still hold your operational knowledge in a proprietary format that cannot go anywhere. Jurisdiction tells you who can turn off the tap. Portability tells you whether it matters.

Here is what I see happening: buyers are getting rigorous about the first test while barely asking the second. The vendors know this, which is why every platform now markets itself as sovereign, and almost none publish their export path.

Ownership is architecture

A vendor’s flag does not protect you. Ownership does, and ownership of a context layer has a specific, checkable shape:

• The databases run on your paper. Commercial or open source, procured by you, on your infrastructure: on-premises, private cloud, or fully air-gapped. No pass-through licensing that quietly makes the vendor your landlord.
• The ontology is built on published standards. OWL, SHACL, SPARQL, PROV-O. Any semantic engineer can inspect it, extend it, and validate it. A proprietary ontology is a dependency with a data model attached.
• Everything exports. The semantic model, the mappings your specialists encoded, the full provenance record of every decision, as standard RDF, on demand, without a negotiation.
• Your existing models come in, not just out. The context your engineers already built, in P&ID exports, functional location hierarchies, and historian tag catalogs, imports into the foundation you own rather than being re-derived by inference. Twenty years of modeling work is an asset to carry forward, not a legacy to abandon.
• The evidence survives vendor exit. Your regulators and insurers will still want the audit trail in 2036. It should not depend on a subscription being active, or on who owns the vendor by then.
• Your own people can run it. Standard databases mean your IT operates the substrate with the DBA, backup, and patching practices it already has. Standards-based ontologies mean your engineers, or the systems integrator you already trust, extend and maintain the model without waiting in a vendor’s professional services queue. If every change to your context layer requires the vendor’s people, you do not own it in any sense that matters day to day.

When those things are true, a change of vendor ownership becomes a commercial event instead of an operational one. When they are not, your operational knowledge is exposed to someone else’s strategy.

We build XMPro’s Operational Context Engine on this split deliberately. The knowledge substrate, the databases, the ontologies, the mappings, the evidence, belongs to the customer, in open standards, exportable at any time. XMPro licenses the engine that makes it live. Ownership is why you can leave. The compounding is why you stay, and we think that is the only honest basis for a twenty-year infrastructure relationship.

The context layer is the entry, not the destination

One more thing the consolidation tells you. Nobody is paying billions for contextualized data on its own. Context is being acquired because it is the prerequisite for what comes next: agent teams acting on operations, with governance a regulator will accept as evidence. Context is where the stack war starts. Governed autonomous action is what it is for.

So when you evaluate a context layer, evaluate the destination too. Ask who governs the agents that will consume this context, how their decisions are bounded, and what evidence exists when an agent acts. A context layer that feeds an advisory copilot and a context layer that feeds governed autonomous operations look similar in a demo. They are different categories of infrastructure.

Six questions for any context-layer vendor, including us

1. Show me the export path. What formats, what completeness, what does it cost, and has a customer ever actually done it?
2. What happens to the context my engineers have already built? Does it import intact, into a model I own, or does your platform re-infer it?
3. Which published standards is the ontology built on, and can my own engineers extend it without your professional services?
4. Whose paper are the database licenses on, and can the whole platform run inside my boundary, disconnected, on hardware I choose?
5. If your ownership changes, which of my assets are unaffected, contractually and technically?
6. What happens to my audit trail, my decision provenance, and my regulatory evidence if this relationship ends?

Any vendor should welcome these questions. The ones who redirect you to a partnership slide are giving you your answer.

If you want to see how we answer them, the Operational Context Engine page covers the standards and the ownership model, and Gavin Green and our solution architects will happily walk through the export path in detail. Bring the hard questions. That is the point of them.