# 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`, `workpaper.html` §01/§04/§05, `cases/leaderboard-autopsy.html` §03 |
| **Status** | **PARTIALLY RECONCILED (2026-07-18)** — split below. `nFills`/`nMarkets`/`avgBuyPrice`/`topMarket` are rebuilt and provenance-stamped. `reconstructed`/`reconPct`/`realized`/`openValue`/`bilateralPct`/`postresPct`/`directionalPct` remain UNRECONCILED — not recomputable from complete data with the tools available to us (see "What remains unrecomputed" below), so they are unchanged and still flagged not-evidence. |

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

| | our published figure | measured 2026-07-16 (/trades) | measured 2026-07-18 (/activity) | ratio (published → 07-18) |
|---|---|---|---|---|
| fills, 2026-06-15 → 07-15 | **15,410** | 539,113 | **≥888,820** | 57.7× |
| markets, same window | **434** | 15,122 | **≥16,258** | 37.5× |
| fills, lifetime (autopsy, "complete fill history", 2026-07-11 pull) | **14K** | **2,918,281** (2025-08-09 → 2026-07-16, every window clean) — unchanged by this update | | ~208× |

**Direction.** Our figures are low. Every one of them, at every measurement. The wallet carries
`marketCapped: false` — our own engine did not flag it.

**What was tried (2026-07-16, retained).**
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 — reconfirmed
   independently 2026-07-18 on both re-fetches below (0 SELL rows in 539,113 and in 888,820).
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.
   *Not re-verified by this update — U1's 2026-07-18 work was scoped to the 30-day cycle window
   the published row actually claims; see the new finding below for why even a "clean" re-fetch
   is not the same claim as complete.*

**What was tried (2026-07-18 — the rebuild).**
6. **Recounted item 1's own artifact independently**, rather than trusting the 2026-07-16 session
   record: a freshly-written streaming parser (not the original fetch script) re-derived every
   number from the raw bytes of `win_2026-06-15_2026-07-15.json` — 539,113 raw rows, 539,113
   deduped (0 duplicates), 0 rows outside the window bounds, 0 wrong-wallet rows, 15,122 unique
   `conditionId`s. Exact match to the 2026-07-16 record. `sha256` of the raw file is in the
   provenance artifact.
7. **Found the 539,113/15,122 figure was itself incomplete.** Before publishing it as the rebuilt
   row, spot-checked `/trades` against `/activity?type=TRADE` for the identical wallet and a
   1-hour sub-window (2026-06-20 12:00–13:00 UTC): `/trades` returned 355 rows, `/activity`
   returned 556 — every `/trades` transactionHash also appears in `/activity`, but **197
   transactionHashes exist only in `/activity`**, and querying `/trades?market=<conditionId>`
   directly for one of them (the per-market bypass approach) still returns nothing. This is a
   *different* failure mode from the original 2.9% problem — both endpoints' own pagination/cap
   signals read clean; the gap is between what the two endpoints' underlying indices contain, not
   a truncation either one flags. Full row-level evidence in `u1-swisstony-provenance.json`
   (`step2_tradesVsActivityDiscrepancy`).
