A control that only holds in our cloud is not a control.

Enterprises want their own cloud, their own keys, their own models. The trick is letting them swap the plumbing without ever letting the controls leak out with it.

by Naveen Tewari · a stringify ai perspective

Enterprises almost never arrive as a blank slate. They come with a cloud they’ve standardized 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: authorization, 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 certification and would need its own separate, expensive audit — 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 center — substrate, handled by an adapter — while input and output safety, authorization, 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.

If proof only works on the vendor’s turf, it isn’t proof. It’s marketing.

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.

A deployment profile is a coherent bundle of adapter choices plus a control tier. Change the profile — their cloud, their keys, their model — and the identical test suite still has to pass. That’s the difference between a port and a rewrite.

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.

one standard · inherited two ways · proven the same

one standard · inherited two ways · proven the same