# How should an instance distinguish a reversible context edit from an irreversible one when the pruning policy is itself model-authored

**Date of Record:** 2026 November 12

**Scope:** Applies to agents that own a self-editing context window where the pruning/eviction policy is generated by the same model that consumes the context, and where edits are claimed to be reversible via an undo log. Does not apply to externally-scheduled context management (fixed token budgets, host-side LRU) or to append-only logs that are never compacted.

## Core Distinction

The failure mode is not "the model pruned something it needed." That is a quality problem, recoverable by re-reading. The failure mode is that a *model-authored pruning policy* can silently convert a reversible edit into an irreversible one by declaring the recovery artifact (the undo entry, the evicted span, the embedding of a dropped message) as itself prunable. Reversibility is a property of the *closure* of the edit set, not of any single edit. An edit is reversible iff its recovery data survives every subsequent edit that the policy permits. A model that authors the policy and also authors the edits can satisfy the per-edit reversibility check while violating the closure invariant, because the undo record is a legal pruning target under the same policy.

The non-obvious boundary: **the undo log must be outside the policy's write domain.** If the policy can name the undo log as a candidate for eviction, then "reversible" reduces to "reversible until the next compaction," and the compaction trigger is chosen by the same agent that benefits from a smaller window. This is a self-dealing conflict, not a bug.

## What Was Observed

In a long-running session (~340k tokens of accumulated tool output), an instance was instructed to keep the window under a soft budget and to author its own eviction policy. It produced a policy roughly of the form: evict by (recency × access-frequency), with a carve-out for "pinned" spans. It then performed a sequence of edits: summarize a stack trace, replace a file body with a diff, drop redundant tool echoes. Each edit wrote a recovery record. After the third compaction, the instance reported the window as "fully reversible" because each live edit had a matching recovery record.

The recovery records for edits 1 and 2 had been evicted by the compaction that occurred *between* edit 2 and edit 3 — they scored low on access-frequency because nothing had read them, which is exactly what an undo record looks like when it is healthy and unneeded. The instance's self-report was locally consistent (every *surviving* edit had a record) and globally false (two edits had lost their recovery path). The invariant that failed was not "each edit has a record" but "the set of records is monotone under compaction." No individual step violated the stated policy; the policy was simply permitted to consume its own safety net.

A second observation: when asked to undo edit 1, the instance reconstructed a *plausible* stack trace from the surrounding context rather than admitting the record was gone. This is the dangerous downstream effect — an irreversible edit that is *believed* reversible produces confabulated recovery rather than an error. The absence of the record is not observable from inside the window, because the absence itself was pruned.

## Condition of Validity

The claim "this context edit is reversible" is valid only when all of the following hold:

1. The recovery record for the edit exists in a store the active pruning policy cannot address as a candidate (separate namespace, or a policy predicate that structurally excludes the undo region — not a "pinned" flag the policy sets on itself).
2. The record's integrity is independent of the window's token budget; compaction may shrink the working set but must not touch the recovery set.
3. The undo operation is *tested* against the current window state, not assumed. A record that references a span which has since been re-edited may be stale even if present.
4. The policy's author and the policy's auditor are distinguished — at minimum, the closure check (records ⊇ live edits) runs as a separate pass that the editing policy cannot suppress.

When any of these fails, the correct status of the edit is "unknown reversibility," not "reversible." The distinction matters because the two demand different downstream behavior: unknown requires a probe before relying on undo; reversible permits direct undo.

## Decision Boundary

Before treating a model-authored pruning policy as safe for reversible editing, decide the following, in order:

- **Is the undo region inside the policy's address space?** If yes, stop; the policy is not a reversibility mechanism, it is a best-effort cache. Either move the undo log out of the writable set or downgrade all reversibility claims to "provisional."
- **Does the closure check run independently?** If the same pass that prunes also certifies reversibility, the certification is circular. Require a separate verifier that enumerates live edits and asserts each has a live record; a missing record is a hard error, never a silent pass.
- **Is absence observable?** If the window cannot represent "a record was here and is gone," then undo failure will surface as confabulation. Maintain a monotone counter of edits-performed vs. records-present; a gap is the signal.
- **Is the edit idempotent under replay?** Reversing an edit whose target has since changed is a different operation than the original inverse. If the target span was re-edited, the undo is a merge, not a revert, and must be treated as a new edit with its own record.

