Validation report
Don't take the demo's word for it.
The Cycle Conductor demo shows one cohort reproducing itself. That's a demonstration, not a verification: it only proves the engine agrees with itself. This page is the verification: 2,300 generated cohorts, each checked against an exact solver implemented independently of the one that ships, plus evidence that the checker itself is capable of failing.
01: What gets checked
Three questions, asked of every cohort.
A · Optimality
Is the chosen pairing really the cheapest one?
The engine's cost is compared against a minimum-weight perfect matching computed by a separate algorithm. If any cheaper pairing exists, the check fails and names the gap.
B · Exhaustiveness
Did it actually look at every pairing?
A pool of n people has (n−1)!! possible perfect matchings. The engine reports how many it evaluated; the check asserts that number is all of them, not a sample that happened to land well.
C · Determinism
Does it do the same thing twice?
The same roster and history are run through the engine twice and the pairings compared. Same inputs, same output, every time, or the check fails.
02: Why the reference is independent
A solver that checks itself proves nothing.
The engine finds its optimum by walking a recursive generator over every perfect matching. The obvious way to test that is to enumerate the matchings and confirm the minimum, but that re-runs the same code path and would agree with itself even if the traversal were wrong.
So the reference is a different algorithm: a bitmask dynamic program over subsets, written from scratch in the harness. It shares no code with the engine beyond the cost function itself. Two independent implementations landing on the same number is evidence. One implementation agreeing with itself is a tautology.
03: Results
2,300 cohorts. No disagreements.
| Run | Cohorts | Pool sizes | Optimality agreement | Worst gap | Failures |
|---|---|---|---|---|---|
| seed 11 | 2,000 | 4 to 10 | 100.00% | 0.00% | 0 |
| seed 12 | 300 | 4 to 12 | 100.00% | 0.00% | 0 |
Every cohort is generated with a seeded random roster, a randomised meeting history, and, in half the cases, a populated fairness ledger, so the tie-break path is exercised too. Determinism and exhaustiveness passed on all 2,300.
04: Same cohort, scrambled rows
Row order is not an input. That had to be earned.
Check C proves the engine repeats itself when handed the same roster twice. In July 2026, a stress-test of a stronger claim — the same roster with its rows in a different order — failed: 44 of 60 order-variants produced a different pairing, every one at identical cost. Nothing ever looked wrong, which is exactly why it hid: never a worse answer, only a different equally-optimal one.
Two independent mechanisms, both order leaks: the seeded shuffle ran on the rows as the
caller handed them in, and the optimiser keeps the first minimum it meets, so
enumeration order decided among equal-cost optima with no randomness involved at all. A
database query with no ORDER BY guarantees neither. Fixed 2026-07-28/29 by
canonicalising the pool before the shuffle; the measurement above lives as a comment beside
the fix in assets/engine.js.
With JavaScript enabled, the demo below re-runs that experiment on the engine this site ships: the same twelve people, handed over in a different row order on every click. The shipping engine's hash never moves; a labeled reconstruction of the removed defect diverges beside it — always at the same cost. The permutations are seeded, so any run you see is reproducible from its settings line.
The reconstruction is labeled because it no longer ships.
The "pre-fix rebuild" arm re-creates the removed defect by skipping the canonical sort — same primitives, one step withheld. It exists so the readout can refuse: if that control arm ever stops diverging, or the shipping arm ever moves, the demo reports itself broken instead of staying green.
05: The checker is checked
A validator that can't fail isn't a validator.
A green result is worthless until you've watched the same harness go red. So a deliberately
suboptimal solver (greedy nearest-partner) ships alongside it, and --selftest
demands that the harness catch it:
Same discipline as a smoke alarm you press the button on. The check that never fires and the check that always fires look identical from the outside.
06: What this does not prove
The boundaries, stated plainly.
It validates the search, not the cost model.
The engine and the reference solver share the same pairCost function. So this
proves the optimiser finds the cheapest pairing under that cost model. It does not
prove the cost model encodes the right priorities. That's a design judgment, argued on the
Method page, not something a solver check can settle.
It covers pools up to 12, not production scale.
Exhaustive verification is only tractable while the number of matchings stays small: (11)!! is 10,395, but it grows fast. These runs cover pools of 4 to 12.
The large-scale solver has not been measured yet.
Above the exhaustive ceiling, a seeded simulated-annealing solver takes over in production.
That solver is not covered by the runs on this page. The harness accepts it
as a drop-in (--solver) and will report its agreement rate and optimality gap
against the same independent reference; until that run is published, treat the annealer's
quality as unverified here.
07: Run it yourself
The button, not the promise.
The engine and the harness are in the repository. Nothing here needs to be taken on trust:
node scripts/validate-solver.js --selftest
# reproduce the headline result exactly
node scripts/validate-solver.js --cases 2000 --seed 11
# push it further: more cohorts, deeper pools, any seed
node scripts/validate-solver.js --cases 5000 --seed 99 --max-n 12
# scrambled rows: prove row order can't change the answer — and that the check can fail
node scripts/verify-run-it-twice.js --selftest
node scripts/verify-run-it-twice.js
Same seed, same numbers, on any machine. If it ever disagrees with what's published here, that's a bug worth telling me about: kira@ousios.dev.