Sovereign Export & Portability
Provider independence is only credible if authoritative state can leave one environment, be recovered elsewhere and produce the same verification/authorization conclusions.
Export contents
A sovereign export should contain or reference the identity manifests, required verification material, rights/passports, provenance/evidence, event state, applicable profiles and the minimum metadata required to recover interpretation under the correct protocol version. Secrets should be encrypted/protected according to the export design rather than mixed into public metadata.
Portability test
- Create export from environment A.
- Hash/sign the export or its manifest.
- Transfer without relying on provider A during recovery.
- Recover in environment B.
- Verify the same Entity ID and key continuity.
- Verify historical rights/evidence/passports.
- Compare semantic/content roots or deterministic conclusions.
- Prove new authorized signing/operation from the recovered state.
Provider rule
DNS, cloud accounts, databases, nodes and discovery systems may help locate or transport state; they do not become sovereign authority simply because the export used them.
Independent interoperability
The strongest portability milestone uses an independently authored implementation to recover and reach the same conclusions. BTG-controlled cross-language baselines are not a substitute for that external evidence.