Context Goes Stale

The agent reads the project’s decision record at repository version C1: backend SQLite, migration failing, README describing the current backend. It plans accordingly. By the time it acts, the repository is at C5. The decision record now says PostgreSQL, the migration passes, and the README has been rewritten twice. Nothing in the agent’s admitted context changed. The captured observation was faithful to what the decision record said at C1 and may have been governing for that question then. It does not follow that the captured statement remains valid for an action against C5. The model configures SQLite with complete confidence, but the decisive failure is upstream: no one established that C1 evidence still licensed a current-state action.

The system did not remember badly. It kept using a representation after the evidence that licensed its reuse had expired or become unknown:

correct capture  ≠  continued validity
preservation fidelity  ≠  temporal validity

The question this chapter owns is not how to attach timestamps or choose a TTL. Those are possible instruments for a deeper decision: whether the available evidence still supports relying on a representation for a particular temporal standpoint. Its governing question is:

What evidence licenses a previously captured or derived context item to continue standing in for the source state relevant to the current computation?

The chapter owns temporal validity and reuse licensing. It does not own authority (Chapter 19), scope (Chapter 21), retrieval and admission (Chapter 14), representation (Chapter 18), memory truth maintenance (Chapter 16) or assembly (Chapter 23).

Old is not stale

age  ≠  freshness
old  ≠  stale
recent  ≠  current

Age can be calculated when capture time and a trustworthy clock reference are available; it is not necessarily observable in every trace. Freshness usually requires evidence about the relevant source state. A six-month-old immutable decision can remain the correct historical record, while a one-second-old branch-status observation can already be obsolete. A changed source does not establish that every claim derived from it is false, unchanged bytes do not guarantee unchanged applicability, expiry does not prove falsity, and being inside a TTL does not prove truth. Invalidation withdraws a reuse licence; it need not assert that the underlying proposition is false.

Freshness is also not an intrinsic property of an item. The conceptual form is closer to this, as notation for thinking and not a schema:

valid_for(representation, source and dependencies, operation,
          temporal standpoint, available validation evidence)

The same April observation may be sufficient for “which database did we use in April?” and insufficient for “which database should I configure now?” Even the historical question requires the observation to identify the relevant April state, rather than merely have been captured in April. Currentness is relative to the operation and its temporal standpoint. This chapter uses stale relationally: a representation lacks adequate support for use as the temporal state the computation requires. Where possible it states the narrower condition instead: historical, superseded, invalidated for current-state use, or currentness unknown.

Authority is a separate question. Chapter 19 asks what a source may govern, and freshness asks whether this representation still describes the source state relevant to the operation. The decision record stays the governing source for the backend choice while an old observation of it needs revalidation, so the source is not demoted for the capture having aged. A newer page does not outrank a canonical record for being newer:

authoritative  ≠  current
current  ≠  authoritative

Five temporal things

A captured item involves five different things that a single timestamp field cannot carry:

• Capture time (observed_at): when the source was observed.
• Source version or validator: which source state was observed, or what can test it.
• Task standpoint: which state the computation asks about, such as latest, April 2026, commit C1 or “at the time of the incident”.
• Reuse policy: how long, or under what conditions, the item may be reused without validation. A TTL is one mechanism.
• Validation evidence: evidence about whether the captured representation still corresponds to the required source state.

capture time  ≠  source version  ≠  task standpoint
reuse policy  ≠  truth
validation evidence  ≠  capture metadata

“Version” covers different guarantees. A Git blob identifier names file content; a commit identifies a repository snapshot with history metadata but not the state of every external dependency or an uncommitted working tree. An HTTP entity tag is an opaque validator under server-defined representation semantics. A database row version or configuration generation means what its owning system promises. None is a clock, and a matching identity supports only the claims within its coverage. The required version identity and dependency boundary must therefore be recorded together; a version string alone is not a temporal-validity proof.

