VAO · pillar 04 · sovereignty and ownership

Governance, sovereignty and IP

Four questions decide everything here, and they get asked in a fixed order. Most of the difficulty in this pillar comes from asking them out of order, or from collapsing two of them into one.

Part one

Four questions, in this order#

A customer who says we care about sovereignty has not yet told you anything actionable. These four separate the claim into things that can be answered, priced and signed — and each one has a different kind of answer: a deployment choice, a technical control, a contract, and an architectural commitment.

Q1Where does it run?

Whether anything leaves the customer's infrastructure at all, and whether a network path even exists.

Answered by topology — A deployment choice, made per account and priced

Q2Who owns what?

The schema, the customer's populated graph, the connectors, the taught decomposition, the traces. Asset by asset, not in aggregate.

Answered by the ownership matrix — A contract, settled before a security review, not during one

Q3What may be generalised?

Whether the method taught at this account — stripped of every particular — may enter the library and reach the next customer.

Answered by the generalisation right — A separately signed schedule, and the clause the moat depends on

Q4Whose model, and how open?

Whether the customer may mandate the model, whether weights run inside their perimeter, and whose data trained what.

Answered by model openness — An architectural commitment, offered at every tier or not credible at any

Topology is decided first. Every other position in this pillar is a consequence of it.

It is tempting to open on the sovereignty story and back into a deployment shape later. That produces both failure modes at once: promising the fastest path to an account that will end up air-gapped, and frightening a mid-market pilot with language it never asked for. Decide where it runs, then everything else follows in order.

Part two

Where it runs#

Two axes move together and are worth separating in the room: where inference runs, and whether anything egresses at all. A customer can be on hosted inference and still export nothing but structure. Air-gapped answers one narrow question — does a network path exist — not the general question of whether data is safe.

Vendor cloud

Compute: Vendor, regional
Network: Standard
Inference: Hosted endpoints, in-region
Who buys it: Pilots and mid-market

Moat participation — full, automatic. Fastest route into the library.

Customer cloud

Compute: Customer's own account, single tenant
Network: Standard, single-tenant boundary
Inference: Hosted or customer-hosted
Who buys it: Most enterprise accounts

Moat participation — full, via the structural exporter.

On-premise

Compute: Customer's data centre or a dedicated tenancy they provision
Network: Connected — a path exists for licensing and support; export is blocked by policy and by the exporter, not by absence of a path
Inference: Customer-controlled open weights
Who buys it: Regulated and export-controlled sectors

Moat participation — none automatic. Only via a human review cycle. Say this before it is discovered.

Air-gapped

Compute: Customer's own perimeter
Network: None — no path exists, physically or logically. This is what makes it D rather than a stricter C
Inference: Customer-controlled, offline
Who buys it: Defence programmes. Top tier only

Moat participation — none automatic. Offline evaluation, mirrored registry, local calibration.

C already answers does our data leave with no. D only adds can anything at all reach or leave this system over a network. That distinction is worth making out loud, because the customer who conflates them buys the more expensive thing for a reason they never had.

The most common self-inflicted woundOver-selling the air-gapped story to an account that never needed it. It costs more to deliver, deploys more slowly, and forecloses the telemetry that would otherwise make that account’s own deployment better calibrated over time. Selling D to a mid-market buyer is not conservatism — it is giving away speed and product quality to buy peace of mind nobody asked for.

Part three

Boundaries and ownership#

Three boundaries, routinely collapsed into one. Confusing them produces over-claiming in the sales conversation and unnecessary alarm in the security review — and the collapse costs the vendor the generalisation right on exactly the accounts where it is worth most.

Boundary 1 — the perimeterDoes anything leave the customer's infrastructure at all?

Answered by topology. In C and D, no.

A deployment choice

↓

Boundary 2 — the data and insight lineOf what does leave, what is operational data and what is structure?

Answered by an enumerated positive list and negative list, enforced by a tested exporter rather than by policy alone.

A technical control

↓

Boundary 3 — the IP lineWho owns the graph, the method, and the improvements?

Answered by the ownership matrix and the generalisation right. This is the one that decides whether the moat exists.

A contract

