iteration 07 ยท card 59 S2+S3 kernel ยท batch-6 implementation ยท 2026-07-02
Card 59 โ Rust kernel matches the answer key to the last binary digit S3 DONE ยท BIT-EXACT
← campaign board ยท previous: iter 06 (the answer key)
In plain language โ what happened this iteration
The fast engine version of "how long until price comes back?" was built and proven โ and this time the match isn't just within a hair's width, it's PERFECT. Feature 1 (Hoeffding) matched its reference to within ~0.0000000000001 โ spectacular, but with a sliver of rounding daylight from summing 40,000 tiny numbers. Feature 2 involves only comparisons ("is this close at-or-above that one?") and one division at the end. Comparisons have no rounding at all โ so the Rust engine reproduced all 19,602 frozen reference answers on Bitcoin and Ethereum to the last binary digit. Zero difference. Not "close enough" โ identical.
The engine version is also 200ร more efficient than the reference. The reference checks every bar against every later bar (up to ~20,000 comparisons per window). The engine uses a classic trick โ a "monotonic stack": walk the window once, keeping a short list of bars still waiting for their level to be reclaimed; each new bar instantly resolves everyone it out-prices. Every bar enters and leaves the list exactly once โ one pass, same integers. To make sure the clever version can't hide a bookkeeping slip, the dumb-but-obvious version lives on inside the test suite and both must agree bit-for-bit at four different window sizes, forever.
One structural difference from feature 1: this feature reads only closing prices, so it plugged into the standard 200-bar window machinery every earlier feature shares โ that machinery's record simply grew from 12 features to 13. Twelve existing plumbing points and the causality/determinism test drivers were widened by one slot, and โ a genuinely obscure corner โ Rust refuses to auto-print records wider than 12 fields, so two error-message sites needed a small reshaping. The compiler caught every single spot: this is why the record is a strict tuple rather than something loosely typed.
The watchdog is red again โ on purpose, again. The schema-contract test noticed the engine now computes a 14th bar-close measurement that the database blueprint doesn't yet list. That wiring is the next iteration's job, and the watchdog stays red until it's complete. Everything else: 42 of 43 suites green.
Grounded this iteration
S2+S3 for bar_hvg_forward_visibility_horizon_mean: monotonic-stack O(n) kernel in
bar_close_features.rs; 5-test battery green (naive-vs-stack bit-equality at n=5/23/61/200,
exact closed-form anchors incl. hand-pinned 5/3, positive-scale bit-invariance, determinism+bounds,
NaN policy incl. all-censoredโNaN); BIT-EXACT oracle gate GREEN on BTC+ETH (residual 0) via the
STANDARD walk โ extended 12โ13 columns (9 selectors, robustness drivers, warm-up test, 13-tuple Debug
workaround). S4 processor-core complete; regression sweep 42/43 (the 1 red = the intended schema-contract
tripwire).
Next fire picks up here
S4 write surfaces (the #556 guard): manifest 14th bar_close entry โ schema.sql +
column_comments.py + constants.py โ arrow_export.rs โ
helpers.rs dict โ row.rs/dead_letter.rs โ tripwires 86โ87 (Arrow) /
91โ92 (CORE_COLUMNS + py mirror) / compat 66โ67 & 13โ14 (the card-78 challenge taught us not to forget
these) โ schema-contract + completeness back to green. Note: the standard-driver harness lanes
(causality/determinism, now 13 columns) ALREADY exercise the new column; S10 parity test extension +
S12 ADR + S13 hvghorizon:* namespace + S14 + S15 challenge + S16 stacked PR (base =
feat/bar-orth/batch6-78-hoeffding). Worktree: ~/eon/odb-worktrees/batch6-59-hvg-horizon,
uncommitted, ledger is truth.