Enterprises almost never arrive as a blank slate. They come with a cloud they’ve standardised on, an identity provider they trust, keys they hold themselves, a security team watching one particular dashboard. The instinct — theirs, and honestly most vendors’ — is to treat all of that as an obstacle. We treat it as the test. If our guarantees only hold on our own infrastructure, they were never guarantees. They were hospitality.
So we drew one line and made it the rule everything else bends around: a customer may bring their own substrate; they may not bring their own controls.
Substrate is theirs. Controls are ours.#
Substrate is the swappable plumbing — the databases, the identity provider, the key store, the model, the log sink, the place it all runs. Bring your own; we have an adapter for it. Controls are different: authorisation, tenant isolation, audit, redaction. Those live in the core and never move, no matter whose plumbing sits underneath. The moment a control leaks out into the substrate, the system falls out of its inherited assurance and would need its own separate, expensive assessment — which is just another way of saying the proof stopped being real.
In practice it looks like this. Use your own Azure Entra login — identity is substrate — while sessions, MFA, and the user-to-tenant link stay in the core. Run your own model in your own data centre — substrate, handled by an adapter — while input and output safety, authorisation, redaction, and audit still happen in the serving layer. Stream your audit into your own Splunk — the sink is substrate — while the audit record is still generated in the core. Hold your own keys — custody is substrate — while what gets encrypted, and how, stays with us.
Where the line actually falls, and why it moves nobody#
The line looks obvious written down and is genuinely hard in practice, because almost every interesting request arrives as a reasonable-sounding exception.
A customer asks to use their own redaction service — they have one, it is tuned to their vocabulary, their security team already trusts it. Redaction is a control, so the answer is no; what we can do is let their vocabulary configure ours. Another asks to write audit events directly from their own agent, skipping our serving layer, because it is fewer hops. The sink is theirs, but the generation is not, so again no: an audit record the core did not produce is a record with a gap in it exactly where the interesting question will later be asked.
These conversations are uncomfortable and they are the point. A boundary that yields to a well-argued exception is not a boundary; it is a default. The reason to state it as a single sentence — substrate yes, controls no — is that a single sentence is hard to erode one meeting at a time.
Portability is the proof, not a feature#
This is why we don’t sell portability as a checkbox. It’s the evidence that the guarantee is architectural rather than promotional. A control you can only demonstrate in your own cloud is one you’re asking the customer to take on faith the moment they leave it — and regulated buyers don’t run on faith. Swapping infrastructure has to be a fine adjustment of adapters and a deployment profile, never a rebuild, and the same tests must pass identically in every profile.
The identical-test-suite requirement is doing more work in that sentence than it looks. It is the thing that keeps the promise honest over time, because it fails loudly. A control that quietly stopped applying in one profile does not announce itself; nobody files a bug for a check that no longer runs. But a suite that must pass everywhere turns that silence into a red build. It converts a governance principle into a thing with a status, which is the only form in which principles survive contact with a release schedule.
The objection worth taking seriously#
The strongest argument against this is that it is a way of keeping the valuable part proprietary while calling it a principle. The customer gets to own the commodity — storage, compute, identity — and the vendor keeps the layer that would let them leave.
It is worth sitting with, because the shape is real. Our answer is that the alternative is worse for the customer, not better. If controls were also swappable, then every deployment would be a different system wearing the same name, and no evidence produced by one would tell you anything about another. The value of a standard is precisely that it is not negotiable per deployment. What we can do — and think is the fair version of the concern — is make the substrate genuinely swappable rather than nominally so, and be specific in public about which side of the line each thing sits on. A boundary you can read is a very different thing from a boundary you discover during an exit.
The second objection is simpler: that this constrains what we can support, and some customer somewhere will need something we cannot adapt to. True. That is a cost we accept, and it is cheaper than the alternative of maintaining a guarantee that means something different in each place it is deployed.
How to check this in someone else’s product#
Ask where the audit record is generated, not where it is stored — the two answers are often different and only the first one matters. Ask what happens to redaction when the customer supplies their own model. Ask for the list of things that are swappable and the list of things that are not, in writing, and notice whether the second list exists at all. Then ask whether the same tests run in every deployment profile, and what happens when one fails.
A vendor with a real boundary can produce both lists in a few minutes, because the lists are what the architecture is made of.
The commercial payoff is real, but it’s downstream of the principle: platform choice never loses a deal, because the customer never has to trade “our stack” for “your controls.” They keep their plumbing. They get our proof. And the standard holds in a place we don’t own — which is the only place it ever really mattered.