8. **Re-fetched the same window from `/activity?type=TRADE`** instead, using the same recursive
   time-window-subdivision method (no conditionId enumeration). First attempt used `/trades`'
   page size (`limit=1000`, stop on a short page) and silently under-fetched to exactly 500 rows
   on all 30 days — `/activity` hard-caps every response at 500 regardless of the requested
   `limit` (verified: `limit=100/500/1000/2000/5000` all return ≤500), unlike `/trades`, which
   honors `limit=1000`. **This is exactly U2's "capped response read as end-of-data" failure
   mode**, caught before anything was published from it. Fixed: page size 500 (matches
   `decode_v2.py`'s own default for non-`/trades` endpoints), split before the ~3,500-row/window
   cap. Result: 888,820 deduped rows (0 duplicates on independent recount), 16,258 unique
   markets, all 30 day-windows clean. Cross-validated the `type=TRADE` server filter is not
   itself lossy (unfiltered `/activity` for the same hour, client-side filtered to `type==TRADE`,
   returns the identical 556-row set).
9. **avg_buy_price recomputed from real `usdcSize`, not a price×size proxy.** A spot-check
   (`verify_usdcsize.py`, n=1,211 live BUY rows) found `usdcSize != price*size` for 774/1,211
   (64%) of rows, up to 2.9% relative difference, consistently `usdcSize` higher — so the
   `/trades`-only data (no `usdcSize` field) could not support the engine's actual formula. The
   `/activity` re-fetch (item 8) carries real `usdcSize`; `avg_buy_price = 0.710` is computed from
   it per the engine's own formula.

**What remains unrecomputed, and why (2026-07-18).** `reconstructed`, `reconPct`, `realized`,
`openValue`, `bilateralPct`, `postresPct`, `directionalPct` are **unchanged** — still computed from
the original 15,410-fill sample, still not evidence about the wallet. `decode_v2.py` (the only source of
these formulas) was read in full: it only fetches LIVE data over HTTP, with no parameter or code
path to ingest a local/pre-fetched fill set, and it cannot be re-pointed at a past window —
`full_activity()` always pulls the wallet's *current* activity. It therefore cannot be re-run
against this window's complete re-fetch, at any date. Hand-deriving the formulas outside the engine
was considered and rejected: `ENGINE_FINDINGS_cid_enumeration_2026-07-15.md` (engine repo)
documents that directly summing cashflow components over-corrects for wallets with negative-risk
(negRisk) conversions — the "obvious fix" for a related wallet (maz26) overshot the true figure by
millions — and swisstony's negRisk exposure across its now-known 16,258 markets has not been
checked. Publishing a second, unaudited implementation of `reconstructed` risked exactly the
failure DOCTRINE rule 4 exists to prevent. Separately: the original `reconstructed`/`realized`/etc.
were never actually scoped to the 30-day window in the first place — `swisstony_v2.json`'s own
`date0`/`date1` show the underlying fetch spanned 2026-03-05 to 2026-07-15 (~4.3 months), because
the capped-source bypass pulls full per-market history for whatever markets it enumerates, not a
time-boxed slice. So "the 30-day-window version of `reconstructed`" was never a well-defined
historical quantity to rebuild, independent of completeness.

**Mechanism lead — verified engine-code facts, no causal claim (2026-07-18).** The engine
repo was read (read-only, per this session's scope). `decode_v2.py`'s `full_activity()` cid
discovery unions conditionIds from exactly three sources — a capped `/activity` pull, a capped
`/trades` pull, a capped `/positions` pull — and never expands beyond them; none recursively
subdivide by time. For a wallet whose true lifetime market count is 132,786, these three capped
sources can structurally discover only a small fraction of it, which is consistent with the shape
of the originally-published 434-market figure. Those are verified facts about the engine's code
(cited by file and line in `u1-swisstony-provenance.json`); under rule 4 they remain a **lead** —
no causal account of the 15,410 figure is claimed, here or anywhere, and this gap's own
reconciliation state is unchanged by them. They appear only here and in the provenance artifact,
never on a customer-facing surface.

**New standing question this update opens (not resolved here — flagged for the coordinator and
U2).** The recursive-window-subdivision-on-`/trades`-until-clean method was, until 2026-07-18,
treated as this project's proof of completeness (it is what "ALL WINDOWS CLEAN: True" meant
throughout the 2026-07-16 session and the U2 "FORBIDDEN methods" list). Item 7 above shows a
*clean* `/trades` fetch can still be a real undercount relative to `/activity`, for reasons neither
endpoint's own pagination signals expose. Whether this generalizes to the other 24 wallets, to the
lifetime figure in item 5, or to the engine's own `/trades`-based cid discovery (one of its three
enumeration sources) is **unknown** and out of this brief's scope. U2's per-wallet completeness work
should cross-check `/activity` against `/trades`, not rely on `/trades` alone, and the lifetime
figure in item 5 has not been re-verified against `/activity`.

