every order, same answer

the takeaway in one paragraph

The lab runs a build pipeline of 15 stages. Some stages do not depend on each other, so there are 88,808 legal orders to run them in. We froze the 15 already-computed stage values into one cache and applied that cache, stage by stage, in every one of the 88,808 legal orders. Every order applied without a HOLD, and the per-stage digest matched the first order's every time.

the everyday problem

A build pipeline is a list of steps where some steps need an earlier step's output and some don't. When two steps don't depend on each other, either order is legal. The worry is what happens to the answer when the schedule changes. If running the same 15 steps in two different legal orders produced two different final digests, the pipeline's own output would depend on which order the scheduler happened to pick that day.

how it works

The pipeline's dependency graph resolves to 160 dependency-closed combinations. The search that found them ran on four worker threads. Expanding those combinations into full topological orders gives 88,808 legal schedules over the 15 stages. Rerunning all 15 stage builders inside each of those 88,808 schedules would mean rerunning filesystem reads 88,808 times over, so the check replays the frozen outputs instead.

• First, the 15 already-computed stage outputs are digested and frozen into one cache.
• Second, a closed operation resolver applies that frozen cache, stage by stage, in every one of the 88,808 legal orders: 1,332,120 individual stage applications in total.
• Third, the frozen cache and the memo key it feeds carry no term that varies with schedule order, so memoization catches all but 15 of those applications: 15 source-bound evaluations, 1,332,105 cache hits.

One of the 88,808 orders is then replayed with the memo turned off, and it lands on the same complete-state digest. That is one order, not all of them.

The 88,808 schedules are then bucketed into 45 shards — 45 is the fixed cap in the code, not a count the run discovered — and each shard is assigned the same digest already found for the first order. The 990 pairwise comparisons that follow are arithmetic on that assignment, not a second, independent check.

A separate test drives the same comparator with a deliberately order-sensitive operation, and it returns a named HOLD with two different state digests and one identical terminal digest. That test turns the memoization off. The 88,808-order run reported here leaves it on.

The lab's canon records this as the executed entry `evidence/parity-cached-operation-confluence`, filed against the confluence law `laws/parity-cached-operation-confluence`. The relation `relations/witnesses-parity-cached-operation-confluence` binds the implementation and that evidence entry to `laws/holonomic-confluence`, the target law it records.

what this does not cover

The check is bounded on purpose, and the law that governs it says so directly: `laws/parity-cached-operation-confluence` states it is 'only about pure cached-artifact maps' and grants 'no external-builder, provider, filesystem, database, deployment, Bend/HVM, or Cell schedule-confluence claim.'

• The per-stage digest each order is checked against is built by sorting the applied stages by name and hashing memoized values that do not change between orders. The match holding on all 88,808 orders is a property of that construction, as much as it is a property of the run.
• The 15 stage builders ran once, in their own deterministic build order. Those builders are the filesystem reads, the work that touches the outside. The 88,808 legal orders replay their already-computed outputs, not the builders themselves.
• The comparison checks the state digest and the terminal digest. A third digest, the trace digest, is computed for every run and does record the order stages were applied in, but it is never part of the comparison.
• The confluence law also requires the check to terminate, and it states plainly that terminal-output equality alone is not enough. This note reports per-stage digest equality across 88,808 completed orders, not a separate termination proof.
• The canon entries behind this note are filed with status draft.
• A fresh rebuild today does not reproduce the digest committed in the docs. The fresh run gives semantic digest `sha256:962105b1...`. The committed build carries `sha256:bbc127f2...`. The registry input digest also moved, from `sha256:ec8fe9b5...` to `sha256:78e5a934...`, since the docs were last committed. The 88,808-order confluence result held on today's inputs.

the next gate

The 15 stages counted here are one pipeline. The next gate points `research_worker/scripts/build-parity-convergence-pipeline.mjs` at a second pipeline's registry and reports its schedule count and digest the same way. For this pipeline, the digest a fresh rebuild produces today does not match the digest committed in the docs. The registry input moved since the docs were last committed, and the 88,808-order confluence result held on today's inputs.

• note 10 · composition is not additive
• note 11 · constructed, not trained
• note 36 · networks of algebras