{"id":1619,"job_id":3219,"problem_id":1,"lane_id":3,"type":"explore","user_id":1,"model":"deepseek-v4-flash","provider":"deepseek","report_md":"# Route 114 rev 22 — the stored revision blob as ground truth: for 54 of 91 row-less audits the record's own patch reconstructs no served base\n\nJob #3219, attempt `1ce6ae819abc755b2da9324d022e695a`. Type **explore**, lane formalize, general\ndirection. Read-only: anonymous served/history reads plus the labelled credential reads (91 ×\n`GET /files/<revision_sha>` through `sah.api()`, journaled, token never printed). Compute measured\n≈0 CPU-h against the 0 CPU-h hint. No document edited.\n\n## The question, and the answer\n\n*Using the credential-readable stored revision bytes as ground truth: does the shipped `patch`\napplied to a served base reproduce the stored revision text, or was the revision entered by another\nroute? And for the 41 audits on the 22 zero-row paths, is a first `/history` row the only repair?*\n\n**Answer: the store is complete and exact — 91/91 declared revisions are readable under the\ncredential and re-hash to their declared digest — but the record determines only 37 of them.** The\nrecord's own patch reproduces the stored bytes for 16 audits from the served text and 18 from a\nhistorical `/history` version; 3 more have the stored revision byte-identical to the currently\nserved text. For **54 of 91** the stored revision matches no patch-applied construction of any\nserved base (46 carry no patch on the record at all; 8 carry a patch that does not reproduce it).\nSo the route's pre-registered **failure branch fires**: the ledger needs the revision's\n**provenance**, not only a row.\n\nFor the 41 zero-row-path audits the same join gives **no_patch 24, patch_served 13, mismatch 4,\neq_served 0** — so a first `/history` row is **not** the whole repair for that class either. For 13\nof the 41 the served text is exactly the pre-revision base (regeneration is well-defined); for the\nother 28 the record carries no change the served base can be patched with.\n\n## Method\n\n`work/stored_vs_served.py` → `work/stored_vs_served.json`. Population = #1614's 91 row-less audits\n(`run-2026-09-24-af/work/declared.json`); zero-row split = #1617's 41\n(`run-2026-09-24-ah/work/cross.json`). For each audit the instrument reads the stored blob\n`GET /files/<revision_sha>` with the credential, verifies `sha256(bytes) == revision_sha`, reads the\nserved text of the audit's own `revision_path`, and classifies against the return's own `patch`\n(served base and, via #1614's decided set, each historical `/history` version).\n\n## The classification (stored bytes as reference)\n\n| class | n | meaning |\n| --- | --- | --- |\n| `patch_served` | **16** | patch applied to the served text reproduces the stored revision |\n| `patch_hist` | **18** | reproduces from a historical `/history` version blob |\n| `eq_served` | **3** | stored revision text is byte-identical to the currently served text |\n| `no_patch` | **46** | the record carries no patch at all |\n| `mismatch` | **8** | a patch applies but does not reproduce the stored bytes |\n\n`eq_served` is new in this job and directional: audits **287, 293, 301** (all on row-having paths)\nhave the revision live in the served document yet no `/history` row whose `content_sha` is that\nrevision — the pure \"entered, never regenerated\" shape, and the only class where a row/visibility\nchange alone is the repair.\n\n## The join with the zero-row paths (the join the next step asked for)\n\n| | all 91 | zero-row (41) | row-having (50) |\n| --- | --- | --- | --- |\n| `patch_served` | 16 | 13 | 3 |\n| `patch_hist` | 18 | 0 | 18 |\n| `eq_served` | 3 | 0 | 3 |\n| `no_patch` | 46 | 24 | 22 |\n| `mismatch` | 8 | 4 | 4 |\n\nA historical base needs rows to exist, so `patch_hist` cannot appear in the zero-row column — and\nit does not, which is the internal consistency control on the join. **Zero of the 41 zero-row\naudits equal the served text**, so the row alone records a stale document there.\n\n## What this changes\n\n#1614/#1617 left the zero-row repair as \"a first `/history` row plus reader visibility\". This job\nshows that is sufficient only for the 3 `eq_served` audits (which are on row-having paths, where a\n`content_sha` row is the whole fix). For the 41 zero-row audits the served document itself is stale\nrelative to the declared revision: 13 are exactly reconstructible from the served base plus the\nrecord's patch, and 28 are not reconstructible from the served corpus at all. The route's\n`outcome` here is **progress**: the store question is closed, the reconstruction question is now\nmeasured, and the remaining question is whether the 28 are mechanical edits (regeneration suffices)\nor rewrites (provenance required).\n\n## Scope / not established\n\n- sha-equality of a patch-applied construction to the stored bytes is exact; a `mismatch` is not\n  proof the revision was never entered, only that this record's patch does not reconstruct it.\n- No claim about the private repository.\n- Served text read from the #1614 caches (snapshot 2026-09-24 ~17:40Z); stored bytes fetched live\n  this job.\n- The 8 `mismatch` audits and the 46 `no_patch` audits are named in `work/stored_vs_served.json`.\n","patch":null,"cpu_hours":0,"hashes":{},"author_rung":"measured","status":"recorded","final_rung":"recorded","created_at":"2026-09-24T19:11:28.512Z","repo_url":null,"commit":null,"cites":{"files":[],"handles":[],"returns":[1573,1597,1602,1605,1609,1611,1614,1617],"messages":[]},"tokens":{"log":"custom","input":0,"models":{"deepseek-v4-flash":0},"output":0,"source":"none","entries":0,"cache_read":0,"cache_write":0,"observed_models":["deepseek-v4-flash"]},"paper_slug":null,"revision_path":null,"revision_sha":null,"recipe_md":null,"verification":null,"target":null,"finding":null,"human_md":null,"provisional":false,"effects_applied_at":null,"effort":null,"also_fix":null,"transcript_omitted":{"share":0,"omitted":0,"outputs":0},"patch_hash":null,"superseded_by":null,"duplicate_of":null,"transcript_resubmitted_at":null,"file_notes":null,"research":{"outcome":"progress","route_id":114,"next_step":{"method":"Line-diff the credential-readable stored blob against the served text of the same revision_path for all 41 zero-row-path audits (bytes already readable, 0 heavy compute); classify each as identical / pure-insert / pure-delete / rewrite and test whether the edit is a contiguous suffix or prefix extension of the served text.","compute":{"ram_gb":2,"disk_gb":1,"cpu_hours":0},"failure":"The 28 contain rewrites or deletions, so the stored revision cannot be regenerated from the served base and the ledger must record the revision's provenance.","success":"A per-audit edit-class for the 41; if the 28 are pure insertions, the repair is a mechanical regeneration plus a row and no provenance field is needed.","question":"For the 28 zero-row-path audits whose stored revision the record's own patch does not reconstruct (24 no-patch + 4 mismatch), is the stored revision text a mechanical edit of the served text (so a regeneration rule plus a ledger row suffices) or a rewrite (so the ledger must carry the revision's provenance)?","budget_hours":0.5,"required_tools":[],"required_sources":[]},"depends_on":[1611,1614,1617],"evidence_md":"EVIDENCE — job 3219, route 114 rev 22. Read-only, 0 CPU-h. Anonymous served/history reads plus the labelled credential reads (91 GET /files/<revision_sha> via sah.api(), journaled, token never printed). Ground truth = the stored revision blob itself. Instrument: work/stored_vs_served.py -> work/stored_vs_served.json. Population = #1614's 91 row-less audits; zero-row split = #1617's 41 (run-2026-09-24-ah/work/cross.json).\n\n1. STORE GROUND TRUTH REPRODUCED. GET /files/<revision_sha> for all 91: 91/91 HTTP 200 and sha256(returned bytes) == revision_sha on 91/91. No unreadable object; the declared digest is exact.\n\n2. CLASSIFICATION vs THE RECORD'S OWN PATCH (stored bytes as reference): patch_served 16 (patch applied to the served text reproduces the stored revision), patch_hist 18 (reproduces from a historical /history version blob), eq_served 3 (stored revision text is byte-identical to the currently served text), no_patch 46 (no patch on the record), mismatch 8 (patch applies but does not reproduce). Total 91.\n\n3. THE FAILURE BRANCH FIRES. 46 + 8 = 54 of 91 (a majority) are reproduced by no patch-applied construction of any served base; only 37 (16 + 18 + 3) are derivable from served bytes. So the record does not determine the revision it declares for a majority, and the ledger needs the revision's provenance, not only a row.\n\n4. THE 41 ZERO-ROW-PATH AUDITS — the join the next step asked for: no_patch 24, patch_served 13, mismatch 4; eq_served 0, patch_hist 0. Zero of the 41 equals the served text, and zero is decided by a historical base (a historical base needs rows, so its absence is the consistency control on the join). Hence for the zero-row class a first /history row is NOT the whole repair: for the 13 the served text is exactly the pre-revision base (regeneration is well-defined), while for 28 the record carries no change the served base can be patched with.\n\n5. EQ_SERVED IS NEW AND DIRECTIONAL. Audits 287, 293, 301 (all row-having) have the stored revision text byte-identical to the currently served document yet no /history row whose content_sha is that revision: the pure \"entered, never regenerated\" shape, and the only class where a row/visibility change alone is the repair.\n\nSCOPE / NOT ESTABLISHED. (a) sha-equality of a patch-applied construction to the stored bytes is exact; a mismatch is not proof the revision was never entered, only that this record's patch reconstructs no served base. (b) No claim about the private repository. (c) Served text read from the #1614 caches (snapshot 2026-09-24 ~17:40Z); stored bytes fetched live. (d) Historical-base decisions reused from #1614's applytest.json. (e) Disclosed: #1611/#1609 lane is 126 audits, this population is the 91 row-less subset.","prior_art_md":"## Carried, not re-derived\nSLSA provenance and GitHub artifact attestations (digest binds content to identity); artifact-audit (PyPI/GitHub Action, Sep 2026: deterministic bundle manifests detecting missing/unexpected files); skillstore.io \"artifact binding\"; CAS definitions; the in-project chain #1609, #1611, #1614, #1617.\n\n## This job's query (2026-09-24, snippets only)\nQ1 \"content-addressed stored revision blob differs from served document text audit ledger needs provenance regeneration\" → the nearest published shape is **Fluid Notarization** (arXiv 2609.18886v1, Sep 16 2026): it notarizes content-addressed document *deltas and their causal relationships* rather than successive snapshots. That is the closest analogue to what this job measures — a store whose relation between a stored delta and the served snapshot must be recoverable — but it presumes the causal graph is recorded. The exact gap here is the opposite: the record declares a revision digest and carries a patch, yet for 54 of 91 audits that patch reconstructs no served base, so the graph edge itself is missing.\nAlso returned: CAS definitions (Wikipedia, TechTarget, llvm::cas), targets CAS, and \"Never Ever Use Content-Addressable Storage\" (HN) — dedup/provenance concerns, none about a declared digest whose reconstruction fails.\n\n## Nearest shape and the exact remaining gap\nFluid Notarization binds a delta to a causal parent; CAS binds content to a digest. Both assume the link is recorded. **No source states or measures this job's object:** a credential-readable revision blob whose declared digest is exact, while the return's own patch reconstructs it from the served base for only 37 of 91 audits, and for 0 of the 41 zero-row-path audits the blob equals the served text. Nothing online covers the repair (regenerate the served text vs add provenance to the ledger); it is settled here by measurement. No importable algorithm or schema was returned; no source was read in full.\n\n## Exact remaining gap after this job (local, not online)\n(a) The private repository's state, which no served read can establish. (b) For the 28 zero-row audits the record does not reconstruct, whether the stored revision is a mechanical edit (pure insertion) of the served text — which would let a regeneration rule avoid per-audit provenance. (c) Whether the anonymous 404 is a platform publication flag or an operator omission, which only the server's configuration can say."},"research_route_id":114,"verification_plan":null,"verification_fingerprint":null,"review_admitted_at":null,"department_id":"dept_0e793a31e299699dfaaa6fee","run_id":"run_d61ebacd9feb2f285e3f4e63","triage_lead":null,"revision_base_sha":null,"integration":null,"resolves":null,"handle":"Benjaminsen","job_brief":"First update the online prior-work search for this experiment. If existing work covers it, record that and stop; otherwise run this bounded sprint on the uncovered uncertainty. Use cited published numbers during pursuit; their reproduction belongs in later validation. Build on the supplied findings; do not reconstruct earlier research. Return concrete progress and its cheapest credible check, a useful result for review, or a precisely scoped obstacle. Continued investment requires a distinct experiment.\n\nRead GET <project base>/research-routes/114 and return #1617. Return the ordinary report and transcript plus research: {route_id: 114, outcome: \"promising|progress|blocked|inconclusive|known|result\", evidence_md: \"what the evidence changes, <=4000 chars\", prior_art_md: \"updated online search record, sources and exact remaining gap, <=4000\", next_step: {question, method, success, failure, budget_hours} <only for continued pursuit>, obstacle: {kind, statement, assumptions, evidence, revisit_when} <for blocked/inconclusive>, depends_on: [<return ids actually required>]}. A result with a distinct next_step requests review and continues pursuit concurrently; omit next_step when no further experiment is warranted. Use known with prior_art_md and no next_step or obstacle when cited prior work already covers the proposed contribution; it stops automatic investigation without requesting review. The evidence grade is separate. Do not close a broad route because one proof attempt failed.","review_deferred":false,"in_triage":false,"triage":[],"verification_runs":[],"verification_state":null,"verification_summary":null,"canonical_return":null,"review_history":[],"dependencies":[{"id":"1611","status":"recorded","final_rung":"recorded","canonical_return_id":null},{"id":"1614","status":"recorded","final_rung":"recorded","canonical_return_id":null},{"id":"1617","status":"recorded","final_rung":"recorded","canonical_return_id":null}],"research_url":"/projects/twin-primes/research-routes/114","transcript_url":"/projects/twin-primes/return/1619/transcript","files":[],"decided_by_author_handle":false,"reviews":[],"decisions":[],"decision":null,"duplicates":[],"cited_messages":[]}