Findings

Things we measured ourselves. Each entry is one statement you can quote on its own, followed by how it was measured, on what, when, and where the full source is. Nothing here describes any strategy's returns.

SEC filing timing in EDGAR

Measured on the 10-K and 10-Q filings of 20 large US companies. These are fast, large filers; smaller companies have later deadlines and weren't measured, so treat every figure as describing this sample only.

  1. F01 56.1% of 10-K and 10-Q filings were accepted by the SEC between 4:00 and 5:30 p.m. Eastern, after the market close, yet carry that day's filing date. A backtest that joins on filing date and trades at that day's close used 56.3% of filings before they were public. Measured on 20 large US filers' SEC filings, 2026-10-17.

    Method
    Each filing timed by the acceptance second in its SEC header (ACCEPTANCE-DATETIME, US/Eastern), compared with its EDGAR filing date and the 4 p.m. close.
    Sample
    1,332 10-K and 10-Q filings from mid-2009 to 2026 by 20 large US filers (AAPL, MSFT, NVDA, AMZN, GOOGL, META, BRK-B, JPM, V, JNJ, WMT, XOM, PG, UNH, HD, KO, PFE, INTC, CSCO, GE)
    Measured
    Source
  2. F02 Quarterly net income became public a median of 29 days after the quarter ended (10-Q), and annual net income a median of 45 days after the year ended (10-K). A dataset keyed by fiscal period end makes those numbers available that much too early. Measured on 20 large US filers' SEC filings, 2026-10-17.

    Method
    Days from fiscal period end to the acceptance of the filing that first reported net income, for fiscal periods ending 2011 or later.
    Sample
    916 first-reported quarterly values (10-Q; 10th to 90th percentile 23–37 days) and 302 annual values (10-K; 30–58 days) from the same 20 filers
    Measured
    Source
  3. F03 A fixed 30-day reporting lag would still have released 44.2% of quarterly (10-Q) net income values before they were public; a 45-day lag released 0.0% in this sample. These are large, fast filers; smaller companies have later SEC deadlines, so the share is likely higher for them (not measured). Measured on 20 large US filers' SEC filings, 2026-10-17.

    Method
    Share of first-reported 10-Q values whose acceptance came after period end plus the assumed lag.
    Sample
    916 first-reported quarterly net income values from the same 20 large filers, which file faster than smaller companies
    Measured
    Source
  4. F04 13.0% of revenue figures and 4.7% of net income figures that were reported more than once later changed by more than 0.1% (same XBRL tag, not a stock split). Of the 209 revenue periods that changed at all, 4 changed through an amended filing (10-K/A or 10-Q/A). Measured on 20 large US filers' SEC filings, 2026-10-17.

    Method
    Each period's first reported value compared with its latest reported value across every filing that re-reported it.
    Sample
    1,274 revenue periods and 1,415 net income periods reported at least twice, from the same 20 filers
    Measured
    Source
  5. F05 The acceptanceDateTime field in SEC's submissions API ends in "Z" but was real UTC for only 6 of 20 filers (429 filings). For the other 14 (952 filings) it was Eastern time with the UTC offset applied twice, 4 or 5 hours later than the true time. Measured on 20 large US filers' SEC filings, 2026-10-17.

    Method
    For each filing carrying financial facts, both readings of the JSON value compared with the acceptance time in the filing's SEC header.
    Sample
    1,381 filings carrying financial facts, from the same 20 filers
    Measured
    Source

Sealed tests of our own Backtest Auditor

Each run uses a fresh test set written blind by a separate AI agent, with the answer key hashed before scoring. The tool is scored once, and our AI red-team reviewer re-runs it. Every run is listed, including the ones that went badly for us.

  1. F06 In our own held-out test (one test set, written for us and sealed before scoring, 2026-10-17), lint v0.5 raised a high or medium red flag on 1 of 105 plain correct files and on 3 of 55 correct files written to look like leaks (4 of 160 correct files overall). It flagged 19 of 60 deliberately leaky files (32%), so it misses many issues. Flags can be wrong, and a report with no red flags is weak evidence. We changed this test's pass rule after two earlier runs; all results, including the earlier ones, are in the table on this page (https://nothingbutalpha.app/findings#auditor-runs).

    Method
    Sealed held-out test: a separate AI agent that never read our code wrote the test files and the answer key; the key and the scorer were hashed before the run; the code under test was pinned to one commit and scored once; our AI red-team reviewer re-ran it from a clean checkout and got byte-identical output. A false alarm is a correct file with any high or medium finding; a leaky file counts as flagged when a high or medium finding lands within two lines of the planted leak.
    Sample
    Sealed set heldout_v8: 60 files with a planted leak, 105 plain correct files and 55 correct files written to look like leaks (220 short Python backtests)
    Measured
    Source
  2. F07 In our own held-out test (one test set, written for us and sealed before scoring, 2026-10-17), lint v0.4 raised a high or medium red flag on 0 of 55 plain correct files and on 4 of 35 correct files written to look like leaks (4 of 90 correct files overall). It flagged 17 of 60 deliberately leaky files (28%), so it misses many issues. With 55 plain files, a result of 0 is still consistent with a true false-alarm rate of up to about 5%. Flags can be wrong, and a report with no red flags is weak evidence. We changed this test's pass rule after two earlier runs; all results, including the earlier ones, are in the table on this page (https://nothingbutalpha.app/findings#auditor-runs).

    Method
    Sealed held-out test: a separate AI agent that never read our code wrote the test files and the answer key; the key and the scorer were hashed before the run; the code under test was pinned to one commit and scored once; our AI red-team reviewer re-ran it from a clean checkout and got byte-identical output. A false alarm is a correct file with any high or medium finding; a leaky file counts as flagged when a high or medium finding lands within two lines of the planted leak.
    Sample
    Sealed set heldout_v7: 60 files with a planted leak, 55 plain correct files and 35 correct files written to look like leaks (150 short Python backtests)
    Measured
    Source
  3. F08 In our own held-out test (one test set, written for us and sealed before scoring, 2026-10-17), lint v0.3 raised a high or medium red flag on 1 of 50 plain correct files and on 2 of 30 correct files written to look like leaks (3 of 80 correct files overall). It flagged 22 of 60 deliberately leaky files (37%), so it misses many issues. Flags can be wrong, and a report with no red flags is weak evidence. We changed this test's pass rule after two earlier runs; all results, including the earlier ones, are in the table on this page (https://nothingbutalpha.app/findings#auditor-runs).

    Method
    Sealed held-out test: a separate AI agent that never read our code wrote the test files and the answer key; the key and the scorer were hashed before the run; the code under test was pinned to one commit and scored once; our AI red-team reviewer re-ran it from a clean checkout and got byte-identical output. A false alarm is a correct file with any high or medium finding; a leaky file counts as flagged when a high or medium finding lands within two lines of the planted leak.
    Sample
    Sealed set heldout_v6: 60 files with a planted leak, 50 plain correct files and 30 correct files written to look like leaks (140 short Python backtests)
    Measured
    Source

