Substrate computability — can a candidate be computed from the pinned slice at all?

Verdict — substrate computability audit (2026-08-14)

In one line: we now know which research ideas can actually be tested with the data we have, and we know it because we counted rather than because we read notes.

What was asked

Before spending compute evaluating ~230 research candidates, check the cheap thing first: does the data each one needs actually exist in the slices we pinned?

What we found

Only one genuine data absence exists: the order book. We counted every row in the table — hundreds of millions — and the bid/ask columns hold zero values. Not sparse. Zero. So ~20 candidates needing order-book depth are properly blocked until someone acquires that feed. This is the single claim the measurement confirmed.

Everything else that looked like a wall was either a stale note or a one-line code choice.

• We had it written down, in a frozen pre-registration, that only Bitcoin carries the cost labels needed for evaluation. Twenty-one coins carry them. That was true when written and quietly stopped being true. Filed as D45; it needs an operator ruling because amending a frozen pre-registration changes the campaign's scientific contract.
• Twenty-odd candidates were blocked because the pinned slice supposedly cannot tell you how long each bar took. It can — consecutive timestamps give it, 80,000 out of 80,000 times, with zero malformed values. That block was simply wrong and is lifted.
• Several columns are marked "dormant" in the code, which reads like "empty". They hold 151 million values. Anyone trusting that label would write off usable data.

The data we do have is healthy. Twenty-eight slices sampled: no all-NULL columns, no all-NaN columns, no constant columns, no slice too thin to work with.

The uncomfortable part

The recommended procedure — a cheap read-only pass over the candidate list, marking what is uncomputable — is exactly what was run first. It produced 69 confident "impossible" verdicts.

Then we measured, and 41 of those 69 were wrong.

Every wrong answer was stated confidently, with a citation, in a machine-readable file that a launcher would have obeyed. Had we stopped at the paperwork stage and shipped it, we would have written off 41 perfectly testable ideas and felt organised about it.

So the honest reading: the paperwork pass is a hypothesis generator, not a finding. It is still worth running — it is what told us where to point the measurement — but its output must not be trusted until measured. That is the inverse of how the source checklist frames it.

A smaller version of the same lesson appeared inside the build. The name-matching logic silently attached the wrong data requirement to a candidate because one name is a substring of another. Plausible shortcut, confident wrong answer. It now refuses to guess.

What is still unknown

• 105 candidates have no description of what data they need. Not blocked — undocumented. Kept in a separate bucket on purpose: collapsing "we do not know" into "we know it is impossible" would make the register look more knowledgeable than it is.
• The silent-failure risk is not fully closed. We checked the columns everything shares, not each candidate's own computed inputs — and that is precisely how the earlier petrosian_fd failure happened: real inputs in, nonsense out, nothing raised.

What changed structurally

Before, this knowledge lived as prose scattered across three documents that disagreed, and no program read any of it. Now it is one file a program reads; anything expensive refuses to start on a blocked candidate; a negative control deliberately breaks the refusal to prove it refuses; and a drift guard fails loudly if the sources change without a rebuild.

The ledger itself was never touched — its append-only hash chain is intact. Substrate verdicts are derived data and live beside it, not inside it.

Next

1. Operator ruling on D45 — widen the axis-2 slice to the 21 labelled symbols, or keep BTC-only and record the reason as scope rather than absence.
2. Declare substrate for the 105 undeclared ledger rows.
3. Extend the NULL probe per-candidate to close the silent-NaN class.