Capabilities are contracts.
Providers are configuration.
A default provider is not a permanent one. This page publishes the honest state of that claim, including where it does not yet hold.
Providers are replaceable participants.
Not an ideological position about decentralisation. A statement about which dependencies have a tested way out.
The system asks “which providers satisfy this capability, under these conditions?” rather than “can provider X do this?” That sounds like a small difference and it is the whole difference: a capability stated in our own terms can be satisfied by someone else, and one stated in a vendor’s terms cannot.
- Capability
- Contract
- Registry
- Active provider
- Exit-ready
Couple freely where state is disposable. Couple carefully where state is authoritative.
That rule does most of the work and it saves most of the effort. A projection that can be rebuilt from the record underneath it may be coupled to a provider as deeply as is useful — the exit is a replay, not a migration. Only the authoritative record needs a seam, and it needs a real one.
Where this holds, and where it does not yet.
Generated from the registry at build time. An exit that has never been rehearsed scores as if it does not exist, which is why several rows below are uncomfortable.
| Capability | Active provider | State | Independence | Against target | Alternatives |
|---|---|---|---|---|---|
| event log | gcp-firestore | authoritative | EXPOSED | below target (4) | 1 eligible |
| derived store | gcp-firestore | disposable | PORTABLE | meets target | 2 eligible |
| identity | firebase-auth | authoritative | CAPTIVE | below target (4) | 1 eligible |
| transport | gcp-cloud-functions | disposable | REHEARSED | meets target | 1 eligible |
| intelligence | (none yet) | disposable | REHEARSED | meets target | 2 eligible |
| key custody | provider-managed | authoritative | CAPTIVE | below target (4) | 1 eligible |
| object store | (none yet) | authoritative | EXPOSED | below target (4) | 1 eligible |
| static hosting | (none yet) | disposable | GENERATIONAL | meets target | 2 eligible |
4 of 8 capabilities sit below the level they need. Generated from the registry at build time, so this table cannot show a level the registry does not support.
The levels run from captive, through exposed, portable, rehearsed and substitutable, to generational — where the authoritative record outlives the whole technology category. Disposable state is capped at portable on purpose: chasing a perfect score on something rebuildable is how over-engineering gets justified.
Because a claim of provider independence with no measurement behind it is worth nothing, and because the rows that fall short are the work queue. The one that matters most is the authoritative record: until its export has actually been restored somewhere else, its portability is a hypothesis.
It is measured per dimension, and only one of them counts.
- Nominal
- A different brand name. Worth nothing.
- Commercial
- A different contract and billing entity.
- Operational
- A different control plane and failure domain. A second region inside one provider is not this.
- Jurisdictional
- A different legal regime. Storage location is not jurisdiction — that follows the operator.
- Technological
- A different underlying stack: silicon, model weights, protocol, upstream project.
- Substitutable
- The only one that protects anything. Data and interface can actually move, within a measured time, and it has been demonstrated.
Two consequences worth stating because they cut against intuition. Changing cloud does not buy independence at the technological layer if both options rest on the same accelerator supply. And choosing a widely implemented standard — SQL, the S3 API, plain JSON — increases independence even though it increases correlation. Standardisation is not lock-in; proprietary semantics are.
Failing over is not replacing.
Availability failover
Provider replacement
No active-active multi-cloud, no policy engine with no policies, no jurisdiction engine with one jurisdiction, and no provider marketplace. The registry is an infrastructure governance mechanism, not a product, and it is a file in the repository reviewed on a schedule rather than a service. Recovery paths are rehearsed and cold, not warm and expensive.