Skip to content

Fixed-Point Build Comparison

A build-convergence check — instantiates Self-Hosted Bootstrap Construction

Iterates the self-build until its output stops changing, then checks that successive self-produced versions are identical — the signal that construction has converged.

Fixed-Point Build Comparison tests whether a self-building system has reached a fixed point: feed the system its own source to build a new copy, use that copy to build another, and compare them. When successive self-produced versions come out identical, iteration has converged — further rebuilds add nothing, and the system demonstrably reproduces itself. Its defining move is comparing a system's output against the output of its own output — self-application iterated to stability — rather than against an external reference. It is not about determinism across machines, nor about judging equivalence when bytes legitimately differ, nor about using a second independent toolchain; it is the sharp convergence signal that the self-build has settled.

Example

The three-plate method makes a truly flat reference surface with no pre-existing flat reference to copy: three plates are lapped against one another in rotation, because matching only two can leave complementary curves, while comparing and correcting all three pairwise converges to genuine flatness — a surface that now matches its own copies.[1] It is a fixed point reached purely by mutual comparison, bootstrapped from no external standard. The software form is the three-stage compiler bootstrap: the seed builds stage 1; stage 1 compiles the source to produce stage 2; stage 2 compiles the same source to produce stage 3; and stage 2 and stage 3 must be byte-identical. If they are, the compiler reproduces itself exactly and the build has converged. If they differ, something is nondeterministic or the compiler miscompiles itself — caught before it ships. GCC's build performs exactly this comparison.

How it works

The distinguishing motion is iterating self-application and comparing across iterations: build the system with its own prior output, then again, and diff stage N against stage N+1. A byte-identical match is a fixed point — iteration has stopped changing anything, so you stop. A mismatch is divergence to localise and diagnose. Early rungs may legitimately improve (the seed-built stage is weaker than the self-built one) before the final stages settle, so the check watches for convergence, not sameness at every step.

Tuning parameters

  • Iteration depth — how many self-build rounds before declaring a fixed point (one comparison, or several). More rounds catch slow-converging or oscillating defects but cost builds.
  • Match criterion — strict byte-identity versus a normalised or hashed compare. Byte-identity is the strongest signal but trips on benign nondeterminism — which is better handed to the semantic-equivalence test than tolerated here.
  • Comparison granularity — whole-artifact hash versus per-object diff. Finer granularity localises exactly where divergence enters the chain.
  • Improvement tolerance — whether early stages are expected to differ (and improve) before the terminal stages must match, versus demanding identity throughout.

When it helps, and when it misleads

Its strength is a single, sharp, automatable yes/no: the self-build is stable and self-reproducing. It catches nondeterminism and self-miscompilation cheaply, at the exact rung where they enter. Its limit is fundamental — a fixed point proves convergence, not correctness or trust. Two identically-wrong copies still match, so a compiler that consistently miscompiles reaches a perfectly stable fixed point, and a subverted compiler that faithfully re-inserts its own defect converges just as cleanly. It therefore cannot detect a shared hidden defect; that needs an independent path, which is why diverse double-compilation, not fixed-point comparison, is the defense against a malicious seed. The misuse is treating a green fixed-point as proof of correctness. The discipline is to pair it with an independent-toolchain check for trust and with semantic-equivalence testing for the benign-difference case.

How it implements the components

  • stage_equivalence_and_improvement_test — the comparison is this test: are successive self-produced stages equivalent, and (early on) improving toward the fixed point?
  • self_product_reuse_rule — it exercises self-reuse to its limit, repeatedly building the system with its own prior output to see whether the result stops moving.

It does not make the build deterministic or traceable in the first place (bootstrap_provenance_chain, external_scaffold_exclusion_boundary — Reproducible Bootstrap Build), does not adjudicate equivalence when bytes differ for benign reasons (stage_transition_invariant_set — Stage-Output Diff and Semantic-Equivalence Test), and does not supply the independent second toolchain that would catch a shared defect (independent_stage_verification_path — Diverse Double-Compilation Check).

Notes

Both this and Diverse Double-Compilation Check "compare builds," but they guard different things and should not be conflated. Fixed-point comparison checks identity across self-iterations of one toolchain — it guards convergence and self-reproduction. Diverse double-compilation checks identity across two independent toolchains — it guards trust. A build can pass one and fail the other; a bootstrap that cares about both runs both.

References

[1] The three-plate method bootstraps a truly flat reference surface with no pre-existing flat reference by lapping three plates against one another in rotation until all three match — a fixed point reached purely by mutual comparison. The three-stage compiler bootstrap (stage 2 versus stage 3, byte-identical) is the same idea in software. ↩