Emergency External-Seed Recovery¶
Recovery procedure — instantiates Self-Hosted Bootstrap Construction
When the bootstrap chain is lost or found compromised, deliberately reaches outside the self-hosted world — under explicit human authorization — to re-import a trusted seed and rebuild from it.
Self-hosting has a dark side: if the only thing that can build the system is the system, then losing or poisoning that one lineage can leave nothing able to rebuild it. Emergency External-Seed Recovery is the sanctioned break-glass procedure for exactly that state — the chain is gone, corrupted, or no longer trusted, and no internal snapshot is safe to roll back to. It deliberately steps outside the self-hosted world to bring in a fresh trusted seed by an alternate route, and it does so only under explicit human authorization, because re-admitting an external origin is precisely the boundary the whole archetype works to close. Its defining move is the authorized breach: it is the one mechanism whose job is to violate self-hosting on purpose, briefly and accountably, so that self-hosting can be re-established at all.
Example¶
A team discovers their self-hosted toolchain's binary lineage is compromised — a diverse double-compilation check has just diverged — and every internal checkpoint traces back through the suspect builder, so rolling back only restores the poison. Normal recovery is off the table. The break-glass procedure activates: an on-call engineer cannot trigger it alone, because the runbook requires a second authorized owner to sign off on deliberately reaching outside the sealed world. Together they choose an alternate seed path — rebuilding from a minimal, human-auditable seed in the spirit of bootstrappable builds, or re-importing a signed historical release fetched from an independent trusted archive and verified against out-of-band hashes.
From that externally-sourced seed they rebuild the toolchain, then re-enter the normal machinery: an independent check confirms the new lineage is clean, and self-hosting resumes on a fresh, trusted base. The external world was touched once, on the record, with two people accountable — and then the door was closed again.
How it works¶
What distinguishes this procedure from ordinary rollback is that it does not assume anything internal survived. Rollback restores a prior good state; recovery presumes there is no trusted prior state and must reach outside for a new origin. Two things define it: an alternate seed path (a route to a trusted seed that does not pass through the compromised lineage — a re-derivable minimal seed or an independently-archived signed release) and a human authorization gate (the deliberate breach of the self-hosting boundary requires explicit, ideally multi-party, sign-off). It is invoked rarely, by exception, and it hands the rebuilt seed straight back to the normal verification and promotion machinery rather than doing that work itself.
Tuning parameters¶
- Seed source diversity — how many independent alternate seed paths are pre-arranged (a minimal auditable seed, a signed archive, a partner's mirror). More options make recovery robust to any single source being unavailable or itself suspect, but each must be kept trustworthy and current.
- Authorization threshold — how many people, and at what level, must approve the breach. A higher bar prevents casual or coerced use but slows response in a genuine emergency.
- Trust re-establishment depth — how much verification the re-imported seed must pass before it is trusted (signature check, independent rebuild, full double-compilation). Deeper checks are safer but delay the return to service.
- Trigger scope — what conditions are allowed to invoke it (total loss, suspected compromise, failed recovery). A narrow trigger keeps it truly last-resort; a broad one risks normalizing the external reach.
When it helps, and when it misleads¶
Its strength is that it is the escape hatch a self-hosted system otherwise lacks: without it, a single compromised or lost lineage can be unrecoverable, because every internal fallback inherits the same defect. By making the external reach explicit and authorized, it also keeps the breach honest — visible, accountable, and closed again — rather than an ad-hoc scramble improvised during an incident.
Its failure mode is becoming a habit. If reaching for an external seed is easy and unlogged, teams use it to paper over ordinary build problems, and the self-hosting the archetype exists to achieve quietly erodes into permanent external dependence. The re-imported seed is also only as trustworthy as its source — a "recovery" from a tampered archive re-seeds the very compromise it meant to escape. The classic misuse is invoking break-glass for routine failures that a normal rollback would fix, spending the boundary casually. The discipline is to keep the trigger narrow and the authorization real, and to route the recovered seed through full trust re-establishment before it is allowed to become the new base.
How it implements the components¶
Emergency External-Seed Recovery fills the archetype's last-resort re-seeding components — an outside route and a human gate:
alternate_seed_path— it supplies a route to a trusted seed that bypasses the lost or compromised internal lineage entirely.human_stop_and_override_authority— it puts the deliberate breach of self-hosting behind an explicit, accountable human authorization rather than automating it.
It does not perform routine rollback to a known-good snapshot (that's Checkpointed Stage Promotion), verify the re-imported seed's trustworthiness itself (that's Diverse Double-Compilation Check and the sibling Seed-Artifact Signature Verification), or enforce the exclusion boundary it is briefly authorized to cross (that's Clean-Environment Rebuild).
Related¶
- Instantiates: Self-Hosted Bootstrap Construction — this procedure is the accountable escape hatch for when the self-hosted chain itself fails.
- Sibling mechanisms: Checkpointed Stage Promotion · Diverse Double-Compilation Check · Bootstrap Dependency Manifest · Clean-Environment Rebuild · Seed-Artifact Signature Verification · Minimal Rescue-Image Bootstrap
Notes¶
Recovery is not rollback. Rollback trusts that some earlier internal state was good; this procedure is for when that assumption has failed and no internal state can be trusted. Because it deliberately re-opens the external boundary the archetype works to seal, it is intentionally the least-used mechanism in the set — its value is measured by how rarely it is invoked, and its danger by how easily that discipline slips.