Post-Bootstrap Artifact-Retirement Audit¶
A post-bootstrap retirement audit — instantiates Self-Hosted Bootstrap Construction
After self-hosting is reached, checks off every bootstrap-only seed, cross-tool, and scaffold and confirms the running system depends on none of them.
Post-Bootstrap Artifact-Retirement Audit is the closing checklist, run once the system can build itself. It enumerates every artifact that existed only to get the bootstrap moving — the seed binary, the cross-compiler, temporary trust anchors, parallel-build scaffolding — and verifies, item by item, that the steady-state system no longer depends on any of them, then retires each. Its defining move is turning "we think we're self-hosting" into a checked inventory of removed scaffolding with a residual-dependency test attached to every line. It confirms the scaffolding is gone and shrinks what must be trusted; it does not sequence the build, prove reproduction, or verify the seed — it consumes those results and closes the loop.
Example¶
A release-engineering team has just brought a toolchain to self-hosting. The audit walks the list. Is the seed compiler still referenced anywhere in the build graph? Does any package still pull the cross-compiler? Are the temporary bootstrap signing keys still trusted? Is the "build old and new in parallel" scaffold still wired into CI? For each line, they trace the current dependency graph, then prove non-dependence the hard way — a clean rebuild with the item deleted — and only then remove it, shrinking the surface that has to be trusted and maintained.[1] Anything that cannot be removed without breaking the build is flagged as a genuine, not-yet-retired dependency: it means the bootstrap is not actually finished, whatever the milestone said.
How it works¶
The distinguishing discipline is enumerate-prove-retire, not inspect-and-assume. Every bootstrap-only artifact is listed; for each, the system is shown to build cleanly without it (ideally by a real rebuild, not a grep); confirmed-inert artifacts are retired; and any artifact that cannot be removed is surfaced as an unfinished self-hosting dependency rather than quietly kept. The output is a closed checklist plus a short list of exceptions that block "done."
Tuning parameters¶
- Retirement scope — what counts as a bootstrap-only artifact (seed, cross-tool, temp keys, parallel-build scaffold). A wider net removes more hidden dependencies but risks retiring something still load-bearing.
- Removal-proof strictness — how non-dependence is established: grep the graph, or a full clean rebuild with the item deleted. A real rebuild is decisive but expensive.
- Retire versus archive — whether artifacts are deleted or archived for possible recovery. Archiving preserves a fallback at the cost of a lingering (though inert) reference.
- Timing — how long after declared self-hosting the audit runs. Too early and recovery paths vanish before the system is proven; too late and dead scaffolding calcifies into permanent trust.
When it helps, and when it misleads¶
Its strength is closing the bootstrap honestly — it is what distinguishes a system that truly self-hosts from one still quietly leaning on its seed, and it shrinks the trusted, maintained surface to what the steady state actually needs. Its failure modes are symmetric. Retire too aggressively or too early and you destroy the recovery path — the rescue image, the rollback — before the self-hosted system has proven stable. Leave the audit undone and opaque bootstrap dependencies accrete into permanent, unexamined trust that no one remembers to question. The classic misuse is rubber-stamping the checklist to declare the project "done" without ever rebuilding with the artifacts removed. The discipline is to gate retirement on a passing reproduction check and to prove non-dependence by rebuilding without the artifact, not by inspection alone.
How it implements the components¶
bootstrap_artifact_retirement_rule— it operationalises which bootstrap-only artifacts get retired, on what evidence, and when.external_scaffold_exclusion_boundary— it verifies, after the fact, that the steady-state system depends on no undeclared bootstrap scaffold, enforcing that boundary as a checked property rather than an assumption.
It does not build the stages (self_product_reuse_rule, stage_capability_contract — Staged Self-Host Build), does not itself prove the system reproduces (post_bootstrap_reproduction_test, stage_equivalence_and_improvement_test — Reproducible Bootstrap Build and Fixed-Point Build Comparison), and does not define the steady-state handoff it presupposes (steady_state_handoff_rule — Staged Self-Host Build).
Related¶
- Instantiates: Self-Hosted Bootstrap Construction — performs the honest close-out that separates real self-hosting from a hidden lingering dependency on the seed.
- Consumes: Reproducible Bootstrap Build and Fixed-Point Build Comparison — their passing reproduction result is the precondition for retiring anything.
- Sibling mechanisms: Staged Self-Host Build · Reproducible Bootstrap Build · Minimal Rescue-Image Bootstrap · Checkpointed Stage Promotion
References¶
[1] A system's trusted computing base is the set of components that must be trusted for it to be secure; retiring bootstrap-only artifacts shrinks that base, removing things that would otherwise have to be trusted and maintained indefinitely. ↩