01 Always
The cloud account.
Opened in your organization's name, held by you. One organization, one account: isolation is the account boundary itself rather than a tenancy label inside somebody else's system.
The lock-in question, answered before you raise it, with the mechanism behind each answer.
If your AI vendor disappeared tomorrow, would anything still run?
With us, you log into your own cloud and keep running. That sentence is only worth printing if it survives the follow-up questions, so this page asks them: what exactly do you hold, what stops, what would a successor need, and where is the honest limit of this arrangement.
Lock-in is rarely a clause.
THE QUESTION · 01
Procurement looks for lock-in in the contract, which is the one place it is least likely to be. Real captivity is architectural. It is your content sitting in a store you cannot read without the vendor's application, an index you did not build, an identity model that exists only inside their product, and a switch-off that is not a negotiation but a login screen that stops working.
You cannot solve that with a termination clause. You solve it by putting the system somewhere the supplier cannot reach past you. Which is why one organization gets one cloud account, in its own name, with its own root credentials and its own billing relationship, and the platform is deployed into that.
You're not buying seats. You're buying a private AI platform on your own cloud, yours to keep.What the commercial arrangement actually is
Six things that are yours, not rented to you.
WHAT YOU OWN · 02
02 Always
Root credentials.
You hold them. We do not, and at the entry posture no cross-account role for us exists at all. Where management access is granted on a higher tier, it is scoped and session-capped and you can revoke it without asking anyone.
03 Always
The billing relationship.
Your cloud provider invoices you directly at list price. We are not a reseller, we do not aggregate your spend, and we hold no payment relationship with the provider on your behalf.
04 Always
The data.
Documents, the index built from them, the audit and access records, the usage evidence. At rest, in your account, in the region your posture pins. We hold no client content on our own infrastructure.
05 Always
The deployed platform, and its source.
Not only the running system but the code it was built from, with a current copy kept inside your own account rather than in an escrow arrangement with a third party. The ownership terms sit in the service agreement, not in a marketing sentence.
06 Always
Runbooks and infrastructure as code.
Deliverables, not courtesies. They exist because the honest version of "you keep the platform" requires that somebody other than us can operate it, and that is a documentation problem before it is a legal one.
What stops if you stop paying.
ASSET AND SERVICE · 03
Two things are commonly sold as one, and conflating them is how a subscription quietly becomes a dependency. We separate them on purpose. The asset is the deployed platform in your account. The service is us keeping it current, watched and improving. Cancel the second and the first does not notice.
| Question | The asset: the deployed platform | The service: $500 a month |
|---|---|---|
| Where does it live | ✓In the cloud account you own | △With us, as work |
| What you are paying for | ✓Deployment, scoped once | △Managed operations and continuous improvement |
| If you cancel | ✓It keeps running. Nothing switches off | ✕It stops. You lose us, not the platform |
| New releases after that | △You hold the version you have, and its source | ✕Not delivered |
| Who pays the compute bill | ✓You, directly to your cloud provider, either way | ✕Never us |
| Who can operate it | △You, a successor provider, or your own cloud engineer | ✓Us, while the service runs |
Row six is the honest one, and it is expanded below. "You keep the platform" is true and it is not the same sentence as "it runs itself".
Day one without us.
THE HONEST EXIT · 04
What actually happens
Nothing switches off. Several things stop improving.
On the morning after the service ends, your people sign in as usual. Chat works, the knowledge base answers, modules serve, the administration area still governs roles and quotas, and your cloud provider still bills you directly. There is no key that expires and no call home to make.
- 01What stops immediately. New releases, drift and diff checks before changes, the post-deploy acceptance runs, model catalogue refreshes as the provider changes its list, cost watch, and the direct line.
- 02What decays slowly. The model catalogue is the first thing to age, because providers move faster than any static list. Then dependency updates, then the posture drifting from what the plan page says as the provider's own services change underneath it.
- 03What a successor needs. The infrastructure-as-code repository, the runbooks, the architecture records, the committed posture object, the module manifests and their admission parameters, and the operations journal. A competent cloud engineer reads that set and can deploy a change.
- 04What we do at the handover. Confirm the current source copy sits in your account, walk the runbooks with whoever is taking it on, and answer their questions. It is not a heroic exercise, because the artifacts were produced along the way rather than assembled at the end.
The handover setAP-04
- SourceA current copy of platform source, configuration and deployment documents, kept in your own accountKept current while the service runs, not assembled at the end
- InfrastructureThe infrastructure-as-code repository that built what is running
- RunbooksDeploy, onboard, rotate, recover
- ArchitectureThe drawn diagram and the discovered model it was reconciled against
- PostureThe committed control object, with its overrides and their reasons
- ModulesManifests, admission parameters, approved artifact hashes
- JournalThe dated record of what was changed and when
Deliverables·Not courtesies
Three things this does not mean.
THE LIMITS · 05
01
It is not self-operating.
Running it afterwards needs a competent cloud engineer. Not a specialist in our product, but somebody who is comfortable with infrastructure as code, identity policy and a deployment pipeline. If your organization has nobody in that description and no intention of hiring one, the honest reading is that you will want a provider, us or another.
02
It is not cloud-portable.
The platform is built deeply on one cloud provider's managed services: identity, the model service, storage, the policy engine that makes the content policy mandatory. Moving to a different cloud would be a rebuild, not a migration, and anyone who tells you otherwise has not tried it.
03
"Composable" means models.
The word does real work on this site and we keep it narrow. Switching the generation model is configuration, because the model sits behind the platform's own application layer. That is a genuine freedom and it is not a claim about clouds. The mechanism, and its one real coupling.
Why we built it this way
Lock-in would be commercially easier. A multi-tenant platform with your content in our store would be cheaper to operate, simpler to sell and far harder to leave. We took the other road for a practical reason rather than a noble one: the buyer we are built for cannot say yes to the easy version. A security owner who would carry the risk of a shared data plane says no, correctly, and no amount of reassurance changes that. Ownership is what makes the yes possible, so it is the product, not a concession.
What a careful buyer asks next.
THE QUESTIONS THAT FOLLOW · 06
01You are one principal. What happens if he is not available?
The risk is real, and three things bound it. You own the account, the credentials, the billing and the data, so nothing is held hostage while anything is sorted out. The engagement produces infrastructure as code, runbooks and architecture records that another provider can pick up, and those exist today rather than being promised for later. And the platform itself is standardized: every deployment comes from the same tagged releases through the same factory, so a successor is reading one system, not a bespoke build. Continuity in full.
02Is any of this actually in the contract?
Yes. The ownership terms, the treatment of the deployed platform and its source, and the arrangement that keeps a current copy in your own account are written into the service agreement. We do not reproduce contract language on a marketing page, because a clause quoted out of its agreement is worse than no clause. Ask for the agreement at the assessment and read it before anything is deployed.
03What if we want to move to a different provider, not away from the platform?
Then the handover set is the whole story, and it is the same set either way. A regional service provider, a systems integrator you already use, or your own team can take on operations. We have an interest in that being easy: a platform that can only be run by its author is a platform with one customer's worth of future.
04Do you hold any of our content on your systems?
No. Client content lives at rest in the client's own account. What travels outside it is the content of an inference request, which the managed model service processes; the provider documents that prompts are not used to train models and are not shared with the model vendors. That is the narrower and truer statement, and it is the one we print. The boundary, defined.
05What happens to our modules if we leave?
They keep serving. Modules run on their own origins inside your account, admitted at deploy time by parameters that live in your infrastructure code, with their approved artifact hashes recorded. A module your own people wrote is yours in the ordinary sense: you wrote it, it runs in your account, and the authoring kit is not a gate on running what already exists. The authoring path.
The exit, in one line
You lose us, not the platform.
Every other promise on this site is easier to make than that one, which is why it is the one worth checking hardest. Ask for the agreement, ask who holds root, and ask to see the runbooks.
- 01No switch on our side. There is nothing we can turn off that stops your deployment serving.
- 02No content on our infrastructure. Nothing of yours to be held, exported or ransomed.
- 03No heroic handover. The artifacts a successor needs are produced during the work, not after it.
⎯⎯ Book the strategic assessment ⎯⎯
Your private AI, inside your control ·
Bring the lock-in question to the assessment. It is the part of the conversation we most want on the record.