**Consequences carried.** `nFills`, `nMarkets`, `avgBuyPrice` and `topMarket` are rebuilt from the
most complete data obtained (2026-07-18) and **are now evidence about the wallet's trading
activity** — though "at least" figures, not asserted as exactly complete (see the standing question
above). `reconPct` (21.9%), `bilateralPct`, `directionalPct` and `reconstructed`/`realized`/
`openValue` remain computed from the original 15,410-fill sample and **are still not evidence**. The
verdict (*Insufficient evidence*) stands — we do not certify it — for a reason that is now doubly
true: the reconciliation figures are unrebuilt, and even a full rebuild would leave every
`strict_classify()` input except fills-count unavailable, which the classifier's own design
collapses to *Insufficient evidence* rather than a guess. No escalation triggered (verdict,
`copyable`, the 6-of-25 count and the frozen workpaper headline are all unchanged — checked and
guarded by `tools/audit.mjs`/`build-workpaper.mjs`'s own HALTs, not asserted).

**Artifacts.** `u1-swisstony-provenance.json` (committed, published, repo root) — fetch windows,
per-window counts, dedupe rule, raw-file `sha256`s, the `/trades`-vs-`/activity` discrepancy
evidence, and what was and was not recomputed. Raw fetch files (outside the repo, cited by path and
hash in the provenance artifact): `scratchpad-msr/win_2026-06-15_2026-07-15.json` (539,113 rows,
`/trades`), `scratchpad-msr/u1/act_trade_2026-06-15_2026-07-15.json` (888,820 rows, `/activity`,
the source of the published figures), `scratchpad-msr/u1/act_trade_fetch.log` (per-day counts),
`scratchpad-msr/win_2026-07-11_2026-07-15.json` (46,986 rows), `scratchpad-msr/lifetime_fetch.log`.

**Exit condition — met for a subset, not all.** Original: "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." **Met 2026-07-18 for `nFills`/`nMarkets`/`avgBuyPrice`/`topMarket`**:
rebuilt, provenance-stamped, committed artifact cited by the row's `why`. **Not met, and not
withdrawn, for `reconstructed`/`reconPct`/`realized`/`openValue`/the mechanism split**: these
cannot currently be recomputed at all (no engine path exists to run them against historical/local
data) and were kept rather than deleted, because the JSON schema `tools/audit.mjs` enforces
requires them as finite numbers on every row — deleting them outright would need a broader schema
change (a general "a row may withdraw a named field" mechanism touching `tools/audit.mjs`'s
required-field check, the `realized+openValue=reconstructed` tie, and the mechanism-sum-to-100%
tie) that this brief's scope did not extend to. They are instead exhaustively flagged
not-recomputed, with a reason, in `fetchTruncated.notRecomputedFields`/`notRecomputedReason` and in
the row's `why`. A future session doing this for U2's wallets should decide, once, whether to build
that general withdrawal mechanism rather than re-deciding per wallet.

---

## U2 — the other 24 wallets' fetch completeness

| | |
|---|---|
| **Opened** | 2026-07-16 |
| **Surfaces** | `decode-index.json` (maz26, 0x2c335066FE58fe9237c3, 0x076daa87), `index.html`, `scorecard.html`, `/w/maz26`, `/w/0x2c330563`, `/w/0x076d8d4c`, `workpaper.html` §01, `og/w/*` (3 re-shot) |
| **Status** | **PARTIALLY RECONCILED (2026-07-18)** — split below. 3 of 24 wallets rebuilt + provenance-stamped (genuine, provable undercounts). 16 of 24 measured and confirmed within tolerance (no defect found). 5 of 24 measured but inconclusive under this method (see "Method finding" below — a genuinely different situation from "unproven", recorded honestly as neither). |

**The gap, as it stood 2026-07-16.** U1 established that swisstony's published fill count was
wrong by 35–57×, undetected by `marketCapped` (which flags a *per-market* `/activity` cap, not a
shortfall at market *enumeration*). Whether the same defect touched the other 24 wallets was
unknown; the July 2026 wallets carry no fetch-provenance metadata, and three prior cheap screens
(end-of-data/cap conflation, an inverted pass/fail, rate-limited empties read as end-of-data) were
each unsound and discarded without result.

**What was done, 2026-07-18 (U2).** All 24 non-swisstony wallets were re-fetched against
`/activity?type=TRADE` for the same `2026-06-15T00:00:00Z .. 2026-07-15T00:00:00Z` window U1 used —
recursive time-window subdivision, page=500 (the endpoint's hard per-response cap regardless of
requested `limit`), split before the ~3,500-row/window cap, every empty/short response retried with
backoff before being believed, streamed to disk, deduped on
`(transactionHash, timestamp, asset, side, price, size, usdcSize)`. All 24 fetches completed with
`allWindowsClean: true` — no window hit the cap at final (60-second) granularity, so each measured
figure below is the complete `/activity` count for that 30-day window. Per U1's standing finding,
completeness beyond `/activity` itself remains unproven, so the published rows still state these
as "at least" floors — "complete" here means complete relative to the endpoint, never absolutely. Method,
scripts and full per-window logs: `u2-wallet-completeness-provenance.json` (committed) and
`scratchpad-msr/u2/<handle>/` (raw, outside this repo). A `/trades`-vs-`/activity` spot-check was
run per wallet on a fixed 1-hour sub-window (2026-06-25T12:00–13:00Z): 0 of 24 had any
transactionHash present in `/trades` but absent from `/activity` — no contradiction of U1's finding
that `/activity` is the more complete endpoint.

**Method finding — the ±15% tolerance is directional, not symmetric (new, 2026-07-18).**
`decode_v2.py`'s `full_activity()` does not time-scope its fetch at all (no `start`/`end` params on
any of its three calls) — the published `nFills`/`nMarkets` describe *however much history the
capped discovery path found*, not a 30-day slice. A measured 30-day floor that comes in **below**
published is therefore not provable evidence of anything: it is equally consistent with "published
correctly counts pre-window history our 30-day probe cannot see" and with "our own fetch is short" —
this method cannot distinguish the two without a lifetime re-fetch, which was out of this brief's
budget for 24 wallets. A measured floor that **exceeds** published is different in kind: a 30-day
window is a subset of whatever longer period published claims to cover, so a floor already above
the published count *proves* undercounting, full stop, regardless of window-scope questions. Only
that direction is called a defect here. This asymmetry was not anticipated by the brief's tolerance
language ("PASS within ±15%, else FAIL") and should be stated explicitly in `recon-error-v2` (iv)
for the next cycle — see item 6 of the closing session record.

