The skeptic pack

skeptic pack 2026-07-28 / board 0.7.0 tier1 / board snapshot 2026-07-29

Two questions open every serious conversation about a board like this one. Isn't this just autocorrelation? and isn't there look-ahead in your backtest? The board has computed both answers on every cycle for months and buried them in a payload nobody reads. This page brings them to the front, with the numbers, the commands to check them yourself, and the limit of each test stated next to the result instead of in a footnote.

Every section here is assembled from the live board or from the source that serves it. A section whose artifact is missing says so rather than filling the space with confident prose.

1. The leak audit: what cheating would have bought

The one-switch protocol, run against ourselves. The audit rebuilds the same backtestable index with exactly ONE discipline deliberately broken, scores every variant against the SAME events, and publishes the gain that break would have bought. A clean pipeline is one whose published number sits at the bottom of its own audit table: everything above it is skill the board refuses to claim.

The largest gain on offer today is NORM_GLOBAL: event AUROC 0.824 against the honest 0.798, a leakage gain of +0.026. That is the number a leaky version of this board would print instead, and it is exactly the number this board declines to print.

leak selectivity, measured on ourselves: the forward-peeking smoother would buy +0.010 AUROC - refused; full-sample standardization would buy +0.026 AUROC - refused; a self-fitted threshold would print run-precision 0.33 instead of the honest 0.17.

Determinism check: the clean build ran twice on the same inputs and hashed identically both times (sha256 prefix 2176f587706c7e9e, over the dated index values). Pin that hash and you can tell whether tomorrow's audit scored the same index you read about today.

audit as of 2026-07-28

The audit's own caveats, verbatim from the engine that computed the table:

• the leaky variants exist ONLY inside this audit - they are never published as signals and never feed any other engine
• all variants score against the identical declustered event list and warmup slice as PROOF - one switch flips per row, everything else held fixed
• Leakage Gain is measured on final-vintage data like PROOF itself; the audit measures pipeline discipline, not vendor revisions
• a near-zero gain on one toggle does not certify the pipeline leak-free - it certifies immunity to THAT leak class only

Limit
A near zero gain on one toggle certifies immunity to that leak class and nothing wider. The audit is run on final-vintage data, so it measures pipeline discipline, not vendor revisions. And note the awkward direction: if the real pipeline were already peeking forward, the forward-peeking toggle would buy almost nothing, so read this table next to the point-in-time record in section 3, not instead of it.

2. The orthogonal test: the board without its own headline input

The event this board is scored against is a spike in the SOFR minus IORB spread. The published index contains spread and tail terms. So the objection is fair and obvious: is the signal just the target wearing a costume? The orthogonal run answers it by deleting the whole tails family from the index and rerunning the identical capture test, same events, same threshold, same warmup slice.

same event-capture test with the target's own variable family removed from the signal (no spread, no tails) - kink-proxy/confession/rvxray/auctions/buffers only.

Reading it in one line: strip out the variable family the event is defined on and the board still captures 69% of events, against 62% with everything in. The capture does not live in the spread term. Whatever this board is doing, it is not one series predicting itself.

Wilson 95% interval on that recall: 42% to 87%. The interval is wide because the event count is small, and it is printed rather than rounded away.

What is left carrying the signal, with weights renormalized:

Out of the run: tails, weather, resonance, hydrophone, undertow, warehouse. Some are excluded because they are the target's own family, the rest because they are live only and cannot be reconstructed point in time at all.

The harder test, on the same page as the flattering one. Permute the alert runs at random and ask how often chance placement captures as many events: p is 0.084 over 2,000 permutations, verdict NOT distinguishable from chance placement of the same alerts. That is the board's own rigor block, and it belongs here more than anywhere else on the site.

Limit
State plainly what this does not prove. The surviving components are not independent of the funding tape: reserves, facility take-up and dealer pairs all respond to the same conditions the spread responds to, so this is a costume test, not an independence proof. The event is still defined on the spread. The index under test is the reconstructable lite index, not the live composite, which carries more information and cannot be backtested honestly. And the event count is small enough that the confidence interval, not the point estimate, is the number to quote.

3. The point-in-time proof: rebuild any past board yourself

Every engine on this board is a pure function of its input series. No engine fetches, no engine remembers. That is not a style preference, it is what makes the next paragraph possible: truncate every series at a past date, rerun the same code, and what comes out is the board as it stood on that date. Nothing is patched in and nothing is carried back.

So do not take the sections above on trust. Rebuild the board yourself for 2025-12-31, a squeeze the board first flagged 42 trading days ahead, and read the composite it was printing that day:

The whole payload comes back, every engine, so any claim about any past day is checkable against the same code that made it. Coverage starts around June 2018, which is where the free public series start. Be patient with the hosted route: a date nobody has asked for lately is rebuilt from the sources on demand, so the first call can run for minutes on a busy box before the replay is cached per date and served with a day-long cache header. The second route needs nothing from us but the code, which is the version a skeptic should prefer anyway.