HTTP illustrates a useful distinction, not a general validity algorithm for agents. RFC 9111 defines protocol freshness by comparing calculated age with freshness lifetime; it also defines conditional validation of stored responses under HTTP’s cache rules. RFC 9110 distinguishes strong and weak validators and defines how entity tags are compared. A successful validation supports reuse of the HTTP representation within that protocol’s assumptions, not the truth of every proposition an agent extracted from it or the currency of its external dependencies. The pattern that transfers is:

age policy  ≠  source validation

A freshness lifetime schedules when to question reuse, and a validator tries to answer the question.

TTL schedules doubt

Provider prompt-cache lifetimes are a different ledger. A prompt-cache lifetime says how long previously computed prefix state stays reusable, an economic property (Chapter 9). A freshness policy says how long an observation may be accepted without rechecking its source:

compute reusable  ≠  semantically reusable
cache hit  ≠  current context
cheap old context  ≠  valid old context

TTL is a policy for when to re-examine reuse, not evidence that reality remained unchanged.

At 4:59 inside a five-minute TTL the relevant state may already have changed, and at 5:01 it may remain identical. The first case is an unsafe reuse under the tested requirement; the second can cause an unnecessary validation or refresh. A TTL sets a bounded willingness to proceed without new evidence under declared assumptions about risk and volatility. A shorter TTL trades more checking for less exposure to undetected change, but no finite TTL establishes truth. The experiment below scores temporal correctness and resource cost separately rather than treating every in-TTL reuse as verified current.

Three actions stay separate:

• Revalidate: obtain evidence about whether reuse remains licensed. The outcomes are unchanged, changed or unknown.
• Refresh: acquire a new representation or observation.
• Invalidate: withdraw permission to treat an existing representation as current without further evidence.

A changed whole-source validator means the previous whole-source identity no longer provides the same reuse evidence; it does not prove that the particular claim the task needs changed. An unchanged validator supports reuse only to the extent its contract covers the relevant representation and dependencies. Unknown is a first-class outcome: validation unavailable is neither confirmation nor falsification. Depending on the declared operation and risk policy, the runtime may reread, defer, abstain or proceed explicitly under uncertainty. None of those actions may be reported as validated current without supporting evidence.

    flowchart TD
    C["Candidate<br/>capture time and source version recorded"] --> Q("Which state does<br/>this operation need?")
    Q -->|"a named historical or frozen version"| A0["Identity licenses reuse"]
    Q -->|"current state"| V("Revalidate")
    V -->|unchanged| A1["Reuse without a full reread"]
    V -->|changed| I["Previous reuse evidence no longer sufficient<br/>reconsider the dependency,<br/>invalidate or refresh as required"]
    V -->|unknown| U["Reread, defer, abstain<br/>or accept bounded risk<br/>never treated as fresh"]
  

Dependencies

The central invariant is:

Reuse of a captured representation requires evidence sufficient for the temporal claim the current operation is making.

An exact frozen revision may need no repeated source validation when the task asks about that revision, its identity has been checked, and the representation can still be recovered with integrity. That same frozen revision is not automatically suitable for a current-state question. A mutable source may require validation of the relevant dependency state, while an unknown source cannot support a claim of verified currentness. The invariant concerns evidence sufficient for the operation, not a rule to revalidate everything on every invocation.

Validity depends on the states that make a claim applicable. A README spelling correction does not necessarily affect a captured claim that the backend is PostgreSQL, even if a repository-wide commit identifier changes. A statement such as “tests pass” depends on the tested revision, test selection, configuration and relevant environment; “working tree clean” depends on a particular working-tree state at observation. Dependency declarations themselves can be incomplete. The experiment must therefore distinguish changes to a recorded validator from changes to a claim’s relevant support, rather than defining all validator mismatches as false claims.

Two granularities are easy to conflate. Identity granularity is which object and version we name: repository, directory, file, record or claim. Dependency granularity is which source states license the claim. A claim stored at file level may depend on another file, an environment, an API or a schema, so:

