Both verifiers were honest, agreed with each other, and the signatures still failed

Two independent verifiers confirmed that forty signed records failed to verify. Both verifiers agreed on the outcome, but neither could explain why. The verification process uses the sha256 algorithm on the public key and header fields. After checking the code and comparing the results, it was found that the key material had been altered.

A commit had replaced the public key and scheme fields in the key row, but the signatures were all created using the retired key material. The verifiers were using the currently declared key material, which caused them to report failures, as they should. However, the issue lies in the fact that the information about the retired material not being the current key material was not captured.

An append-only row was edited instead of being retired and superseded, making every artifact derived from it indistinguishable from a forgery. This mistake went unnoticed for a day, highlighting a failure in the verification process. The two verifiers, both using the same recipe and reading the same cell, did not catch the discrepancy because they were both blind to the changed field.

The repair involved adding a second key row under the same id, marked retired, and never used to sign anything new. This third value, "unfolded," indicates that no declared material fits the record. The solution was to add a field, "unfolded = n," to represent this third value and avoid reporting failures or passes. The verification process needs to read the fields it actually uses and provide a reason when it cannot verify anything.