A customer who says nothing leaves our perimeter has answered boundary 1 and said nothing about boundary 3. Making that distinction explicitly, in the room, is worth doing — because the two get collapsed by default, and the collapse always runs in the direction that costs the vendor the clause it needs.

The ownership matrix

The single most useful artifact in a security review, because it converts an argument into a table.

Asset	Owned by	Note
The customer's operational data	Customer	Absolutely. The vendor is a processor. Returned or destroyed on termination.
The populated graph instance	Customer	A derived work of their data about their operation. Exportable on termination in a documented format. Do not fight for this one — the value is in the schema, not the instance, and conceding it removes a large objection cheaply.
Local overrides and thresholds	Customer	Live in the tenant repository, inside their perimeter in C and D.
Outputs — recommendations, simulations, executed actions	Customer	Their operational decisions.
The graph schema — object model, edge families, archetype rules	Vendor	Licensed for the term. Generic, and contains no customer data.
The deterministic kernel, orchestration and evaluation framework	Vendor	Product.
The strategy library — situation types, strategies, selectors, evaluation suites	Vendor	The asset. The generalisation right governs how it grows.
Connectors built during the engagement	Vendor	Added to the maintained catalogue, because per-customer forks are a maintenance disaster. Carve out the exception for a connector to a system the customer built themselves — their interface, their IP — explicitly, rather than arguing it later.
Traces and decision records	Split	Customer for full fidelity; vendor for enumerated structural telemetry only. Boundary 2 defines the split.
Third-party model weights	Neither	The provider's. Not fine-tuned on any customer's data.
A situation type taught during this engagement	Contested	The vendor owns the decomposition; the customer holds the rights granted in the generalisation schedule. Every clause below exists to resolve this one cell.
A customer-specific fine-tune layer, trained before generalisation strips the particulars	Open	Not yet decided. The candidate precedent is the populated graph — given to the customer outright because the value sits in the schema, not the instance. The same logic may or may not apply.

The generalisation right

The most important clause in the commercial relationship. In plain language, this is what is being asked for:

In the course of the engagement, specialists work with your practitioners to make explicit the reasoning they apply to recurring classes of operational disruption. The result is a documented decision method: the situations that recur, the several legitimate strategies your experts choose between, and the factors that determine which applies.

Your data — suppliers, parts, quantities, prices, programmes, thresholds — remains yours and remains in your environment. What is retained is the method, stripped of every particular: that a class of situation exists, that these strategies address it, and which categories of factor discriminate between them.

Structure it as a separate schedule, not a clause buried in a master agreement. A right this consequential should be signed deliberately, and a customer who cannot find it later will assume it was hidden.

Why a customer agreesReciprocity. They receive the accumulated library from every prior engagement. Withholding the right is asking to consume without contributing — and the pricing reflects that, because teaching a net-new situation type is discounted precisely because of this right.

And it is not a data grant. The negative list sits in the schedule alongside it, and the review that decides what generalises is theirs to run.

Model openness

The shortest section here, and the one that closes the most security reviews. The commitment that matters is unconditional: no fine-tuning on customer data, ever — and the reason it can be unconditional is that the architecture already requires it. Fine-tuning on one customer’s data would bind the taught strategies to one model’s weights and break the swap protocol that sovereignty depends on.

Why unconditionality is the pointA commitment offered at every tier reads as architectural. The same commitment negotiated per deal reads as a concession that might be walked back. Sovereignty and no-training-on-your-data point the same direction, so nothing is given up by making it absolute.

The distinction to hold onto in the room is whose data trained the model, not whether training happened at all. Collapsing those two produces either an over-claim — we never train anything — or an under-sell, that the product is a wrapper around someone else’s model. A vertical model post-trained on the generalised library is a legitimate third answer to whose model, and it contains nothing from the negative list because the stripping happens before generalisation, not after.

The dependency point, which cuts the vendor’s wayModel access is now itself subject to export control. In June 2026 a frontier model tier was placed under US Department of Commerce controls and access was suspended for roughly three weeks before the controls were lifted. For a European industrial customer that is not an abstraction: a single-provider dependency in that window meant an outage in whatever it powered. An architecture where no agent names a model treats this as a configuration change rather than an incident.