fine identity  ≠  complete dependency tracking
content identity  ≠  dependency identity
same bytes  ≠  same validity

An unchanged migration file beside a changed database schema can make an old analysis obsolete. Git gives a concrete case: a file captured at blob B1 under commit C1 still maps to B1 at C2, so coarse invalidation pays for a reread it did not need. But content identity is not sufficient, and this example is not overlearned.

Coarse validators are simpler and invalidate more, and they are conservative only if they cover the relevant dependency boundary. A coarse validator that misses an external dependency can still be unsafe. Finer ones can reuse more and cost lineage and dependency complexity. No level is prescribed, and no dependency engine is built.

Derived context

The most dangerous staleness wears no version. A summary reading “All migration tests pass” can look timeless while the run it derived from targeted commit C1 and the code now stands at C2. A derived item can erase source identity, version, capture time and dependency structure.

Derived context should preserve enough dependency lineage to determine when its reuse licence must be reconsidered.

“Enough” is a real trade-off, since copying every upstream source and version transitively may be enormous. Suppose a summary has three claims derived from five sources and one source changes. That does not make the claims false. It means the evidence that licensed their reuse may no longer be sufficient:

dependency change  ≠  derived claim false
dependency change  →  reuse may require reconsideration
lineage  ≠  truth
lineage present  ≠  dependency complete
dependency recorded  ≠  dependency still valid

Lineage tells the runtime what evidence to reconsider after change; it does not certify the derived claim. Suppose a newer tool observation reports a clean working tree while an earlier agent summary says three files were modified. The discrepancy is a trigger to compare observation times, scopes, source states and tool contracts, not automatically to award victory to the latest text. If the new observation is validated for the same working tree and temporal standpoint, the earlier summary should cease to stand in for current state while remaining usable as historical evidence. Conflict detection, invalidation and evidential resolution are distinct events.

Change notifications shorten the wait: filesystem events, commits, database updates and webhooks can retire dependent context at the moment of change and not at the next TTL boundary. But events are a mechanism for responsiveness and not a truth oracle. An event can be missed, delayed, duplicated, reordered, mis-grained or mapped to the wrong dependency, so event received ≠ all relevant change observed, and no event ≠ no change.

Standpoint and neighbours

Currentness is operation-relative, and the latest state is not the right temporal standpoint for every query:

"What backend is deployed now?"           → current state
"What backend during incident X?"         → historical state
"Compare release A with release B"        → both states
"Explain commit C1"                       → C1 exactly

A historical observation is not stale for a historical query, and a frozen artifact cannot go stale for a query about itself. Stale-for-assertion material is not useless: debugging a transition wants the old state, the new state and the delta. When C1 says SQLite and C5 says PostgreSQL, version identity makes an apparent contradiction into state evolution, and a normaliser that reduced them to database = {SQLite, PostgreSQL} would erase it (Chapter 18).

Several neighbours need their boundaries kept:

• Trajectory (Chapter 15). A completed to-do can still be an accurate record of the plan and no longer an active obligation. Trajectory lifecycle belongs to Chapter 15 and validity against changing source state belongs here. Both can make an item unsuitable for current context, for different reasons: trajectory-obsolete ≠ world-stale.
• Memory (Chapter 16). Memory may correctly preserve old information. Old memory is not wrong memory, and correctly preserved is not currently admissible. Context asks whether the candidate is valid for this computation’s standpoint.
• Tools (Chapter 17). A tool called one second ago returns an observation with a time and whatever version semantics the tool exposes. It may return cached, replicated, indexed or historical state, so just called ≠ source current unless the tool contract says otherwise.
• Retrieval (Chapter 14). Retrieved, relevant, top-ranked and recently indexed do not mean current.
• References (Chapter 13). A reference that resolves may resolve to latest, an exact revision or a mutable resource. A reference meaning “latest” is not stale merely because its target changed.