The stronger artifact sits next to it. From the day it was switched on, every published reading is appended to a forward-accruing as-published record at /api/pit, which no later recomputation can revise. A replay is honest reconstruction; the as-published record is not reconstruction at all.

Limit
Replays run on final-vintage data. Daily market prints are effectively unrevised, but weekly H.4.1 aggregates are lightly revised against what was on screens that day, and the payload says so in its own vintage note. The deep analytics layer is excluded from replays on purpose, because its percentile bases are defined against the live sample and replaying them would be the look-ahead this page exists to refuse. Replays are cached per date, and the operator can put the route behind sign-in with SEICHE_ASOF_AUTH=1, so a 401 means gated, not missing.

4. The notary: proof a past reading was not edited later

A record that can be quietly improved is not a record. Every as-published reading is canonicalised to JSON with fixed key order, hashed with SHA-256, and chained to the one before it as sha256(prev_hash|digest|utc|pit_date), from a fixed published root, seiche-notary-genesis-v1. Change any earlier reading, reorder two links, delete one, and every later link stops reproducing.

The chain is served with no authentication on purpose, and the check runs on your machine, not ours:

Step one proves internal consistency: the server cannot hand you a ledger with an edited past that still recomputes. Step two is the part that does not depend on trusting the operator at all: each digest is submitted to the OpenTimestamps calendars and settles into the Bitcoin chain, so a reading can be shown to have existed by a given block time and cannot be backdated. Step three is the signature layer, an Ed25519 key over domain:stream:day:record_hash, with per-day commitments at /api/attest/stream/{stream}. The digest in step two is the record_sha256 of the ledger entry you are checking, and what comes back is a standard detached OpenTimestamps proof that any OTS verifier will take. A digest whose anchor has not settled yet answers 404 saying exactly that, which is better than a proof that proves nothing.

The board's own as-published composite history, hash chained the same way and versioned in a public git repository, is a plain file: https://seiche.info/data/book_history.json. Keep a copy today and you hold a copy of the past nobody can edit out from under you.

Limit
The chain proves integrity and ordering, and the Bitcoin anchor proves a reading is not backdated. Neither proves the reading was computed from honest inputs; that is what sections 1 to 3 are for. Anchoring is a separate step from committing, so a very recent digest can still be pending, in which case it is only as good as the operator's word until it settles. And the ledger stores commitments, not payloads, so pinning a specific past number means keeping the record you were shown, or reading it out of the published history file above.

5. What would falsify the whole board

Not marketing. These are the conditions under which the honest thing to do is take the board down, or at least stop quoting it. They are listed here because a tool that cannot say what would refute it is not a measurement, it is a mood.

• The endogenous claim dies on its own sample. The headline competence claim rests on 2 endogenous episodes. If the next two calendar or reserve squeezes arrive with the composite below its alert threshold, the claim is dead and no amount of engine count saves it.
• The permutation test never improves. Today the alert placement carries p 0.084 against chance placement of the same runs. If that does not fall as the sample grows, this board is decoration with good typography, and the honest move is to say so here.
• Run precision stays where it is. 17% of alert runs are followed by an event, which means most alerts are not. If that does not improve with sample, the board is a smoke alarm that rings at toast, and the number stays printed next to every claim until it does.
• The orthogonal run collapses. If capture without the tails family falls to the base rate, the board is one series wearing a costume and this page will print that instead of the current table.
• The leak audit inverts. If the forward-peeking toggle stops buying anything while published skill rises, the honest reading is not that we got better; it is that the real pipeline started peeking.
• The as-published record diverges from the reconstruction. The forward-accruing record and the backtest cover the same dates from different directions. If the reconstruction is systematically kinder to the board than the record it accrued live, the reconstruction is flattering and the backtest number should be retired.
• A replay cannot be reproduced. The code is AGPL and public. If someone runs it against the same free public series and cannot reproduce a published past board within revision noise, the point-in-time claim is false and everything above it is worth less.

Limit
This list is written by the same desk that built the board, which is a conflict of interest and not a small one. The mitigation is that every item is checkable against a published artifact rather than against our opinion: the audit table, the rigor block, the ledger, the replay endpoint and the source. Bring your own falsifier if this list is missing one.

Where to go next

The method behind every number is on the versioned methodology page, with citations and a changelog. The code that produced all of it is at https://github.com/beepboop2025/seiche under AGPL-3.0, including the leak audit and the orthogonal run, so the fastest way to disprove this page is to read the two engines behind it.

Changelog

• 2026-07-28: first publication; the leak audit and the orthogonal run were computed on the board for months before this page surfaced them.

Free public data with native lags. Not investment advice. Seiche is free open source software (AGPL-3.0) and a public good.