Recover ENTITY from zero infrastructure

This scenario assumes the application workspace, original Git clone, cloud account and venue database are unavailable. The goal is to restore verifiable identity, governed information and logical economic state into a clean environment without creating new authority or silently dropping required state.

Scenario

A provider failure or destructive event removes the original application environment. You retain only the approved protected recovery material: identity/recovery evidence, sealed ENTITY/BTDU state, required market/economic recovery package and verifier material.

1 · Start from a clean destination

Do not restore over an unknown or partially populated destination. Create a clean compatible runtime and record its version/environment before importing authoritative state.

2 · Restore and verify identity first

Recover the Entity manifest/key continuity using the recorded recovery policy. Verify signatures, Entity ID, active verification methods, rotation/recovery continuity and manifest revision before allowing the recovered principal to authorize any mutation.

3 · Replay / reopen governed information state

Open the sealed ADAM/BTDU state using normal verification. Do not disable signature/root checks to make recovery succeed. Validate expected roots/checkpoints before reconstructing governed objects.

4 · Reconstruct exact information where required

For qualified objects, reconstruct bytes and compare cryptographic hashes to the expected object/source evidence. The strong tested Memnox campaign demonstrated 865/865 tracked blobs plus archive, manifest and acceptance proof recovered without the original workspace, Git, GitHub or network. Treat that as bounded evidence for that tested campaign, not a universal guarantee for arbitrary damaged data.

5 · Restore market/economic state logically

Import canonical logical rows and verify semantic hashes for the required state sets:

• venues, instruments, balances, listings and disclosures;
• orders, RFQs, quotes, acceptances, trades and cancellations;
• clearing, entitlements and usage;
• revenue rules, rule sets and trade-revenue bindings;
• authorized settlement verifiers and payment attestations;
• treasuries, participation policies, reserves, obligations and position snapshots where applicable.

6 · Fail closed on partial recovery

If a required table/subsystem, identity attestation, semantic hash or dependency is missing, do not label the destination as a complete recovered market. A partially restored economic history can change meaning if balances, entitlements, revenue rules or settlement evidence are absent.

7 · Verify authority did not expand

Compare recovered principals, delegations, rights and controller relationships to the pre-loss evidence. A new cloud account, database owner, machine administrator or restoration operator must not become the economic or identity authority simply because they performed the restore.

8 · Re-run negative controls

• Invalid/tampered manifest → identity restore fails.
• Atomic/semantic root mismatch → state restore fails.
• Missing entitlement table → market recovery fails closed.
• Unauthorized settlement verifier → settlement remains unverified.
• Concurrent divergent sovereign state → surface conflict; do not silently last-writer-wins.

9 · Produce a recovery qualification record

Record the clean destination, source evidence identifiers, expected/actual roots and hashes, reconstructed object counts, missing/extra/mismatch counts, whether network/original workspace/Git were used, and the final authority/economic-state verification result.

What success proves

A successful drill shows that the application or provider was infrastructure—not the definition of identity, rights or market meaning. Recovery preserves the recorded system while refusing to manufacture missing external truth, rights or settlement evidence.