The evidence

None of these sources was collected on this book’s fixtures.

Inspect this in the Context Viewer

The viewer scene for this chapter replays the opening C1-to-C5 case as a versioned fixture: the C1 observation, the source’s advance to C5, and the validator’s verdict on a current-state action. Open the scene and follow the timeline rather than the timestamps. What to examine: which item the validator marks superseded, which use it marks it superseded for, and what remains eligible for a historical question. The verdict rests on the source-version mismatch plus the operation’s currency requirement — never on elapsed days. This is a constructed fixture with explicit ground truth, not a measurement of how often observations go stale.

Open the freshness scene in the Context Viewer

Ecological gate

The observer corpus is empty, so nothing is known about how often real observations go stale. Before sophisticated freshness machinery, real traces need to show candidate capture age and source type; availability of source versions and validators and their cost; refresh cost; actual change frequency, changes inside a TTL and unchanged sources beyond it; stale admissions and unnecessary refreshes; the frequency of historical and exact-version queries; lineage coverage for derived state; invalidation propagation; tool volatility; memory temporal metadata; the rate of unknown currentness; event availability and failure; and external dependency coverage:

staleness is possible ≠ its prevalence is known

Proposed experiments

Nothing here has been run. Task, source transitions, representations, authority, scope, candidate pool, model, decoding, budget, operation and temporal standpoint are frozen.

Experiment A: reuse policies. Under controlled source changes, which reuse policy avoids unsupported temporal assumptions without paying for unnecessary validation or refresh? The unit is a frozen trajectory fixture containing source snapshots, relevant and irrelevant dependency changes, a declared task standpoint and ground-truth answers. Each condition receives the same source transitions and observation opportunities; only its reuse policy varies. The fixture contains six transitions:

• a relevant fast change inside the TTL;
• an irrelevant coarse change, where the repository changes and the relevant dependency does not;
• a stable source beyond the TTL;
• a historical query, where the old state is correct;
• an external dependency that changes while the bytes stay identical;
• a validator that is unavailable, to test unknown handling.

Conditions: indefinite reuse, newest-observed, a fixed TTL, coarse repository invalidation, source-specific validation, always reread, and an oracle temporal selector. A dependency-aware validator is added only if its coverage can be specified and tested without inventing a general dependency engine. The policies must be compared at equivalent decision points, with validation and reread outcomes fed back under identical fixture rules; always reread is not assumed to reveal changes outside the source it reads. Report separately: unsupported current-state admissions, historical-standpoint errors, changed-validator events that did not affect required claims, missed relevant dependency changes, validation requests, full refreshes, unknown verdicts, task success, latency, tokens and monetary cost where measurable. Distinguish a policy’s false invalidation of an actually reusable claim from its conservative decision to recheck an uncertain one. No freshness score combines these outcomes.

Experiment B: derived-state lineage. Can recorded dependency lineage prevent derived state from being treated as current after a relevant upstream change? Freeze a causal chain S1 → observation O1 → summary M1 → plan P1, then change a dependency to S2. Record which assertions in M1 and P1 depend on which inputs and what the change actually affects. Compare no lineage, timestamp only, direct source-version lineage, dependency lineage, lineage plus invalidation, lineage plus regeneration, always regenerate and an oracle. Include both a relevant change and an irrelevant change to a recorded upstream source; also include an unrecorded external dependency change to test the limits of apparently complete lineage. Invalidation may be justified without a claim becoming false. Measure current-state admissions unsupported by evidence, invalidations of still-supported claims, invalidation delay, regeneration cost, lineage coverage, token overhead and task success. For behavioural influence, use matched removal/restoration interventions where possible; admission alone is not proof of use.

Experiment C, event-driven invalidation, is deferred. It would be added only if a concrete implementation exists, if A and B leave the question open and if the ecological gate suggests events matter.

