# Unreconciled items

**DOCTRINE rule 4 requires this file, and until 2026-07-16 it did not exist.**

Rule 4 says a numeric gap has exactly two publishable states — RECONCILED (decomposed, each side
recomputed from source, remainder $0.00) or UNRECONCILED (*"logged in the standing
Unreconciled-items table with magnitude, direction, and what was tried"*) — and that **no cause,
mechanism, or story may be attached to a gap until it is RECONCILED**.

There was no standing table. So the second state had nowhere to live, and every gap faced a choice
between reconciling it and saying nothing — which is the pressure that produces A5, A7 and B5, the
three errors where a plausible story was published instead of a reconciliation. **The rule's escape
hatch was missing, so the rule bent.** This is that hatch.

A row here is not an admission of a bug. It is the honest state of a number we publish or rely on,
and it is strictly better than the alternative this repo keeps reaching for: an explanation.

**Rules for this file.** Every row states the magnitude, the direction, and what was tried — not
why. A row leaves only by being RECONCILED (remainder $0.00, artifact cited by path) or by the
claim being withdrawn from publication. "It's probably X" is not an exit.

**Revision 2026-07-16:** the "What was tried" entries below were condensed from step-by-step
protocol to outcome level. No magnitude, direction, date, status, decision, or exit condition
changed. The full fetch protocol, cap measurements, and working artifacts are retained internally
and available to any auditor on request.

---

## U1 — swisstony's published fill and market counts are refuted by a re-fetch

| | |
|---|---|
| **Opened** | 2026-07-16 |
| **Surfaces** | `decode-index.json` (swisstony), `scorecard.html` rank 2, `/w/swisstony`, `og/w/swisstony.png`, `cases/leaderboard-autopsy.html` §03 |
| **Status** | UNRECONCILED |

**The gap.** For wallet `swisstony` = `0x204f72f35326db932158cba6adff0b9a1da95e14`:

| | our published figure | measured 2026-07-16 | ratio |
|---|---|---|---|
| fills, 2026-06-15 → 07-15 | **15,410** | **539,113** | 35.0× |
| markets, same window | **434** | **15,122** | 34.8× |
| fills, lifetime (autopsy, "complete fill history", 2026-07-11 pull) | **14K** | **2,918,281** (2025-08-09 → 2026-07-16, every window clean) | ~208× |

**Direction.** Our figures are low. Every one of them. Our fetch captured roughly **2.9%** of the
fills in the window it reports on, and the wallet carries `marketCapped: false` — our own engine
did not flag it.

**What was tried.**
1. Re-fetched the exact 2026-06-15→07-15 window in segments sized so that none could hit the
   endpoint's caps. Result: 539,113 rows, all this wallet's, all timestamps inside the bounds,
   fully deduplicated.
2. Verified by measurement, not assumption, that both public endpoints cap how much history a
   single query path can return — shallow enough that a top-volume wallet's 30-day window cannot
   be pulled through the user-level path at all. The exact cap behaviour and measurements are
   retained internally.
3. Independent rate check, by a different method: `/trades?user=…&limit=500` returned **500 fills
   spanning 77 minutes**. At that rate the published 15,410 is about 40 hours of trading, reported
   as a 30-day total.
4. **Tested our own pipeline before blaming anything** (rule 4's corollary). The fetch returns
   100% `BUY` rows, which looks like a filtered feed and would invalidate the count. It is not:
   `side=SELL` returns zero rows, `takerOnly=false` and `takerOnly=true` are identical, and
   `/activity` shows `TRADE`/`REDEEM`/`MERGE` with no sells. The wallet buys near-certainty and
   redeems; it never sells. The all-BUY shape is the wallet, not our fetch.
5. Attempted the lifetime total. The first attempt exhausted RAM at 2026-04-26 with three months
   unfetched, and this item published **≥1,819,142** as an explicit floor. **Superseded
   2026-07-16:** a re-run completed every window from 2025-01-01 to 2026-07-17 —
   2,918,484 raw rows, **2,918,281 deduped fills**, 132,786 unique
   `conditionId`s, earliest fill 2025-08-09, latest 2026-07-16, `ALL WINDOWS CLEAN: True`. The
   lifetime figure is now **measured, not floored**. The retired floor was sound: 1,819,142 is
   exactly the sum of the windows through 2026-04-26, which is all the first run had reached.
   *This paragraph previously read "the exact lifetime figure is not known" while the log cited
   below as its own evidence already recorded it — the sentence was refuted by the artifact it
   pointed at. An auditor holding the log catches it in one read.*

**What is NOT claimed.** *Why* our figure is 2.9% of the book. The obvious candidate is that market
enumeration is bounded by the capped user-level feed — every wallet's published `nMarkets` is under
~3,400, which is the shape you would expect — but **the engine that produced these numbers is not
in this repo** (`grep` finds no assignment of `marketCapped`; the frozen `*_v2.json` enrichment
source the builder's own HALT points at is absent). So the mechanism cannot be closed here, and
under rule 4 it therefore is not written down as one. The mechanism above is a lead for whoever has
the engine, not a finding.

**Consequences carried.** swisstony's `reconPct` (21.9%), `bilateralPct`, `avgBuyPrice`,
`directionalPct` and `topMarket` are all computed from that 2.9% sample and are not evidence about
this wallet. Its verdict (*Insufficient evidence*) stands — we do not certify it — but the verdict's
published reason has been rewritten: it previously said the wallet's PnL "won't reconcile", which
attributed to the wallet a gap our own fetch produced.

**Artifacts.** `scratchpad-msr/win_2026-06-15_2026-07-15.json` (539,113 rows),
`scratchpad-msr/win_2026-07-11_2026-07-15.json` (46,986 rows),
`scratchpad-msr/lifetime_fetch.log` (per-window counts, `clean=True` per window, and the completed
lifetime total recorded above).
*These are outside the repo and outside the publish surface; they are working artifacts, not a
frozen source. U2 exists because that is not good enough.*

**Exit condition.** A complete, provenance-stamped re-fetch of swisstony, with the counts
recomputed and the row rebuilt from it — or the row's numbers withdrawn from publication.
*Status 2026-07-16: the "complete" half is now done (item 5 above). The provenance stamp and the
rebuild are not: the fetch lives in a scratchpad outside the repo, nothing in the publish surface
is computed from it, and the published row still carries the 2.9% sample. This item stays
UNRECONCILED — a measurement we happen to have is not a published number.*

---

## U2 — the other 24 wallets' fetch completeness is unproven

| | |
|---|---|
| **Opened** | 2026-07-16 |
| **Surfaces** | `decode-index.json` (all), `scorecard.html`, `/w/*`, `workpaper.html` |
| **Status** | UNRECONCILED |

**The gap.** U1 establishes that at least one wallet's published fill count is wrong by 35×, and
that **our engine did not flag it** (`marketCapped: false`). `marketCapped` detects a *per-market*
`/activity` cap; it cannot see a truncation that happens at market *enumeration*. So the flag
cannot be used to screen for this, and no other completeness evidence exists for this cycle: the
July 2026 wallets carry **no fetch-provenance metadata at all**, which `tools/audit.mjs` has
printed as a known blind spot on every run since it was written.

**Magnitude and direction.** Unknown, and that is the finding. If the same defect touches other
wallets, their fill counts are low and their reconstructions are computed from a fraction of the
book — which would flow into `reconPct`, into the verdicts that cite it, and into the frozen
headline. Whether it does is **not known**.

**What was tried.** A cheap screen of all 25 was attempted three times and abandoned. Each version
was wrong in a different way — one conflated "reached the end of the wallet's data" with "hit the
cap" and flagged complete wallets; one inverted its verdict and passed everything; the third was
rate-limited into empty responses it read as end-of-data, reporting an 8,310-fill wallet as having
a 298-row feed. **No screen result is recorded here, because none of them were sound.** The only
method known to work is the exhaustive per-wallet re-fetch U1 used, which took roughly an hour and
several gigabytes for a single wallet.

**Decision, recorded.** On 2026-07-16 the choice was made to fix swisstony and log the rest here
rather than re-fetch the cycle. That is a decision to publish 24 rows whose completeness is
unproven, taken knowingly, with this row as the disclosure. It is not a claim that they are fine.

**Exit condition.** A per-wallet completeness proof for the cycle — which `SPEC_recon_error_v2.md`
(iv) already requires from the next ingest forward — or the affected figures withdrawn.

---

## U3 — the autopsy's receipt figures have no source artifact

| | |
|---|---|
| **Opened** | 2026-07-16 |
| **Surfaces** | `cases/leaderboard-autopsy.html` §02 |
| **Status** | UNRECONCILED |

**The gap.** The flagship decode's fill receipts are hand-typed from a 2026-07-11 pull that
retained no artifact in this repo. Two of the five lines were arithmetically wrong when published:
`$125,950` for a product of `$125,942.61` (**+$7.39**, reachable by no rounding model) and `$2,849`
for `$2,849.68` (**−$0.68**, truncated where its siblings rounded). Both are now corrected and
`tools/audit.mjs`'s `fill receipts tie` check holds every line to the rounding model the block
declares — **verified by reverting both numbers and watching it fail on each**.

**What remains unreconciled.** Fixing the arithmetic did not make the numbers sourced. The three
values on each line are now internally consistent and still unverifiable: there is no frozen fill
log behind them, and the wallet is published only as **`0x24c8cf69…823e1`** — a truncated address
that cannot be looked up, so the subject of our flagship case study **cannot be re-fetched by us or
by a reader**. `grep` over the repo finds the full address nowhere.

**Direction.** Unknown; an internally consistent line gives no evidence about which of its three
numbers is right.

**Exit condition.** Publish debased's full address and re-fetch the cited market's fills into a
committed inputs artifact the page renders from — or drop the dollar figures and keep the prices
and sizes, which is what the strategy classification actually rests on.