Tollbridge Docs

Methodology

How the decision instruments are built, and the standing disclosures — starting with the S01 market-regime degeneracy audit.

This page carries the standing methodology disclosures. The full S01 audit is committed to the repository as S01_AUDIT.md; the summary below is the litigable record.

S01 market regime — degeneracy audit (2026-09-19)

The fact. On the live Hyperliquid BTC tape, S01's calculator returned range_expansion as its mode in 11 of 11 resolved rows, while the world delivered range_compression in 11 of 11 (match: false, 0/11). Every row is visible in the series — the sample is complete.

Can the calculator output another mode? Not demonstrated. The choice is delegated to the hosted system model (the same System One / @tollbridge/jev primitive the other questions use) — there is no in-repo scorer, weight table, or branch to inspect. The stored distribution is the wire answer verbatim (no rounding, clamping, or re-ranking). Across the 11 rows the distribution does move (range_expansion 0.37–0.53, trending_up 0.24–0.32, range_compression 0.21–0.33), so it is not a frozen prior; but the mode never moved, and trending_down sat at exactly 0.01 in all 11 rows.

Why the tape is degenerate. The trailing 24h realized-vol baseline was near-constant (0.00616–0.00624). Every 60m return (−0.0030…+0.0058) sat well inside the ±1.5×baseline trend band, and the forward 60m realized vol (0.00048–0.00068) was roughly one tenth of the baseline — so trending_up, trending_down, and range_expansion were all unattainable by the event's own rule, and range_compression was the only label the world could deliver. The realized side is as pinned as the predicted side.

Status — calculator under review. We did not retune any weight, prior, option order, or threshold to chase a match: a distribution moved to fit the last five rows would be fraud. No in-repo defect was found to fix; the immobility is recorded, not explained away. The calculator's output will be re-examined when the tape produces a directional move or a forward-vol expansion.

The tape probe — graded (2026-09-19, 05:20Z). Both probes sat their full horizon and resolved exactly at horizon_end, graded three ways (HTTP resolution = MCP tollbridge_get_resolution = the series row the tiles hydrate from):

BTC  11/11      pred expansion     realized compression   (match false, 0/11)
ETH  1b7b4919   pred compression   realized compression   (match TRUE)
SOL  56ea4416   pred compression   realized compression   (match TRUE)

At resolve, range_compression was the only legal label on both probe tapes (60m returns inside the ±1.5×baseline band; forward vol roughly a tenth of the threshold) — and the model had put 0.70 on it. Both forecasts were right on those tapes; that is stated plainly, with no accuracy percentage and no celebration. The cross-asset calibration read model counts the probes as they land (n 11 → 12), still unpublished below the floor (30); the BTC series itself is unchanged at 11 rows.

The streak broke. The mode left range_expansion on both live Hyperliquid tapes, so the calculator is not a constant and BTC-afternoon's 11/11 was (at least partly) the tape. The cross-asset degeneracy hypothesis is retired. Both decisions persist the full System One exchange (model.request, the exact feature envelope POSTed; model.response, the raw distribution; model.request_hash; the model name / url / version), so a later audit sees what the model saw — the record no longer hides the brain.

Note, not a patch: trending_down sat at 0.00 on the probe distributions (0.01 across the BTC rows) — a property of the calculator's output, recorded here; nothing was retuned.

On every S01 tile: the disclosure block carries the model line — calculator jev-1.13.0 · hash <first 8 of model.request_hash> (ETH 9ca8b292…, SOL 8ec3b808…) — above the event English; pre-trace BTC rows stay silent rather than show a fabricated box. The audit sentence sits above the series strip:

S01 grades: BTC 11/11 pred expansion → realized compression. ETH 1b7b4919 pred compression → realized compression (match). SOL 56ea4416 pred compression → realized compression (match). calculator under review.

Calibration stays unpublished below n = 30; a reliability diagram is deliberately not published — the graded rows above are the disclosed evidence.

On this page