A correction should travel as far as the claim.
Correcting a source is only the beginning. AI governance also needs a bounded way to find, reassess and notify the decisions that depended on it.
Dr. Benjamin Harvey
Watch the 48-second visual essay
The source changed. Did the decision?
Imagine an AI-assisted research team discovering that a source document assigned a contribution to the wrong person. The document is corrected. But its earlier version already informed a summary, an attribution assessment and a release recommendation. Updating the document does not establish that any of those downstream judgments changed.
This is a useful way to connect this week's questions about uncertainty, authority, organization and scientific context. Each asks whether a system preserves the conditions behind a decision. Correction adds a further test: can the system respond when one of those conditions is no longer reliable?
The goal is not to erase history or automatically reverse every connected action. It is to identify potentially affected work, assign review and establish what actually happened next. A correction should travel as far as the claim—but its consequences should be assessed, not guessed.
Lineage supplies a map, not a verdict
W3C's PROV Data Model, a Recommendation dated April 30, 2013, provides concepts for entities, activities, derivations and revisions. It can describe which version was used and how another artifact was derived. Its invalidation concept marks the end of an entity's availability for use; it is not a universal label meaning that a statement is false.
That distinction matters. A provenance relationship identifies a dependency worth examining. It does not prove that an error affected the conclusion, that every descendant is wrong, or that a correction has reached an external recipient. Those are additional claims requiring evidence.
For AI IP attribution, preserve both the original assessment and its revision, with the evidence spans, uncertainty and reviewer rationale. Then separately reassess any access or release decision that relied on the assessment. Technical lineage should inform that review without being treated as a substitute for rights evidence or authorization.
Make correction an operational responsibility
NIST's AI Risk Management Framework Playbook addresses post-deployment monitoring and change management in MANAGE 4.1. MANAGE 4.3 addresses communicating incidents and errors, tracking responses and maintaining system-change records. These are governance recommendations, not evidence that a particular implementation works.
My practical proposal is a correction record with five elements: the superseded claim and exact version; the reason and evidence for the change; potentially affected outputs and decisions; a named reviewer with authority to act; and the observed disposition of each affected item. Dispositions might include revalidated, revised, withdrawn or awaiting review.
Keep notification distinct from remediation. A message sent is not proof that a recipient read it. A revised recommendation is not proof that a deployed action was reversed. In a distributed workflow, some participants may be unreachable or retain older copies. Mark those gaps explicitly instead of turning partial propagation into a clean completion badge.
Test the correction path before relying on it
A proposed evaluation could introduce a known correction into a consented, synthetic attribution workflow. Compare an ordinary event log with dependency-linked review under the same evidence, tools, time and reviewer budget. Include unaffected branches so indiscriminate blocking does not count as success.
Measure affected decisions missed, unnecessary reviews, time to a verified disposition, recurrence of the superseded claim and legitimate work completed. Independently inspect outputs and recipient acknowledgments rather than trusting the system's own completion narrative. Report unresolved branches as unresolved.
This is an experiment design, not a measured result or deployed capability. The next practical question is simple: choose one claim your team uses today. If it changed tomorrow, could you find the decisions that depend on it—and show which ones were actually reconsidered?