C-83 — full-population hash sweep bounds the tampering residual to metadata, not bytes - #172
Merged
Conversation
Sync main back to development after #166
…g residual (#170) The 2026-08-15 triage checked the eleven rows whose $updatedAt had moved and predicted that hashing the remaining 572 would add nothing. Against substituted bytes that prediction held exactly; this does not correct it. Every row was re-downloaded and re-hashed anyway: unfao 111/111 and production_forecasts 461/461 match their recorded file_hash. sha256, confirmed empirically across all 572 rather than assumed. Read-only, GET only. What the sweep adds is a fact a sampled method could not reach: rows and files are a perfect bijection — 0 files without a row, 0 rows without a file, in both buckets. A count-preserving delete-and-recreate must point its new row at a file that already exists, since the buckets were never writable; pointing it at a file another row already claims leaves the displaced file an orphan. There are none, and there were no unreferenced files to point at. What survives is smaller and still unfalsifiable: a delete-and-recreate preserving fileId and file_hash while altering only descriptive fields. The residual is now bounded to metadata semantics rather than file bytes.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Brings
mainup to date with the one commit ondevelopmentsince #166.What this carries
#170 — the full-population hash sweep on C-83. 22 lines added to the register, one amendment
block under the existing verdict. No other file changes.
Every row in both delivery collections was re-downloaded and re-hashed, not only the eleven the
triage flagged:
unfao111/111 andproduction_forecasts461/461 match their recordedfile_hash. sha256, confirmed empirically across all 572 rather than assumed. Read-only,GETonly.The amendment is explicit that it narrows the residual without correcting the triage — the
triage's prediction, that hashing the rest would add nothing against substituted bytes, held exactly.
What the sweep added is a fact sampling could not reach: rows and files are a perfect bijection,
0 files without a row and 0 rows without a file, in both buckets.
That closes the delete-and-recreate route. A count-preserving recreate must point its new row at a
file that already exists, since the buckets were never writable; pointing it at a file another row
claims leaves an orphan, and there are none.
What survives is smaller and still unfalsifiable: a delete-and-recreate preserving
fileIdandfile_hashwhile altering only descriptive fields (targets,name,description). The residualis now bounded to metadata semantics rather than file bytes.
Gates
Docs-only change — carbon protocol §2 waiver applies to the bare-pytest gate, recorded here.
Everything else run on the merge base:
Register counts reproduce by
grep: 64 concerns, 12 resolved, unchanged — this amends anexisting entry rather than adding one, which also keeps epic #157's guardrail intact (no register
entry below Tier 2 created while the epic is open).
Context
The blocker on the rest of epic #157 cleared separately: views-pipeline-core#483 merged
2026-08-24, so #160 (S3) and #163 (S6) are now actionable. This PR is not part of that — it is the
C-83 evidence trail catching up to
main.