Run a provider-independent recovery drill
A recovery test is successful only when the logical authority, information and economic meaning survives—not merely when a database file can be copied. This drill separates identity continuity, BTDU reconstruction and market/economic-state recovery.
1. Capture the baseline
Before simulating loss, record the state you expect to recover.
- Entity ID and verified public manifest
- BTDU atomic root and selected object SHA-256 values
- repository/object manifests needed for reconstruction
- market semantic hashes for required logical tables
- balances/positions, open and historical execution state
- entitlements and usage state
- revenue rules/rule sets and trade-revenue bindings
- settlement-verifier authorizations and payment attestations
- economic participation state: treasuries, reserve allocations, obligations and position snapshots
2. Produce the recovery material
Use the current operator backup/export and market-recovery procedures to produce a protected recovery set. Keep identity/key material separate from public evidence. For market recovery, preserve canonical logical rows, semantic hashes, identity manifests and controller attestations rather than treating database bytes themselves as the authority.
3. Simulate provider/workspace loss
Move the working copy aside or restore into a clean compatible destination. The important property is that the recovery destination does not depend on the original application's live database or workspace.
For a stronger BTDU test, select at least one object whose original workspace copy is unavailable to the recovery process and require exact reconstruction from governed state.
4. Restore identity and governed state
- Restore/verify the Entity public identity and authorized private key material using the protected operator procedure.
- Open the recovered BTDU/ADAM state and verify its root before mutation.
- Restore the market snapshot into a clean compatible destination.
- Restore economic participation state alongside exchange state.
- Reject the recovery if a required subsystem/table is absent instead of treating a partial market as complete.
5. Verify the recovered system
| Layer | Verification |
|---|---|
| Identity | Manifest and continuity proofs verify; recovered keys have no broader authority than before. |
| BTDU | Atomic root/state verifies and selected reconstructed objects match expected SHA-256 exactly. |
| Market structure | Venues, instruments, balances, listings and disclosures match semantic hashes. |
| Execution | Orders, trades, RFQs, quotes, acceptances and cancellations are preserved. |
| Post-trade | Clearing, entitlements, usage, verifier authorizations and payment attestations are preserved. |
| Economics | Revenue rules, treasuries, allocations, obligations and participation state survive. |
6. Run negative checks
- Alter one logical row and confirm semantic verification fails.
- Remove one required market subsystem and confirm restore fails closed.
- Attempt to restore into a non-clean conflicting destination and confirm the procedure refuses silent merge.
- Confirm missing external payment evidence remains missing after recovery.
- Confirm recovery does not create ownership or new rights.
7. Compare with the qualified destruction-recovery result
The public BTDU evidence includes a stronger qualified case in which the tested Memnox campaign recovered 865/865 tracked blobs plus archive, manifest and acceptance proof without the original workspace, Git, GitHub or network. Your tutorial run should use the same principle: define what must survive, remove dependencies, reconstruct, then compare exact evidence.
8. Success criteria
- Identity continuity verifies.
- Selected BTDU content reconstructs exactly.
- All required market/economic logical state is restored.
- Semantic hashes match the baseline.
- Negative cases fail closed.
- No new authority, rights, settlement or ownership claims appear merely because recovery succeeded.