Jump to another pillar
VAO · pillar 04 · sovereignty and ownership
Existing SaaS agreements were not written for software that decides and acts. Four questions make them agentic-ready: where it runs, who owns which asset, what may be generalised beyond one account, and whose model gets trained on what.
Part one
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
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
Whether the method taught at this account — stripped of all customer data — 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
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
Part two
Contribution to the library — automatic. The fastest route in.
Contribution to the library — automatic. Only patterns leave, never the customer's data.
Contribution to the library — none automatic. Only through a review the customer runs.
Contribution to the library — none automatic. Everything stays inside: testing, updates, and checking the agents are still getting it right.
Part three
Answered by topology. In C and D, no.
A deployment choice↓
Answered by an enumerated positive list and negative list, enforced by a tested exporter rather than by policy alone.
A technical control↓
Answered by the ownership matrix and the generalisation right. This is the one that decides whether the moat exists.
A contractThe 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.
Model openness
Openness is not one commitment. It is four choices a vertical SaaS company should make deliberately, and most make by accident.
A different model per agent. No agent names a provider. Classification, long-horizon reasoning and drafting have different requirements, and the right model for each changes as the market moves. The gateway decides; the agent never does.
A different model per topology. What runs in a vendor cloud need not be what runs in a customer’s data centre. Hosted deployments can use a frontier model; on-premise and air-gapped ones use open weights the customer controls. Same product, same taught strategies, different weights underneath.
Our own fine-tuned models — as open as the base allows. Post-training an open-weight base on the accumulated library produces a model that knows the vertical. How open that model can then be is not our decision alone: it is inherited from the licence of the base we started from. Apache 2.0 permits redistribution; a community licence may not. This makes base-model selection a strategic choice about future optionality, not a technical one about benchmarks.
A published model for sovereign accounts. For customers who cannot send anything out, releasing the fine-tuned model — weights, and an account of what went into it — turns a trust problem into something inspectable. They run it, test it and satisfy their own regulator without taking anyone’s word for it. The alternative, a closed domain model processed on the vendor’s infrastructure, asks them to trust a contract instead. Both are legitimate; only one survives a serious sovereignty mandate.