What
db/data/usda_snap/fy69_to_current/manifest_fy2025_monthly_source_package.yaml (package usda-snap-fy2025-monthly-state-caseloads, vintage 2025, file snap-zip-fy69tocurrent-6.zip, sha256 3eee0916…4101abe) records this storage.r2 key:
raw/usda_snap/usda-snap-fy69-to-current/2024/3eee091653335a00a80c6fe76b84904b309dddba0c8b63a256b7e079e4101abe/snap-zip-fy69tocurrent-6.zip
That is the sibling package's object (manifest.yaml, package usda-snap-fy69-to-current, vintage 2024, same bytes). The canonical location for the FY2025 entry is raw/usda_snap/usda-snap-fy2025-monthly-state-caseloads/2025/<sha256>/snap-zip-fy69tocurrent-6.zip, so the entry's recorded key disagrees with its own package and year.
How it was found
Sol's gate review of #226 (round 1). Verified by reading both manifests. chronicle inventory-artifacts --root db/data/usda_snap/fy69_to_current --manifest manifest_fy2025_monthly_source_package.yaml reports the entry valid (inventory checks bytes and locator shape, not the key's package/year), and the root sweeps do not visit named manifest_*.yaml files at all today (#226 fixes the sweep; once it lands, publish-raw over this directory will refuse the entry as recorded_r2_key_disagrees_with_country_prefix).
What to decide
The bytes are identical, so the question is provenance shape, not content: either (a) publish the same bytes under the FY2025 package's own key and record that block (keeping the FY69 one untouched), or (b) decide that a package may point at another package's content-addressed object and teach the key check to accept it explicitly. Not changing tracked data inside #226.
What
db/data/usda_snap/fy69_to_current/manifest_fy2025_monthly_source_package.yaml(packageusda-snap-fy2025-monthly-state-caseloads, vintage2025, filesnap-zip-fy69tocurrent-6.zip, sha2563eee0916…4101abe) records thisstorage.r2key:That is the sibling package's object (
manifest.yaml, packageusda-snap-fy69-to-current, vintage2024, same bytes). The canonical location for the FY2025 entry israw/usda_snap/usda-snap-fy2025-monthly-state-caseloads/2025/<sha256>/snap-zip-fy69tocurrent-6.zip, so the entry's recorded key disagrees with its own package and year.How it was found
Sol's gate review of #226 (round 1). Verified by reading both manifests.
chronicle inventory-artifacts --root db/data/usda_snap/fy69_to_current --manifest manifest_fy2025_monthly_source_package.yamlreports the entry valid (inventory checks bytes and locator shape, not the key's package/year), and the root sweeps do not visit namedmanifest_*.yamlfiles at all today (#226 fixes the sweep; once it lands,publish-rawover this directory will refuse the entry asrecorded_r2_key_disagrees_with_country_prefix).What to decide
The bytes are identical, so the question is provenance shape, not content: either (a) publish the same bytes under the FY2025 package's own key and record that block (keeping the FY69 one untouched), or (b) decide that a package may point at another package's content-addressed object and teach the key check to accept it explicitly. Not changing tracked data inside #226.