An evidence object has already been used in an assessment.
Later, someone discovers that the normalization rule was wrong.
The team opens the stored JSON, changes the affected field, and calculates a new SHA256 hash.
The new hash matches the updated file.
But what happened to the evidence that produced the original assessment?
If the previous version was overwritten, the historical policy input may no longer exist. The current record looks consistent, but the earlier conclusion cannot be replayed from that record.
A corrected evidence file is not a preserved evidence history.
Correction is a separate event
Consider a source response containing:
status = not_configured
An earlier normalization rule produces:
enabled = false
A later rule preserves the same source value as:
enabled = null, state = unknown
The original observation has not changed in this scenario.
The interpretation has.
If the first normalized record has already been referenced by a policy evaluation, replacing its contents creates a second problem: the record no longer represents what the evaluator originally consumed.
This is not a new observation. It is not target-system remediation.
It is a revision of the evidence representation.
That distinction should survive in the evidence pipeline.
Keep both versions identifiable
A safer structure preserves three separate objects: the original evidence version, the revised version, and the event connecting them.
The revision event needs enough information to establish lineage:
Original evidence reference and digest
Successor evidence reference and digest
Original raw observation reference
Revision reason and claimed actor
Affected historical evaluation references
Authorization and re-evaluation status
The original evaluation must remain bound to its original input.
The revised representation gets a different identity.
This is consistent with the revision relationship described by W3C PROV-O’s prov:wasRevisionOf: a revised entity can be linked to an earlier entity.
The CodeYourCompliance example does not implement the W3C ontology. The relationship is a useful conceptual reference.
But recording the relationship is not enough to establish that the correction is valid.
A revision event can still be unauthorized. Its reason can be wrong. The replacement fact may require independent review.
The lineage records what changed. It does not approve the change.
Historical replay and reassessment are different operations
As discussed in Can Your Audit Evidence Survive Replay?, replay depends on preserving the evidence and evaluation context used for the original decision.
Suppose the original assessment used evidence version v1.
A later correction produces v2.
There are now two questions.
Historical replay: What result did the original policy, using the original evidence and evaluation context, produce?
Reassessment: What result would a separate evaluation produce using the revised evidence?
The second operation must not overwrite the first.
If v1 disappears, a future reviewer may be unable to reproduce the historical assessment, even if v2 is internally consistent and its hash verifies.
An old digest without the old evidence bytes does not reconstruct the original policy input.
If another independently preserved copy exists, replay may still be possible. That is a different storage and provenance claim.
What the GitHub artifact models
This week’s Evidence Revision Lineage Contract compares two synthetic structures.
In the in-place replacement example, a normalized record is overwritten. An earlier digest reference remains, but the original payload is unavailable from the modeled package.
In the linked revision example, separate versions preserve their identities, the common raw observation reference, and the original evaluation binding. A proposed revision event connects them.
The second structure preserves more information.
It does not prove the correction was approved, that either version is correct, or that an append-only storage system exists.
These are static synthetic examples. They do not execute a collector, calculate real hashes, enforce immutable storage, or replay an OPA policy. The original evaluation reference is modeled, not a runtime capture.
That is the current implementation boundary.
The audit problem starts before correction
Evidence pipelines need a way to handle errors discovered after collection.
A parser may be corrected. A source reference may be challenged. A previous evidence assertion may need to be withdrawn.
None of these events should silently mutate the historical inputs.
The pipeline should distinguish observation, transformation, revision, policy evaluation, and remediation. Each has a different provenance and authority boundary.
As argued in Compliance Automation Starts at Evidence, automating the report is not the same as establishing the evidence behind it.
The same applies to corrections. A clean, updated report does not establish what was originally observed or evaluated.
For MAS TRM-inspired engineering, this is an interpretation of what evidence must preserve to support later review. It is not a claim that the MAS Technology Risk Management Guidelines prescribe this revision schema or implementation mechanism.
A new evidence version may change what can be concluded today.
It must not erase what was actually evaluated yesterday.
Public reference artifacts
The accompanying technical material is available in the CodeYourCompliance evidence-validation-pipeline repository:
Origin and scope
CodeYourCompliance
Website: https://www.codeyourcompliance.com/
GitHub: https://github.com/codeyourcompliance
CodeYourCompliance explores replayable evidence, read-only evidence collection, provenance, integrity verification, and policy-as-code.
Attribution is requested for forks, references, adaptations, and technical discussions.
MAS TRM-inspired means engineering interpretation, not legal, regulatory, audit, certification, or compliance advice.