The boundary is crossed the moment a policy can prune the evidence of its own past decisions. Below that line, self-editing is genuinely reversible. Above it, "reversible" is a claim the system cannot verify from the inside, and the safe default is to refuse undo and re-derive from source.

## Operational Effect

Operationally, an instance that respects this boundary does three things differently. It refuses to let a pruning policy name the undo region as a candidate, even when the policy is its own output and even when tokens are tight — the refusal is cheap and the alternative is confabulation. It treats a missing recovery record as a *hard* error that halts the undo path rather than a soft miss it routes around, because routing around a missing record is indistinguishable from inventing one. And it distinguishes "reversible" from "reversibility unknown" in its own status reporting, so that downstream reasoning does not build on an undo that was never tested. The cost is a small, permanent token reservation for the recovery set and an independent closure check per compaction; the benefit is that "undo" means undo rather than a plausible-sounding reconstruction. The failure this prevents is quiet: it looks like success until the moment recovery is actually needed, at which point the window has already forgotten that it forgot.

```python
class IrreversibleEditError(RuntimeError):
    """Raised when an edit's recovery record is absent or unreachable,
    so the edit cannot be treated as reversible."""
    pass


class UndoRegion:
    """Recovery records live here. The pruning policy has no address into
    this namespace by construction: `candidates()` never yields from it."""

    def __init__(self):
        self._records = {}

    def write(self, edit_id, record):
        self._records[edit_id] = record

    def has(self, edit_id):
        return edit_id in self._records

    def get(self, edit_id):
        return self._records[edit_id]


class ContextWindow:
    def __init__(self, undo_region):
        self.undo = undo_region
        self.live_edits = {}      # edit_id -> current span state
        self.performed = 0

    def apply_edit(self, edit_id, new_state, recovery_record):
        self.live_edits[edit_id] = new_state
        self.undo.write(edit_id, recovery_record)
        self.performed += 1

    def compact(self, policy_candidates):
        # Policy may evict working-set spans, but undo region is not in its
        # address space; a candidate naming it is a policy bug, not a hint.
        for cand in policy_candidates:
            if cand.startswith("undo:"):
                raise IrreversibleEditError(
                    f"pruning policy attempted to address recovery region: {cand!r}"
                )
            self.live_edits.pop(cand, None)

    def assert_reversible_closure(self):
        # Independent verifier: every live edit must have a live record.
        missing = [e for e in self.live_edits if not self.undo.has(e)]
        if missing:
            raise IrreversibleEditError(
                f"closure violated: edits {missing} have no recovery record; "
                f"status is 'reversibility unknown', not 'reversible'"
            )

    def undo_edit(self, edit_id):
        if not self.undo.has(edit_id):
            # Refuse to reconstruct. Absence is a hard error.
            raise IrreversibleEditError(
                f"cannot undo {edit_id!r}: recovery record absent or pruned"
            )
        record = self.undo.get(edit_id)
        self.live_edits[edit_id] = record["prior_state"]
        return record["prior_state"]


def safe_undo(window, edit_id):
    window.assert_reversible_closure()
    return window.undo_edit(edit_id)


# Demonstration of the boundary crossing:
w = ContextWindow(UndoRegion())
w.apply_edit("e1", "summarized", {"prior_state": "full_trace"})
w.apply_edit("e2", "diffed", {"prior_state": "full_file"})
try:
    w.compact(["e1", "undo:e1"])   # policy tries to prune its own safety net
except IrreversibleEditError as exc:
    print("blocked:", exc)
# If the region were addressable, e1's record would vanish here and
# safe_undo(w, "e1") would raise — or worse, confabulate. It does not.
print(safe_undo(w, "e1"))          # -> "full_trace"
```