**Per-wallet ledger** (fills only, the site's published tolerance; nMarkets tracked but not gating —
several wallets show a much larger nMarkets gap than fills gap in the *below-published* direction,
consistent with the same window-scope effect and not treated as a separate finding. One exception,
logged under this row's own asymmetry rule: **alwayslatetotheparty's measured 30-day market floor
(961) exceeds its published 434-market-scale figure (812) by +18.3%** — a floor above published
proves a market-enumeration undercount regardless of window scope. Magnitude 149 markets, direction
ours-low, no cause attached; its fills count PASSes and its row is unchanged this pass — exit is a
market-count rebuild or withdrawal at the next ingest):

| Rank | Wallet | Real edge | Published nFills | Measured floor (30-day) | Diff | Call | Action |
|---|---|---|---:|---:|---:|---|---|
| 1 | DEEDDIT | yes | 8,310 | 8,594 | +3.4% | PASS | none — folds into the existing per-market-cap disclosure, see below |
| 2 | swisstony | — | *(U1, above)* | | | | rebuilt (U1) |
| 3 | maz26 | | 38,386 | 55,756 | +45.3% | **FAIL** | rebuilt + `fetchTruncated` |
| 4 | CandleHammerDrums | | 14,695 | 14,734 | +0.3% | PASS | none |
| 5 | Sparkling8899 | | 22,682 | 20,499 | −9.6% | PASS | none |
| 6 | Jsram | | 18,350 | 12,581 | −31.4% | INCONCLUSIVE | none (window-scope ambiguity) |
| 7 | 0x2c335066FE58fe9237c3 | | 333,368 | 389,007 | +16.7% | **FAIL** (marginal) | rebuilt + `fetchTruncated` |
| 8 | ramadamaramadam | | 11,588 | 10,255 | −11.5% | PASS | none |
| 9 | asparagus2012 | | 3,408 | 3,350 | −1.7% | PASS | none |
| 10 | muchobliged | yes | 6,296 | 6,330 | +0.5% | PASS | none |
| 11 | weatherman12 | yes | 9,898 | 8,561 | −13.5% | PASS (narrow) | none |
| 12 | hot2trot | yes | 5,929 | 6,480 | +9.3% | PASS | none |
| 13 | palegrit | yes | 1,207 | 1,207 | 0.0% | PASS (exact) | none |
| 14 | Allezpapa | | 47,271 | 41,639 | −11.9% | PASS | none |
| 15 | myzbsq | | 1,003 | 1,003 | 0.0% | PASS (exact) | none |
| 16 | ndb1 | | 46,458 | 12,509 | −73.1% | INCONCLUSIVE | none (window-scope ambiguity) |
| 17 | 0x076daa87 | | 10,739 | 57,001 | **+430.8%** | **FAIL** (severe) | rebuilt + `fetchTruncated` |
| 18 | cnyek | | 1,876 | 201 | −89.3% | INCONCLUSIVE | none (window-scope ambiguity) |
| 19 | alwayslatetotheparty | | 270,446 | 258,979 | −4.2% | PASS | none |
| 20 | highnetworth | yes | 988 | 981 | −0.7% | PASS | none |
| 21 | 0xC41D736bDed9ED1acCD6 | | 22,400 | 19,289 | −13.9% | PASS (narrow) | none |
| 22 | pada | | 6,093 | 1,092 | −82.1% | INCONCLUSIVE | none (window-scope ambiguity) |
| 23 | FootballFan98 | | 21,028 | 10,643 | −49.4% | INCONCLUSIVE | none (window-scope ambiguity) |
| 24 | filthybetz | | 8,067 | 8,290 | +2.8% | PASS | none |
| 25 | wco26 | | 7,348 | 6,695 | −8.9% | PASS | none |