We changed this test's pass rule after two earlier runs. The old rule (no false alarms on any correct file) was not met: 3 of 80 correct files were flagged in one run and 4 of 90 in the next, all but one of them look-alike files. The new rule was fixed before the next test set was written.

Every sealed run so far
DateSetLintLeaky files flaggedPlain correct flaggedLook-alike correct flaggedAll correct flagged
2026-10-17heldout_v6v0.322 of 601 of 502 of 303 of 80
2026-10-17heldout_v7v0.3 (baseline)16 of 600 of 555 of 355 of 90
2026-10-17heldout_v7v0.417 of 600 of 554 of 354 of 90
2026-10-17heldout_v8v0.4 (baseline)19 of 601 of 1053 of 554 of 160
2026-10-17heldout_v8v0.519 of 601 of 1053 of 554 of 160

On sealed set heldout_v8, lint v0.5 and lint v0.4 produced byte-identical output, so their rows match. lint v0.5's changes didn't affect any file in this set.

Hashes recorded before each run
  • heldout_v6, lint v0.3: answer key (manifest.json) sha256 be3191640e7bc7e2ff6e2052d7a8b5ebaf0cd8500630a2f975c6c71ab0b8db80; scorer output sha256 (first 16) 4cfeeebd4f1d572c; commit under test 8078a0b21ee3
  • heldout_v7, lint v0.3: answer key (manifest.json) sha256 c020c5195ac9a2435ba8f23c1ca8f8c1f60389cd40e968e225b470a4ac16fc4c; scorer output sha256 (first 16) 86ec7d86d882171b; commit under test c314a0561211
  • heldout_v7, lint v0.4: answer key (manifest.json) sha256 c020c5195ac9a2435ba8f23c1ca8f8c1f60389cd40e968e225b470a4ac16fc4c; scorer output sha256 (first 16) 6f269f0a54415dd7; commit under test 7d226139544a
  • heldout_v8, lint v0.4: answer key (manifest.json) sha256 b309f30f25a4c3841d93afae95ae8fbeaa3efde6179dd6444ff0df4d5a9a8f7d; scorer output sha256 (first 16) cd566c5358bb9c3b; commit under test 42c89baff013
  • heldout_v8, lint v0.5: answer key (manifest.json) sha256 b309f30f25a4c3841d93afae95ae8fbeaa3efde6179dd6444ff0df4d5a9a8f7d; scorer output sha256 (first 16) cd566c5358bb9c3b; commit under test 3ed4c006b7ec

The files are written by an AI agent to resemble backtest code. We have no evidence about how the tool behaves on code people actually submit.

The test-set writer and the reviewer are AI agents, not people, each run separately from the agent that built the tool. A fingerprint's publication time is GitHub's commit time; we don't use an outside timestamping service yet.

Our public ledger

Facts about the record itself. No scores are published yet.

  1. F09 Nothing But Alpha's ledger has been recording since 2026-10-16, and publishes a daily fingerprint of every record sealed so far to a public GitHub repository. The latest fingerprint, for 2026-10-16, covers 4 records. No scores are published yet.

    Method
    Records are appended to a hash-chained, append-only ledger. Each day's fingerprint is a SHA-256 hash over every record sealed so far, committed to the public ledger-heads repository.
    Sample
    The whole ledger: 4 records as of 2026-10-16
    Measured
    Source
  2. F10 Nothing But Alpha's daily ledger fingerprints are public, but the records they cover aren't published yet. The fingerprints contain only hashes and counts, so they commit us to the records without revealing them. Checking a record against a fingerprint needs the records and our verification tools, and neither is published yet, so no one outside the company can check them today. Latest fingerprint (2026-10-16): b4931544e69ddd678060d8ed83c7d5c5723fabb0e1da22f1aa6a58a6dfec341b.

    Method
    Each fingerprint is a SHA-256 hash over every record sealed so far. A fingerprint's publication time is GitHub's commit time; we don't use an outside timestamping service yet, so a match will show a record is unchanged since the fingerprint was published, not when the record was first written.
    Sample
    Fingerprint number 0 of ledger nba-main
    Measured
    Source

See also the backtest hazard report preview: three example ticker lists, each fact linked to a public source.

To cite an entry, link to its anchor (for example https://nothingbutalpha.app/findings#edgar-filing-date) and give the date it was measured.