two reducers, one answer
18 starting shapes go into two implementations of the same reducer, one live in the kernel and one a pinned 12,925-byte compiled file, and both land on the same finished form every time, with every state and step counted along the way.
the takeaway in one paragraph
The lab's kernel holds one reducer for a structure called a Piece, and Codebox holds a second reducer for the same kind of structure, called a Cell — a compiled WebAssembly file on disk, 12,925 bytes, pinned by its own sha256 hash. Feed both reducers the same starting shape and let each run to its own finished form. Across all 18 connected closed starting shapes in the kernel's own live builder family, the two reducers land on the same finished form every time. The match is one exact digest equal to another.
The file holds 18 tests. All 18 pass, 0 fail, 0 skipped, in `research_worker/test/kernel.parity-cell-wasm.test.ts`. That 18 is a separate count from the 18 starting shapes swept inside it — one number sizes the test file, the other sizes the family of shapes the file checks. Both land on 18.
the everyday problem
The same lab can write two different implementations meant to do the same job, in two different languages. Agreement on one example proves little. Real agreement means every input in the field you care about gets run through both programs and the outputs compared directly.
Here the two programs are two reducers over the same computational structure: one called a Piece, live in the kernel's own source, and one called a Cell, a file compiled separately and shipped in Codebox. The Piece reducer executes directly in the current process. The Cell reducer, for this comparison, runs inside a WebAssembly worker with a timeout, its bytes checked against a pinned sha256 hash before anything executes. The comparison is whether the finished form matches.
how the sweep runs and what it counted
`selectConnectedClosedPieceSeedsV1` enumerates the starting shapes directly from the kernel's own live builder parameter space, keeping only the shapes that are connected and closed. The enumeration produces exactly 18 seeds, from `0/0/2@1` through `3/1/4@0`.
Each seed runs to its own normal form twice inside `runPieceCellWasmCorrespondenceV1`, once by the kernel's Piece reducer and once through the actual Cell WASM bytes. Agreement is one exact digest equal to another, `cell_normal_form_ir.canonical_digest` against `piece_normal_form_ir.canonical_digest`.
- lowers the Piece net to canonical Radix IR
- encodes it into the Cell's flat ABI
- executes the pinned `reducer.wasm` behind a Worker timeout
- strictly decodes the result
- lowers it back to Radix IR
A separate sweep, `sweepFamily`, walks the same 18 seeds inside the kernel alone and counts five things. `reduceToNormalForm` runs there too, tracked step by step, and feeds the longest-path and widest-point maxima.
- every state visited
- every reduction step taken
- every local two-redex diamond checked for confluence
- every distinct canonical form seen along the way
- every place a diamond, well-formedness, port-invariance, or disjointness check could have failed
The full count, from `kernel.parity-cell-wasm.test.ts:150` through `:172`:
| what the sweep counted | value | line |
|---|---|---|
| starting shapes (seeds) | 18 | :150 |
| states visited | 82 | :151 |
| reduction steps taken | 64 | :152 |
| local two-redex diamonds checked | 149 | :153 |
| diamond checks skipped for budget | 0 | :154 |
| distinct canonical forms seen | 41 | :155 |
| reduction-break defect events | 0 | :156 |
| diamond, port-invariance, well-formedness and disjointness check failures | 0 | :157 |
| longest single reduction path | 15 steps | :171 |
| widest point of parallel active pairs | 6 | :172 |
The same test then runs the 18 seeds again with the reduction steps offset against each other: 72 runs, 256 reductions, 0 synchronization stalls, 0 normal-form mismatches. The pinned Cell reducer itself is `apps/dashboard/public/wasm/cell/reducer.wasm` in codebox-os: 12,925 bytes, sha256 `6333f63c32d82e71afbf92ec460028a518f3eca51e138506461ca561743715bc`, tracked in that repo since the commit that pinned it, though the kernel's own artifact label still reads untracked from before that commit landed. Reproduce with `node --env-file=.env --test test/kernel.parity-cell-wasm.test.ts`.
what this does not cover
- exhaustive for the kernel's own connected, closed seed family, and for that family alone
- correspondence, per the lab's own `laws/piece-cell-normal-form-correspondence`, not isomorphism: reduction history and allocation order are never reconstructed, only the finished form is compared
- the Cell reducer is pinned by one sha256 hash, and this note checks that one build of it and no later build codebox ships
- whether the two reducers agree on any topology outside this connected-closed family — this sweep does not test that, and does not claim it
- a case where either reducer fails to terminate or times out — none of these 18 seeds hit that path, so this sweep says nothing about what happens when one does
- the shared kernel code that canonicalizes both finished forms before the digests are compared — a bug there would appear on both sides and this sweep could not see it
- the case where the Codebox artifact is missing from disk — the test skips rather than fails then, and the 0 skipped here is what makes the 18 passes mean anything
the next gate
The match holds for 18 starting shapes and reduction paths up to 15 steps long. The next gate is the same comparison run against topologies outside this family, until it either holds or breaks.