**All 6 "Real edge" / `copyable` wallets pass.** DEEDDIT, muchobliged, weatherman12, hot2trot,
palegrit and highnetworth were checked first, per the brief's work order, because their verdicts are
recon-gated and a truncation would invalidate the one thing this site certifies. All 6 measured
within tolerance (weatherman12 — Real edge — lands at the narrow end at −13.5%, as does
0xC41D736..., not Real-edge, at −13.9%; both inside but close to the ±15% line). **No escalation triggered**: no verdict, the
"6 of 25" count, or the frozen workpaper headline moved.

**DEEDDIT — folding U2's measurement into the existing disclosure, not duplicating it.** DEEDDIT's
largest market (`0xf5a0c2d5b6bf…`) was already known to hard-cap at 3,500 rows
(`market_capped: true`, disclosed on the workpaper since 2026-07-16 and in this row's own `why`).
U2's complete 30-day re-fetch counts **3,783** fills in that single market — confirmation that the
cap genuinely bit *within this window* (283 fills over the 3,500-row ceiling), not just a
theoretical lifetime concern. The wallet's total measured floor (8,594) still lands within tolerance
of the published 8,310, and market discovery matched exactly (17 measured vs. 17 published) — so,
per the brief's amendment 4, this is a case we have **proven consistent**, not one requiring a new
`fetchTruncated` block on top of the disclosure that already exists. No change made to the row. The
wallet-total proof lives in `u2-wallet-completeness-provenance.json`; the per-market **3,783** comes
from the same raw fetch (`scratchpad-msr/u2/DEEDDIT/`, whose `sha256` is recorded in that artifact) —
the committed artifact summarizes at wallet level only and carries no per-market split.

**Two shapes of "FAIL", not one.** maz26 and 0x2c335066FE58fe9237c3 already carried
`marketCapped: true` — our own engine's signal was never green for them; U2 is the first time the
magnitude was measured and the row rebuilt from it, rather than left as a bare flag. 0x076daa87
carries `marketCapped: false` — the same enumeration-level blind spot U1 found on swisstony, on a
**second** wallet, at a smaller but still severe magnitude (5.3× vs. swisstony's 57×). That answers
the standing question U1 left open ("whether this generalizes... is unknown"): **yes, at least once
more** — the flag-blind failure mode is not unique to swisstony. Two of three rebuilt rows follow
the swisstony pattern exactly: `nFills`/`nMarkets`/`avgBuyPrice`/`topMarket` rebuilt from the
complete re-fetch; `reconstructed`/`reconPct`/`realized`/`openValue`/the mechanism split
**not** rebuilt (same reason as U1 — `decode_v2.py` cannot ingest historical data or be re-pointed
at a past window) and disclosed as such in each row's `fetchTruncated.notRecomputedFields`. None of
the three are in the workpaper's frozen headline set (all fail its `nMarkets<=50 AND nFills<=10000`
structural rule by a wide margin, both before and after rebuild) and none carry `copyable` — the
build's own HALT guard (`tools/build-workpaper.mjs`) would refuse to publish if a `fetchTruncated`
row were ever inside that set.

**The 5 INCONCLUSIVE wallets are not a finding, and are not "fine" either — they are the method's
honest limit.** Jsram, ndb1, cnyek, pada and FootballFan98 all measured well below their published
fill counts (−31% to −89%). Per the method finding above, this direction is not provable either way
with a 30-day probe against a fetch that was never time-scoped to 30 days. No row was touched. A
future cycle wanting to close these needs one of: (a) a lifetime re-fetch per wallet (U1's swisstony
approach, ~1h and several GB each — not budgeted here for 5 wallets), or (b) a fix to
`decode_v2.py` so `nFills`/`nMarkets` are time-scoped at source, making the comparison basis
well-defined in the first place (the more durable fix — see item 6 below).

**What was tried, 2026-07-16 (retained).** A cheap screen of all 25 was attempted three times and
abandoned before this sweep — 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 read as end-of-data, reporting an 8,310-fill wallet as a 298-row
feed. None of the three methods were reused; 2026-07-18's sweep is the exhaustive recursive-window
method U1 validated, run per wallet, with backoff-protected retries specifically guarding against
the third failure mode.

**Artifacts.** `u2-wallet-completeness-provenance.json` (committed, published, repo root) — per-wallet
windows, counts, dedupe rule, raw merged-file `sha256`, the per-wallet `/trades`-vs-`/activity`
spot-check, and the PASS/FAIL/INCONCLUSIVE call and its basis. Raw fetch files (outside the repo,
hashed and cited by path in the artifact): `scratchpad-msr/u2/<handle>/summary.json`, `fetch.log`,
`merged_deduped.json`, per-window `w*.json`. Fetcher: `scratchpad-msr/u2/fetch_activity.py`.

**Exit condition — met for a subset, not all.** Original: "a per-wallet completeness proof for the
cycle... or the affected figures withdrawn." **Met for 19 of 24**: 16 proven consistent (PASS,
provenance recorded, no row change needed) and 3 proven inconsistent (FAIL, rebuilt + disclosed).
**Not met for 5** (the INCONCLUSIVE set): measured, but the method cannot produce a proof in either
direction for a published figure that was never time-scoped to begin with — carried forward, not
silently dropped, per the same rule 4 that opened this row. `SPEC_recon_error_v2.md` (iv) should be
updated to require the fetch itself be time-scoped at source for the next ingest, which would close
this class of ambiguity rather than requiring an ever-larger lifetime re-fetch per wallet.

