The compressed sentence is a memory of a conclusion. It is not evidence for that conclusion, and it has lost the condition that made the conclusion true. If the agent is going to make a new claim after compaction, it needs the source identity, revision, exact supporting span, effective interval, permission context, and the question or transaction to which the span was applied. Some of that can be kept as small references. The text can be fetched again when needed. Merely stuffing the entire original conversation back into a prompt defeats the budget and still leaves the agent guessing which span was authoritative.

I would separate a run's durable evidence ledger from its next model context. An evidence item names (tenant, source object, revision, span or table cell), the captured bytes or a verifiable hash where retention permits, the retrieval time, and the authority and applicability checks made then. A claim records which evidence items supported it and any transformation, such as selecting the rule for purchases after June. The compacted context may carry a short reminder and those IDs. The answer builder resolves them against the ledger and checks current permission, deletion, and policy validity before showing the claim or citation. W3C PROV-O gives a vocabulary for entities and derivation. The particular ledger and authorization rules are our system design.

This does not mean an old decision is always replayed as the current answer. A later user may ask about April purchases, the policy may have changed, or the user may have lost access. Treat the compacted statement as a hypothesis to revisit. Fetch the revision and its effective interval, or retrieve new authoritative evidence if the question changed. A source ID is useful because it prevents accidentally citing a similarly named page, but even the correct source revision can be inapplicable to the user's date.

Some compaction mechanisms are opaque. OpenAI's current compaction guide describes an opaque compaction item that carries prior state in fewer tokens. I would not assume I can inspect or force that item to retain a claim's citation span. The application owns the evidence contract outside the model context and validates citations from it. The same principle applies to a homegrown text summary, where the loss is visible.

Now the cited revision has been deleted under a retention request. Do not restore private bytes from a long-lived agent checkpoint just to defend the old answer. Invalidate the evidence reference for future disclosure and find a permitted current source. If none exists, the agent should say it cannot substantiate the claim. An audit may retain limited metadata under a separate retention rule, but a citation is not a way around deletion or access control.

One more difficult case: the original claim was wrong. An immutable ledger should preserve what was seen for incident reconstruction, not elevate it to truth. Corrections produce a new claim with its own evidence and a link to the superseded conclusion. When the agent resumes, it should not silently treat an old summary as a system instruction. I would evaluate this with changed effective dates, revoked access, deleted sources, and two near-identical policy titles across a compaction boundary.