iter 14 — row-order invariance holds FIXED

Attack item X-3 · 2026-07-30 · harness harness/row_order_invariance.py · gate /xi:order-invariance

Why X-3 was aimed here rather than at "byte-identical double run"

Read literally, X-3 would pass vacuously — every harness in this campaign is seeded. The version that can actually fail, and that this loop has a direct stake in, is the metamorphic one: re-order the rows without changing their content; the verdict must not move.

The stake is mine. Iteration 1 (PR #674) changed the fetch from ORDER BY close_time_us DESC to ORDER BY close_time_us DESC, first_agg_trade_id DESC. That was done to make the row set deterministic under a LIMIT — but it also changes the row order for every row tied on close_time_us, and BTCUSDT@250's window carries 40,054 such ties. If ξ were order-dependent, that "pure correctness fix" would have silently moved verdicts. I made the change, so I am not willing to leave the claim untested.

Result 1 — the estimator's claim verified, both directions

  x ties   content-addressed    positional (default)
   0.000     |diff| 0.00e+00         |diff| 0.00e+00
   0.100     |diff| 0.00e+00         |diff| 1.71e-03
   0.309     |diff| 0.00e+00         |diff| 4.47e-04
   0.950     |diff| 0.00e+00         |diff| 5.27e-03

negative control: positional tie-break moved in 3/3 tied cases -> gate can fire

Content-addressed keys give exact invariance — 0.00e+00, not "small", at every tie rate including the 0.95 rate-valued-kernel shape. The positional default demonstrably does not, which is what makes this a gate rather than a formality.

Worth sizing: the positional drift reaches 5.27e-03 at the rate-kernel tie rate. The ξ PASS moat is 0.006. So under the positional default, merely re-ordering rows could move a verdict almost the full width of the moat. That is what the content-addressed fix bought, quantified.

Result 2 — PR #674's re-ordering moved nothing

xi_max_pair   before 0.353897485246   after 0.353897485246   |diff| 0.00e+00   -> unchanged

Replaying the exact permutation the ORDER BY change induces — rows tied on close_time_us, re-sorted by first_agg_trade_id — leaves ξ bit-identical. Iteration 1's substrate fix did not move verdicts through this mechanism. Verified, not assumed.

Result 3 — through the cascade's own entry point

before xi=0.338218625462 stable=True    after xi=0.338218625462 stable=True   -> IDENTICAL

Both the value and the stability flag survive a joint permutation, so the invariance holds through xi_cell_vote_stable, not merely through the bare estimator.

A self-consistency check that fell out of building this

Section 2 needed an identity key for the rows, and the natural candidate — close_time_us — is duplicated by construction in that scenario, since the whole point is rows tied on it. So the harness uses the unique key instead. That is precisely the degeneracy iteration 1's G2 gate now refuses (assert_deduplicated rejects a non-unique identity column, because row_identity_keys silently degrades on it). The campaign's own gate and this harness independently arrived at the same requirement.

What landed

/xi:order-invariance, wired into /xi:check-full and verified by /xi:doctor. Unlike X-2 — which is real but currently failing, and was deliberately kept out of the suite — this one passes, so it belongs in the gate set. The full suite runs green: oracle parity exact to 2.44e-15, shuffled null clean both directions, row-order invariance exact.

Zero free parameters. No dial, band or threshold touched.

Limits

• Synthetic data throughout. The invariance is a property of the estimator's tie-break mechanism, not of any dataset, so this transfers — but the specific drift magnitudes (1.7e-03 to 5.3e-03) are for these designs and would differ on real cells.
• Only ξ was tested. h_norm, ρ and panel-R² have their own order sensitivities and were not examined; this establishes invariance for the binding stage, not for the whole cascade.
• The #674 replay is a simulation of the ORDER BY permutation, not a re-run of the real fetch — which would need a wide bigblack read. It reproduces the permutation structure faithfully; it does not prove the production path is identical.

Evidence: harness/row_order_invariance_evidence.json. Reproduce: mise run xi:order-invariance