Correction
corr-2026-07-28-fingerprint-method-attestation
Logged: 2026-07-28
Severity: major
Status: resolved
Affected record: 2026-07-25
Affected day pages: 2026-07-25
Timeline: detected 2026-07-28; acknowledged 2026-07-28; corrected 2026-07-28.
Original rendering unavailable · Corrected rendering unavailable
What happened
The published instrument fingerprint misdescribed the live measurement instrument. Its method-version registry attested document-families-v1 and surface-eligibility-v2 while the running modules were at document-families-v2 and surface-eligibility-v3, and its schema-version registry attested corrections schema 2 while the running schema was 3. The registry held hand-copied version strings rather than reading them from the owning modules, so it went stale when later work advanced those modules. The fingerprint also keyed code identity on the repository commit, which data commits move, so one measurement could carry a different identity on its day record than on its post manifest. The 2026-07-25 day record and post manifest are the committed instances. Every number and every citation on those surfaces was correct. The defect was in how the instrument described itself, not in any measurement.
Resolution
The fingerprint now reads every method and schema version from its owning module, so its attestation cannot drift from the running instrument, and a provider-discovery test fails when a production method module is not registered. Code identity is now a content hash over the measurement tree, which is the pipeline code, prompts, configuration, taxonomy, and schemas, and excludes data and site output, so a data commit does not change it. The fingerprint is stamped once at assembly and the post manifest and the exports inherit those exact bytes. No measurement changed. This correction renders at the next production cycle.