DashboardCrypto candidatesCost-Realism Labels › iter 06

iteration 06 · PR-B authoring · crypto cost-realism labels · 2026-07-14

The blueprint and the machine — written, reviewed by tests, and deliberately never switched on AUTHORED · ALL GATES GREEN

← campaign board · ← iter 05 · PR #618 (PR-A) · issue #614

In plain language — what happened this iteration

Peer B exists now. On a second isolated workbench (stacked on top of Peer A's, since it reuses the single source-of-truth column list), we wrote everything needed to actually put the labels into the database — but, crucially, as reviewable files that the automation never executes. The database table definition (CREATE TABLE) is a file a human will run once after review. The backfill program — the machine that will eventually label ~139 million historical bars — is written, argument-checked, and importable, but it has a dry-run default and has never been run here.

The safety lessons got baked in. Every hard-won lesson from Peer A's adversarial review became a structural property of Peer B: the tick feed must arrive strictly in trade-ID order with no duplicates (the Rust boundary now REFUSES anything else — a loud error, not a wrong number); millisecond timestamps from the disk cache are converted to microseconds, and the boundary rejects any timestamp that looks like the wrong unit; bars too close to the newest data ("live edge") are held for the next run instead of being labeled with incomplete windows; the derived round-trip-cost column is computed by the database itself from a formula stored in the table, so it can be re-tuned without touching code.

The last five anti-leak guards are live. Guards B and C prove no label ever appears in the feature manifest or the feature column lists. Guard F freezes the four "tripwire" numbers proving the existing bar pipeline is untouched (126/93/93/68 — all unchanged). Guard H pins the audit playbook. Guard I teaches the candidate-intake tool to flatly refuse any label_* name — labels can never even be nominated as ML features. Plus two "lockstep" tests that byte-compare the SQL file's column descriptions against the single source of truth. All 18 guard tests green; the full gate suite green; zero bytes of oracle drift.

What's next: Peer B gets the same adversarial wrecking-crew treatment as Peer A, any held findings get amended, and pull request B opens — stacked on PR #618 — completing the loop's mandate. Everything after that (merge, table creation, the pilot on SUIUSDT, the full backfill) is human-owned.

Grounded this iteration

python/opendeviationbar/clickhouse/labels_schema.sql: CREATE TABLE (RMT(computed_at), PARTITION/ORDER BY mirroring the parent, ouroboros_mode declared — resolving the ADR D1 sketch inconsistency), inline COMMENTs byte-locked to the spec SSoT (guard-tested with '' unescaping), D5 DEFAULT roundtrip expression, operator maintenance notes (mutations_sync, DROP PARTITION rollback, fee-swap ALTER), plus the open_deviation_bars_with_labels VIEW (LEFT JOIN with consistency-column match). scripts/backfill_labels.py: stripped repair_direct_parquet fork — per-symbol sequential, partition enumeration FROM the bars table, watermark resume, day+6s-carry tick reads, explicit sort(agg_trade_id)+unique feed, ms→µs normalization, live-edge holding, 7-measured-column inserts, end-of-run OPTIMIZE FINAL mutations_sync=2, --execute gate (default dry-run). src/labels_bindings.rs: compute_cost_realism_labels_batch — fail-closed boundary validation (strict TID monotonicity + µs plausibility floor) enforcing the PR-A carry-forward in release builds; registered in src/lib.rs; smoke-verified (same-µs TWAP fallback, exit-family NULLs). Guards B/C/F/H/I + 2 R5 lockstep tests appended; novelty_check.py TIER-0 label fence added (self-test ALL PASS). Gates: labels:test 16/16 · test-full 36/36 · guards 18/18 · oracle-fresh 0-byte drift · clippy clean.

guards total18 / 18
tripwires126 / 93 / 93 / 68
DDL executedNEVER (file)
runner executedNEVER (authored)
bindingfail-closed feed
check-fullGREEN

Decisions made (for operator review at PR time)

#DecisionWhy
1PR-B stacked on feat/labels/pr-a-oracleConsumes PR-A's spec module (R5 single column list); operator merges A then B
2DDL carries inline COMMENTs (vs the bars-table column_comments.py convention)One-shot operator artifact must be complete in isolation; spec module stays SSoT, byte-locked by guard
3Runner inserts only the 7 measured columnsroundtrip = pure table DEFAULT (D5, replay-safe, ALTER-swappable fee); computed_at server-side
4Feed contract enforced in the BINDING, not a kernel debug_assertRelease builds included — the PR-A adversarial finding's actual fix location
5Guard I = TIER-0 fence inside novelty_check + ledger hygiene testFails closed before any scoring; existing self-test unaffected (ALL PASS)
6Live-edge bars held (not written) vs empty-window NULLs (written)The two NULL-taxonomy states stay separable for the coverage audit (§2 vs §3)

Next fire picks up here

PR-B S5 — adversarial pass + open PR. Attacker→defender panel over the PR-B diff (schema correctness vs ADR D1/D3/D5, runner watermark/live-edge/carry logic, binding contract, guards B/C/F/H/I bypass attempts, DDL⇔spec lockstep, convention compliance); amend held findings; open PR-B with base feat/labels/pr-a-oracle + Challenged & Held; flip campaign ledger to both-PRs-open saturation and hand back to the operator. Branch feat/labels/pr-b-schema-runner.