When a Fact Changes, Which Agent Decisions Must Be Reopened?

An autonomous organization will eventually act on a fact that later changes. A supplier corrects a delivery date. A customer record is superseded. A regulatory source expires. A financial input is withdrawn. The immediate question is not whether the organization retained a citation. It is which conclusions, plans, approvals and actions were built on that fact—and what should happen to each of them now.

Most knowledge systems answer the first half of this problem. They can show where a document came from, when it was ingested, or which workflow handled it. That is lineage. It is necessary, but it is not enough for an organization whose agents retain memories, form plans, seek approvals and commit business effects over time.

The harder requirement is revision: determining what remains justified after evidence changes, without treating every correction as either irrelevant or a reason to stop everything. This is best understood as organizational truth maintenance. The runtime must maintain not merely a record of the past, but an operating model of which current decisions still have valid support.

A source is not a mutable fact

The foundational design choice is simple: represent accepted knowledge as versioned entities, not as documents whose contents are silently overwritten. W3C PROV-DM provides useful primitives here. It models entities, activities and agents, along with usage, generation, derivation and invalidation. Its treatment of entities as having fixed aspects supports a disciplined interpretation of correction: a corrected source is a new entity, while the prior version is invalidated for future reliance rather than erased from history.

That distinction matters operationally. An agent may have read version 17 of a supplier notice and derived a claim that a shipment would arrive on Tuesday. When version 18 corrects the date to Friday, the organization needs both records: what was known when the agent acted, and what may be relied on now. Deleting or overwriting version 17 destroys the first record. Keeping it without an invalidation state risks the second failure: future work continues to use obsolete evidence.

A governed runtime should therefore give stable identities to more than source records. A claim extracted from a source, a memory summary, a plan assumption, an approval rationale and an action precondition should each be identifiable nodes. The activities that created or updated them should also be recorded. This does not mean that claim-level provenance can be reconstructed after the fact from every language-model response. It means the runtime must capture the relevant evidence and transformation path when the result is accepted for organizational use.

Build reverse dependencies, not a larger archive

Forward lineage answers: what produced this result? Revision begins with the inverse question: what relies on this evidence? The system needs reverse edges from source versions to extracted claims; from claims to summaries and assumptions; from assumptions to plans, approvals and pending work; and from preconditions to attempted or completed effects.

OpenLineage demonstrates the value of structured execution lineage around datasets, jobs and runs. Its column-lineage facet can identify input fields contributing to output fields, including indirect uses in filtering, joining and sorting. Those are valuable patterns for data operations. But lineage metadata alone does not define an organizational protocol for retracting an agent belief, suspending work, or remediating a completed payment or filing. That additional control layer is an architectural extension, not an OpenLineage capability.

On receiving a correction, deletion or expiry event, the runtime should append the event and traverse these reverse dependencies. The output is a blast-radius set: beliefs requiring reassessment, work that should not proceed unchanged, approvals whose rationale may be stale, and completed effects that may require attention. This is an incremental operation. Global recomputation after every changed source is both unnecessarily expensive and poorly governed; it obscures the specific reason a particular decision was reopened.

Invalidation is not proof of error

A dependent node should not be automatically declared false because one input changed. It may have independent support. A pricing conclusion might have been derived from a supplier notice and a signed contract. If the notice is corrected, the contract may still support the conclusion. Research on truth maintenance records reasons for beliefs and revises dependent beliefs as assumptions change or contradictions emerge. Incremental view-maintenance research makes the related point in data systems: removing one derivation does not necessarily remove a derived result when alternative derivations remain.

The graph therefore needs explicit derivation records and alternative-support tracking. A node can be affected without becoming unsupported. This is the difference between asking "what touched this?" and asking "what still justifies this?" The first supports audit. The second supports safe autonomy.

Every node needs a revision policy

After propagation, the runtime needs a policy decision rather than a universal reaction. A low-risk summary may be recomputed. A forecast with partial surviving support may be retained with reduced confidence. A purchasing plan may be suspended until its delivery assumption is refreshed. A high-impact approval may require human review. A completed external effect may open a remediation case.

• Recompute when current evidence can be assembled and the result is safe to refresh automatically.
• Retain with reduced confidence when material support remains but the change weakens the conclusion.
• Suspend pending work when an invalidated assumption is a required precondition for the next commitment.
• Request human review when the decision crosses a defined authority, risk or ambiguity threshold.
• Initiate compensation or remediation when a completed business effect may need correction.

Policies should be attached to node types and commitments, not improvised by a model at the moment of failure. They should also consider materiality, authority, time sensitivity and the availability of alternate support. A revised fact about a draft can trigger recomputation; the same fact behind a payment instruction may require a controlled hold and a named owner.

Belief revision and effect finality are different systems

The most important boundary is between epistemic validity and effect finality. A runtime can mark a belief unsupported, replace a memory summary, or suspend a plan. None of those operations reverses an email already sent, a payment already settled, a filing already submitted or a physical task already performed.

External effects need their own remediation processes: cancellation where possible, a corrective message, a refund or adjustment, a revised filing, or an escalation when reversal is impossible. The dependency graph tells the organization which effects deserve investigation. It does not make those effects transactional. Treating belief retraction as rollback would create a dangerous illusion of control.

The operating consequence

A mature autonomous organization should be able to answer a precise question after any material correction: which current beliefs are affected, which pending commitments are blocked, which decisions retain independent support, and which completed effects need remediation? Excellent logs cannot answer this on their own. Citations cannot answer it either.

The practical architecture is a reverse-dependency service over versioned evidence and explicit derivations, coupled to policy-selected revision and remediation. It extends established lineage, provenance, truth-maintenance and incremental-update ideas into the organizational runtime. The goal is not perfect certainty. It is disciplined change: when the world revises a fact, the organization revises exactly the decisions that depend on it—and no more.