Skip to content

Staged Self-Host Build

A staged build process — instantiates Self-Hosted Bootstrap Construction

Builds the target as a ladder of stages, each one compiled by the product of the stage below, until the system can build itself and the seed drops away.

Staged Self-Host Build is the spine of the whole pattern: it resolves the chicken-and-egg of "you need the tool to build the tool" by turning construction into a finite ladder. A small trusted seed builds stage 1; stage 1's product builds stage 2; stage 2's product builds stage 3 — and the ladder ends when a stage builds a working copy of itself from its own source, at which point the system is self-hosting and the seed can be let go. Its defining move is self-product reuse: each rung is built by the output of the rung below, so the system progressively takes over its own construction. It is the doing of the bootstrap — not the map of the dependency cycle, not the promotion gate, not the tests that confirm the rungs match.

Example

The Go toolchain replaced its original C implementation with one written in Go. The transition runs as a ladder. The end state is fixed first: a compiler written in Go that compiles the Go compiler (transition_target_state). A known-good earlier Go compiler serves as the seed (stage 0). The seed builds the Go-written compiler (stage 1); stage 1 then compiles the same source again to produce stage 2. Each rung is only allowed to build the next once it demonstrably can — it compiles the standard library and passes the toolchain's own tests (stage_capability_contract). When a stage builds a working copy of the whole toolchain from source, authority hands over: the Go-written compiler becomes the canonical build tool and the C implementation is retired (steady_state_handoff_rule). What was structurally impossible — "compile the Go compiler with the Go compiler" — is reached in a handful of finite, checkable steps.

How it works

The engine is the reuse chain, not a generic build script: the output of stage N is the builder of stage N+1, so trust and capability climb the ladder together. A rung may advance only after meeting its capability contract, which is what keeps the chain from carrying an incapable intermediate upward. The ladder terminates on a defined target — the system building a working copy of itself — and then executes an explicit handoff that transfers the canonical-builder role to the self-built system and drops the seed. Everything else (dependency mapping, verification, retirement) hangs off this spine.

Tuning parameters

  • Stage granularity — few large rungs versus many small ones. More stages isolate where a failure entered but multiply integration and rebuild cost.
  • Seed capability — how much the initial seed already carries. A fatter seed shortens the ladder but widens the surface you must trust before the first rung.
  • Self-reuse point — how early you switch from building with the seed to building with the system's own product. Switching earlier exercises the product sooner but risks building on still-immature output.
  • Handoff bar — how much the self-built system must prove (rebuild itself once? twice? pass the full suite?) before the seed is retired and authority transfers.

When it helps, and when it misleads

Its strength is converting an impossible self-reference into a finite, ordered ladder in which every rung is small, capability-checked, and reachable from the one below — ending in a system that provably builds itself.[1] Its failure modes are the two ways a ladder goes wrong: it never leaves startup mode, because the handoff bar is never met and the project leans on the seed or cross-tool indefinitely; or seed defects propagate silently, since every descendant inherits from its predecessor and a flaw in the seed rides all the way up. The classic misuse is declaring "self-hosting" while the system still quietly needs the seed — a cosmetic handoff hiding a permanent external dependency. The discipline that guards against it is an explicit handoff rule gated on a reproduction check, so the seed is dropped only once the system has actually rebuilt itself.

How it implements the components

  • self_product_reuse_rule — the defining spine: each stage is built by the previous stage's product, so the system increasingly constructs itself.
  • stage_capability_contract — a rung may build the next only after it demonstrates the capability the next rung needs.
  • steady_state_handoff_rule — on reaching self-hosting, the canonical-builder role transfers to the self-built system and the seed is retired.
  • transition_target_state — the ladder aims at a defined end: the system reproduces itself from its own source.

It does not check that successive stages match (stage_equivalence_and_improvement_test — Fixed-Point Build Comparison), nor make the build deterministic and traceable (bootstrap_provenance_chain, post_bootstrap_reproduction_test — Reproducible Bootstrap Build), nor map the dependency cycle it climbs (bootstrap_dependency_graph — Bootstrap Dependency Manifest).

Notes

"Builds itself" and "builds an identical itself" are different claims. This mechanism only has to reach the first: a stage that produces a working copy of the system. Proving the stronger property — that the self-build converges to a byte-identical fixed point — is the job of Fixed-Point Build Comparison, which is why the handoff bar should invoke it rather than trusting a single successful build.

References

[1] A system is self-hosting when it can build itself from its own source using no other implementation — e.g. a compiler written in the language it compiles. Reaching self-hosting is the defined end of the ladder and the point at which the seed can be retired. ↩