The skeptic pack

skeptic pack 2026-07-28 / board 0.9.1 estuary / board snapshot 2026-08-13

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.821 against the honest 0.797, a leakage gain of +0.024. 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.011 AUROC - refused; full-sample standardization would buy +0.024 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 777da537cd48f180, 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-08-12

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 forward as-published record in section 3, not instead of it.

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

3. The construction-PIT reconstruction: rerun a past date 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 to observations dated on or before a past date and rerun the same code. What comes out is a construction-PIT reconstruction, not the publication vintage that was visible on screens that day. Nothing dated later is carried back.

So do not take the sections above on trust. Rebuild the board yourself for 2025-09-15, a dated funding squeeze, and read the composite reconstructed for that date:

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 notary at /api/notary, whose hash-linked entries and proofs can be checked without a private route. A replay is honest reconstruction; the as-published record is not reconstruction at all.

Limit
Replays run on final/current-vintage data and are not validated-backtest evidence. 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 competence claim rests on a handful of dated endogenous episodes. If the next two arrive with the composite below its alert threshold, the claim is dead.
• The permutation test never improves. If alert placement stays indistinguishable from chance as the sample grows, this board is decoration with good typography.
• Run precision stays where it is. Most alert runs are not followed by an event. If that does not improve with sample, the board is a smoke alarm that rings at toast.
• 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 historical diagnostic 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 diagnostic 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 the same construction-PIT result within revision noise, the reconstruction 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.