Retroactive Revision

Status: Design landing Reference epics: INK-829

What retroactive revision is

When a piece of workspace content changes, other content that was derived from it becomes potentially stale. Retroactive revision is the world model’s mechanism for noticing that staleness and bringing it to the author’s attention, without silently regenerating anything.

The mechanism is built on two primitives already in the world model:

• Derivation links — the graph edges that record which content supports which. When a source changes, walking its inbound derivation edges identifies every piece of derived content that could have gone stale.
• Standing — the derived signal that measures how load-bearing a piece of content is in the world’s structure. A change to high-standing content propagates consequences farther and matters more than a change to a peripheral page.

Retroactive revision uses the first to identify what to flag and the second to decide how prominently to flag it.

Flag, never rewrite

The cardinal rule: the world model flags; it does not auto-rewrite. When a source changes, derived content is marked for re-validation and surfaced to the author. It is not silently edited to match the revised source.

This is deliberate. Silent regeneration of derived content violates the author-authority principle (see World Agent § Author authority). The author’s world is composed of pieces the author has accepted; a silent rewrite of accepted content is the world changing its own mind, which is exactly what the product refuses to do.

The agent may propose a revision to stale content, either conversationally or as part of a scheduled task. That proposal is an ordinary submit that crosses the submit boundary, lands as candidate content, and requires the author’s explicit act to become canonical. The proposal path and the flag path are distinct: flagging happens automatically on any source change; proposing is agent work that produces a candidate (and potentially a deviation record, if the proposal conflicts with the existing canonical derived content).

The re-validation queue

Flagged items enter a re-validation queue — a surface the author and the agent both read.

The queue is a product surface that reads from the workspace graph (specifically, derivation-link edges with their most-recent-source-change timestamps) rather than a separate store with its own persistence model. A flag is materialized by a source change; it is cleared by the author taking one of the three resolution actions below. No flag state lives independent of the derivation graph.

From the queue, each entry surfaces:

• The derived page (with an inline marker on its surface indicating it has an open re-validation flag).
• The source that changed.
• The diff of the source change.
• The flag’s prominence, derived from the source’s standing at flag creation time.

Standing-sensitive prominence

Flag prominence in the re-validation queue scales with the standing of the content whose change propagated:

• A change to high-standing content produces a prominent flag. The queue surfaces it first; the inline marker on affected pages is visually distinct.
• A change to low-standing content produces a routine flag. It enters the queue and the inline marker appears, but neither competes for the author’s attention when higher-prominence work is pending.

Prominence is a presentation and triage rule, not a gate. Every change to every source produces a flag on every derived page. Standing influences ordering and visual weight, not whether the flag exists. This preserves the no-middle-ground stance of the provenance model: standing is a signal, not a gate.

Standing is read at flag creation time, not re-evaluated continuously. If a source’s standing rises or falls after a flag was created, existing flags keep their original prominence; new flags from subsequent source changes reflect the newer standing. This keeps the queue’s ordering stable as the author works it, rather than reshuffling underfoot.

Three options

For each queue entry, the author has three options — the same three available for any content the world is asking them to reconsider:

1. Accept as still valid. The derived content remains accurate despite the source change. The flag is cleared with an acceptance note. The derivation link is retained as-is; the re-validation queue moves on.
2. Update. Edit the derived content to reflect the revised source. The edit is an ordinary authored submit (origin: authored, lifecycle: canonical). Clearing the flag happens as a side effect of the edit crossing the submit boundary; the flag’s resolution is recorded.
3. Retire. The derived content was written under assumptions the source no longer supports, and a simple update won’t do. Retirement is a lifecycle transition; the derivation links the retired content holds are preserved in the graph but no longer contribute to the source’s standing accrual (per Derivation Links §lifecycle).

The agent can propose any of these actions as a candidate for the author to accept; the agent cannot take them itself on canonical content without author action.

Who walks the queue

Three parties can process re-validation queue entries:

The author. Through the queue surface (and via inline markers encountered while editing). Author action is the only path that clears a flag on canonical content without producing new candidates.

The conversational agent. When the author is in conversation and the agent reaches content with an open flag, it surfaces the flag and may propose resolution. The author accepts or rejects the proposal. This is the same propose/dispose relationship that governs every other agent write.

Scheduled autonomous tasks. Re-validation queue processing is a scheduled-task category. When the author has granted the agent scope for it (granted by default per PL-C but revocable), the agent walks the queue on a cadence, producing candidate revisions and deviation records. The author finds the results in the triage inbox and the candidate surface the next time they look.

Scheduled walks weight their attention by flag prominence: high-standing-source flags are processed first. The goal is to have the most-consequential staleness surfaced or proposed-on by the next time the author looks, even if the queue is long.

Relationship to deviation records

Retroactive revision and deviation records are distinct mechanisms that can appear together:

• Retroactive revision flags noticing that a source changed. It is proactive and routine; every source change fires flags on every derived page.
• Deviation records capture a specific, detected disagreement between two pieces of content. They are detected and recorded, not merely flagged.

The common path where both appear: a scheduled task walks the re-validation queue, reads a flagged derived page, compares it against the revised source, and finds the derived content now directly contradicts the source. The scheduled task produces a deviation record (type agent-inference-revisited) and may also produce a candidate revision. The re-validation flag is not automatically cleared by the deviation-record creation; it clears when the author takes one of the three resolution options above.

What retroactive revision is not

• Not cascading rewrite. Flags do not propagate through derivations transitively by default. If A changes and B was derived from A, B is flagged. If C was derived from B, C is not flagged by A’s change — C’s flag fires only when B itself changes. This is deliberate: the flag measures “a thing you built on has moved,” not “something three hops upstream has moved.”
• Not a validator. The queue does not assert that flagged content is wrong. It asserts that the source changed; it is the author’s (or the agent’s, on proposal) job to judge whether the change propagated to the derived content.
• Not limited to agent-produced content. Authored content can be derived from other workspace content (through explicit citation, for example — see Derivation Links §when created) and participates in re-validation the same way.

Worked example

Moment 3 — Source edit and retroactive revision shows retroactive revision firing end-to-end. The author rewrites the cost-scaling section of The Nature of Binding — a high-standing page. Every derived page gets a prominent re-validation flag. The author sets the queue aside to finish her scene; a scheduled task walks the queue that night and produces Moment 4’s deviation record on the page whose cost section now directly contradicts the revised source.

What this page does not do

• Does not describe the derivation-graph substrate. See Derivation Links.
• Does not describe the standing computation. See Provenance §standing.
• Does not describe deviation records produced by scheduled walks. See Deviation Records.
• Does not describe the scheduled-task registration surface. See the platform docs for scheduling.