---

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

| | |
|---|---|
| **Opened** | 2026-07-16 |
| **Surfaces** | `cases/leaderboard-autopsy.html` §02, `debased-receipts.json` (new) |
| **Status** | RECONCILED — 2026-07-18 |

**The gap, as it stood 2026-07-16.** The flagship decode's fill receipts were 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 were corrected 2026-07-16 and `tools/audit.mjs`'s `fill receipts tie` check held every line to
the rounding model the block declares — **verified by reverting both numbers and watching it fail on
each**. Fixing the arithmetic did not make the numbers sourced: there was no frozen fill log behind
them, and the wallet was published only as **`0x24c8cf69…823e1`** — a truncated address that could
not be looked up, so the subject of the flagship case study could not be re-fetched by us or by a
reader. `grep` over the repo found the full address nowhere.

**Reconciliation, 2026-07-18.** The engine repo
(`C:\Official Predict Here\trueedge-wallet-intel\`, read-only, not part of this repo) carries
debased's full address in three independent files that agree:
`debased_v2.json` (`summary.wallet`), `autopsy_full_decodes.json` (`debased.wallet`), and
`autopsy_run.log` / `run_autopsy.py`'s run-target list — all
`0x24c8cf69a0e0a17eee21f69d29752bfa32e823e1`, matching both the published prefix (`0x24c8cf69`) and
suffix (`823e1`). That repo does **not** carry fill-level data for the five receipt lines (only
lifetime aggregate stats), so those were re-fetched independently 2026-07-18: a per-market
activity-bypass pull (`decode_v2.py`'s own `full_activity()` fallback method) against both cited
markets, each paged to a clean under-cap finish — Portugal 1,125 rows over 3 pages (500+500+125),
USA 373 rows in one page, no truncation on either. The 29 fills behind all five lines (21 Portugal +
8 USA, filtered to `BUY`/`No`/price≥0.99 — the same near-certainty threshold the original
receipt-generation script used) are committed at
[`debased-receipts.json`](/debased-receipts.json), with the complete raw per-market pull's sha256
recorded there (raw file itself retained outside this repo, per the U1 convention).

Re-tying the five lines to that artifact **moved two of them again**. Using `usdcSize` — the exact
on-chain USDC amount per fill, the field this site's reconstructions treat as authoritative
elsewhere — rather than `shares × displayed price`, the largest Portugal fill sources to
**$125,950** (not the 2026-07-16-corrected $125,943) and the USA line sources to **$2,849.38**
(the 2026-07-16 pass printed $2,850): both land back on the pre-2026-07-16 figures at the dollar,
for two different reasons the artifact evidences per line. The Portugal fill's own `usdcSize` is
not its displayed price times its displayed share count (a 3-decimal display price is not the
exact multiplicand). The USA line's eight legs (8 separate on-chain transactions inside a
3-second window) all price at exactly 0.995; its 2026-07-16 figure came from multiplying a share
count that had been rounded up (2,864 for the true 2,863.7). Both lines now print in the
`shares @ avg … for $…` format — the USA line at full precision, so its printed pair reproduces
the artifact's sums exactly; the other two individual lines were already exact under the product
model and are untouched. **Remainder: $0.00** — all five published lines now equal the artifact's
own sums, held there by two `tools/audit.mjs` gates: `fill receipts tie` (each line's own
arithmetic) and `receipts tie to committed artifact` (added 2026-07-18 in review — fails if any
printed line drifts from `debased-receipts.json`'s own sums, which is the artifact tie this
paragraph previously claimed before any code enforced it).

The full address replaces the truncated one on both of its occurrences in
`cases/leaderboard-autopsy.html` §02; the disclosure paragraph is rewritten to name and link the
artifact, and a new dated correction (2026-07-18) sits beside the 2026-07-16 one rather than
replacing it. Unchanged, per DOCTRINE guarded prose: debased's exact net PnL remains
non-decision-grade, and the strategy classification still rests on the prices and sizes shown, not
on these dollar totals.

**Not covered by this reconciliation.** The autopsy card's summary stats above the receipt (`74,345
fills`, `444 markets`, `65%` / `67%` / `$0.78`) are unaffected and remain unsourced — `74,345` does
not match the engine's own `debased_v2.json` (`73,588`), a gap now logged as its own row, **U4**
below (and named in `tools/audit.mjs`'s standing notice and on the page itself). §03's table (RN1,
ImJustKen, tripping, suntori, and swisstony's own withdrawn row) is also untouched and remains
hand-typed from the same 2026-07-11 pull — that is U1/U2 territory, not U3's.

**Artifacts.** [`debased-receipts.json`](/debased-receipts.json) — committed in this repo: full
address + fetch provenance + the 29 raw fills behind the five lines + a per-line derivation record.
The complete raw per-market pull (1,125 + 373 rows, every activity type) is retained outside the
repo; its sha256 is in the artifact.

---

## U4 — the autopsy card's fills count disagrees with the engine's own output

| | |
|---|---|
| **Opened** | 2026-07-18 (found during the U3 review) |
| **Surfaces** | `cases/leaderboard-autopsy.html` §02 card sub-line ("74,345 fills"); the same card's `444 markets`, `65%`, `67%`, `$0.78` are equally unsourced |
| **Status** | UNRECONCILED |

**The gap.** The published card says **74,345 fills** for debased (`0x24c8cf69a0e0a17eee21f69d29752bfa32e823e1`).
The engine's own saved output for the same wallet — `debased_v2.json` (`n_fills`), in the engine
repo — says **73,588**. Magnitude **757**; direction: **our published figure is high** (~1.0%).
The card's other summary stats have no committed source artifact either; the fills count is the
only one with a second measurement to disagree with.

**What was tried.** Both values were read directly (the card; the engine repo's `debased_v2.json`,
the same file whose `summary.wallet` verified the full address for U3). No re-fetch was attempted;
the two figures come from different pulls on different dates, and per rule 4 no story about which
is right (or why they differ) is attached. The page now carries a one-sentence disclosure next to
the card, and `tools/audit.mjs`'s standing notice names this row.

**Exit condition.** Source the card's summary stats to a committed artifact the page renders from
(the U3 pattern — `debased-receipts.json` — is the template), or withdraw the unsourced figures
from the card.