โ€บNavigation
Closing reconciliation

Asked to turn a written rule about what makes a feature admissible into something a machine can actually check. Came back with three runnable probes, one gate that refuses promotion when any axis fails, and a correction to what one of the three axes even meant.

What it measured
QuantityValueMeaning
Probes and gates built3 probes, 1 composed gateorthogonal / parameterless / agnostic
Candidates swept for shared knobs40knob inventory across families
New constants recommended2 (MFDFA_DETREND_ORDER=1 over 16 members; TAKENS_EMBEDDING_TAU=1 over 4)knobs that are conventions, not magic numbers
Candidates rescued by the constants168 ordinal/CECP by reuse plus 8 single-knob MF-DFA
Convergence-oracle agreement6.9e-18 and 0.0 absolute difference in 2 cases; 3.3% relative divergence in 1the divergent case is an unpinned embedding order
How it ran
FiringWhat it did
01Transcribed the source ruling verbatim rather than paraphrasing it
02Found the 'agnostic' axis had drifted to mean cross-asset; re-anchored it to 'two correct implementations agree'
03Replaced by-hand inspection with a code scanner and a convergence oracle
04Composed them into one cheapest-first gate that stops before any expensive database query
05Swept every candidate's tuning knobs to find ones that are conventions
What it produced
Carries forward

Register a second reference implementation per candidate so the agnostic convergence test runs live (bar_svd_entropy is held pending on it); land the 2 recommended project-wide constants; feed the bigblack orthogonality run into the gate. The knob sweep is append-only and re-runs on every new candidate.

Why it is closed

'FORMALIZED โ€” three probes + one promotion gate; agnostic axis provenance-corrected.' (manifest.json verdict; ledger adds: no open queue, no next_iteration)

Lifecycle status is process state, not a judgement of the findings. Results are stated as numbers with their uncertainty. Generated between CLOSING-RECONCILIATION markers โ€” regenerate rather than edit.

Bruntwork ยท Eon Labs ยท opendeviationbar-py ยท 2026-06-09

Three-Axis Probe Formalization

Terry's feature-column discipline โ€” orthogonal ยท parameterless ยท agnostic (msg id=428) โ€” turned into three runnable probes + one promotion gate, with the agnostic axis re-anchored to Terry's verbatim source.

Headline correction. Terry's Agnostic axis means algorithm-invariant (two correct implementations converge), not asset-invariant. The cross-asset / multi-slice sweep that had drifted under the "agnostic" label is actually Terry's orthogonality substrate. Provenance โ†’

The three axes

exists Orthogonal

Captures a dimension no other feature captures โ€” empirically, on real bars.

probe: orthogonality_probe.py (+ ฮพ/CODEC cascade)
new Parameterless

No magic numbers, no tuned constants, no if n>=500 dispatch.

probe: parameterless_probe.py (AST + constants_registry.toml)
new Agnostic

Algorithm-invariant: two correct implementations converge to the same answer.

probe: agnostic_probe.py (no-dispatch + convergence oracle)

The promotion rule (enforced in code)

promote = parameterless.PASS AND agnostic.PASS AND orthogonal.PASS
A feature-wise tunable knob (parameterless FAIL) vetoes promotion even if orthogonal + agnostic pass. A project-wide constant does not block. This is the exact rule whose violation was the near-promotion to prevent.

Gate demo โ€” does it prevent the mistake? Yes

candidate implparameterlessagnosticorthogonaldecision
bar_svd_entropy (pinned to SVD_ORDER)PASSPENDINGPENDINGPENDING โ€” agnostic oracle needs a 2nd reference impl
add_antropy (hardcoded order=3)FAILSKIPPEDSKIPPEDBLOCKED โ€” parameterless (feature-tunable knob vetoes)

The hardcoded impl is blocked on the FREE static axis โ€” before any ClickHouse cost. The pinned impl is held PENDING; the gate never fakes a PASS.

Iterations

Source