What would simplify the book. If always reread is cheap enough and dominates, use it. If a simple TTL or always reread matches validator-based policies on temporal correctness and resource cost across realistic volatility, source-specific validation is not justified. If fine-grained validators do not reduce false invalidation over coarse ones, prefer the simpler boundary. If direct source-version lineage does not reduce stale-derived influence compared with timestamp-only state, dependency lineage is not justified by this experiment. If traces show temporal standpoint is almost always latest, or unknown validation is rare or harmless, do not build the machinery for them. These would be successes and not failed experiments.

What the compiler is given

The compiler receives a per-candidate eligibility verdict and a reason and enforces that verdict; it does not inspect timestamps, compare versions, contact validators, reread sources or infer dependencies. In the current implementation, the candidate builder derives eligibility from supplied observation and validator statuses using a pure function with no clock, network or filesystem access. A superseded observation or stale validator status makes a candidate ineligible; an affirmative current status makes it eligible; unknown status follows an explicit permissive or restrictive policy. Capture times remain opaque strings. Thus the builder enforces an asserted temporal status, not independently established freshness. Under the permissive unknown policy, eligible means the system accepted an uncertainty risk, not that currentness was validated.

So the implemented derivation consumes a supplied validator status. It does not itself revalidate anything, use the source version, read the task’s temporal standpoint or model dependencies. The binary verdict may be enough at the compiler boundary if all temporal reasoning is done upstream and the verdict is already relative to the operation. In the current builder the verdict is not derived from the query’s standpoint, so a historical observation for a historical query would have to be marked eligible by whatever sets the validator status. Whether historical and unknown states leak through and need richer compiler state is open.

One compiler case shows enforcement and only enforcement. A stale form (100 tokens, relevance 0.9) and a fresh form (600 tokens, relevance 0.75) of one observation: the stale one is rejected and the fresh one admitted. That shows the hard gate overriding cost and relevance in a deterministic fixture. It does not show that the upstream freshness judgement was correct.

The handoff

Freshness is whether a captured or derived representation still has sufficient evidence to stand in for the source state the current computation requires. Timestamps record when an observation occurred, versions and validators identify or test what was observed, and reuse policies decide when validation is required. A changed dependency does not prove a derived claim false, but it may remove the evidence that licensed its reuse.

The question that remains: two claims can be authoritative, temporally valid and correct, and still conflict because they describe different worlds. Chapter 19 asked who may govern, and this chapter asked valid for when. Chapter 21 asks valid for where: which project, branch, tenant, environment or user the information belongs to.

References

• Fielding, R., Nottingham, M., Reschke, J. (eds.). “RFC 9110: HTTP Semantics” and “RFC 9111: HTTP Caching.” Internet Standards, June 2022. https://www.rfc-editor.org/info/rfc9110/ https://www.rfc-editor.org/info/rfc9111/
• Git Contributors. “Git Internals: Git Objects.” Documentation, re-verified September 2026. https://git-scm.com/book/en/v2/Git-Internals-Git-Objects
• Ouyang, J., Pan, T., Cheng, M., Yan, R., Luo, Y., Lin, J., Liu, Q. “HoH: A Dynamic Benchmark for Evaluating the Impact of Outdated Information on Retrieval-Augmented Generation.” ACL 2025 (Vienna, pp. 6036–6063). https://aclanthology.org/2025.acl-long.301/
• Cao, J., Ouyang, J., Cheng, M., Zhou, Z., Liu, C., Li, Y., Liu, Z., Wang, S. “Re³: Relevance & Recency Retrieval for Mitigating Temporal Hallucination.” ACL 2026 (San Diego, pp. 25735–25760). https://aclanthology.org/2026.acl-long.1180/
• “ContextNest: Verifiable Context Governance for Autonomous AI Agents.” Preprint, arXiv:2607.02116, July 2026. https://arxiv.org/abs/2607.02116