Freshness, Supersession and Valid-Time Evidence

“Latest” is not a temporal model

A live banking agent is asked why a corporate payment was held. It retrieves a screening result updated three minutes ago, a customer risk record changed yesterday, a sanctions procedure published last week and a payment event created this morning. Every item looks fresh. The result can still be wrong.

The screening record may be a correction entered after the payment decision. The customer risk change may take effect tomorrow. The procedure may replace an earlier version only for payments initiated after a transition date. The event time carried by the payment may differ from the time the message reached the bank. An analyst may need the best current explanation, the evidence actually available when the hold occurred, or both.

Recency scoring collapses these questions into one number. A timestamp is sorted, newer items rise, and the model is told to prefer recent sources. That design confuses arrival, observation, validity, publication and decision time. It also treats replacement as similarity: the retired procedure remains almost identical to its successor and may rank beside it.

A decision-grade agent needs temporal semantics before it needs a freshness boost. Every material claim should carry the time in the world for which it is asserted, the time the system learned it, its source version, and its relationship to later corrections or replacements. The agent should answer against an explicit temporal frame and preserve evidence that was valid then even when it is no longer current now.

This article develops that design through a composite case at “Harbour Bank.” The institution, customer, payment, timings and operating thresholds are fictional. Public standards and documentation support the architecture; no production outcome is claimed.

Harbour bank’s two correct answers

At 10:04 local time, Harbour Bank receives a corporate payment instruction from Meridian Shipping. At 10:04:08, the screening service produces a possible match and the payment orchestration applies a hold. At 10:06, an operations analyst clears the alert after comparing date of birth and nationality. At 10:09, a source feed issues a correction to the candidate record. At 10:12, the customer’s relationship manager asks the agent, “Why was this payment held?”

There are two defensible answers to different questions. The operational-history answer is that the payment was held because the screening result available to the payment workflow at 10:04:08 met the configured hold rule. The current-evidence answer adds that the possible match was later cleared and the external candidate record was corrected. Saying only “the customer matched” is false now and overstates the evidence then. Saying only “there was no match” erases why the deterministic workflow acted.

The case becomes harder because Harbour’s screening procedure changed that morning. Version 7 was published at 08:00, approved at 09:30, configured with an effective time of 11:00 and intended for payments initiated after that time. A search ordered by publication time will retrieve version 7. The 10:04 decision was governed by version 6.

History, current truth and counterfactual replay are separate products. A fluent paragraph can contain all three only if each clause identifies its temporal basis.

Four clocks, not one timestamp

The architecture needs at least four clocks. Valid time says when a proposition holds in the represented world. Observation time says when a source observed or asserted it. System time says when Harbour recorded that assertion. Decision time says when a control or human acted. Publication and effective time are specialised clocks for governed artefacts.

System-versioned databases often focus on when a row was current in the database. Microsoft’s current temporal-table documentation describes a current table, a history table and system-managed period columns that support point-in-time queries. This is valuable for reconstruction, but application semantics may need a second valid-time interval supplied by the business event.

A source can report late. A beneficial-ownership change valid from Monday may reach the bank on Thursday. A correction recorded today can say that a prior fact was never valid. A procedure published today can become effective next month. One updated_at column cannot represent these cases.

RFC 3339 defines an interoperable Internet timestamp profile, while RFC 9557 extends it with additional information including time zones. These standards help encode instants; they do not decide which clock a field represents. Every temporal field still needs explicit semantics and a declared time zone or UTC normalisation rule.

Timestamp precision does not create temporal meaning. 2026-07-22T10:04:08.123Z can be precisely wrong if it stores arrival when the decision needs validity.

Use bitemporal evidence for correctable facts

Bitemporal storage keeps valid time and system time. It can answer, “What did we believe on 22 July about what was valid on 20 July?” That question is essential when data arrives late or is corrected.

Suppose the candidate feed initially says a date of birth is 1978. At 10:09 it corrects the value to 1987 and states the earlier value was an editorial error. The 1978 assertion was present in Harbour’s system between 10:04 and 10:09, but it was never a valid birth date according to the corrected source. The store retains both facts: one as historical system knowledge, the other as the source’s current valid-time assertion.

A bitemporal evidence row should be immutable. A correction creates a new assertion and a relationship; it does not rewrite the old payload. The system can materialise a current view for fast operations, but the evidence ledger retains the history needed for reperformance.

The design does not mean retaining every personal-data version forever. Legal, privacy and records policies govern retention. Temporal correctness and minimisation can coexist through scoped history, cryptographic evidence references, approved redaction and deletion receipts. Where a historical value must be erased, the system should preserve a non-sensitive event that a correction or deletion occurred rather than pretend the original version never existed.

Supersession is a graph, not a boolean

A superseded=true field says an artefact is no longer primary. It does not say what replaced it, for which scope, from when, or whether some provisions survive. Policies are amended, partially replaced, corrected, consolidated, suspended, reinstated and retired. Evidence sources are retracted or updated. Model and index artefacts also acquire successors.

Represent the relationship as a typed edge with scope and time. replaces can cover the full predecessor. amends can target clauses. corrects changes interpretation without necessarily changing effective scope. retracts warns that a source should not support new conclusions. consolidates may provide a convenient view while preserving the authority of constituent changes. suspends is temporary and may be followed by reinstatement.

Crossref’s current versioning and correction guidance illustrates why typed update relationships matter in scholarly records: significant updates, corrections and retractions should be identifiable and connected rather than silently overwriting the prior record. Bank policy artefacts need their own controlled vocabulary, but the recordkeeping principle transfers.

Never discard the predecessor merely because a successor exists. Never present the predecessor as current merely because history is retained.

A temporal evidence envelope

Every item admitted to an agent context should arrive in a temporal evidence envelope. The envelope separates source content from claims about its status. It names the proposition, evidence class, source and version; valid and system intervals; supersession edges; retrieval time; authority, and integrity reference.

The source content may be a short excerpt, structured record or object reference. The envelope should not claim more precision than the source provides. A policy can have a date with no time. A customer statement may say “since June” without an exact instant. Approximate and open intervals are legitimate values; they should not be filled with midnight defaults that later look authoritative.

The W3C PROV-O Recommendation offers a standard vocabulary for provenance involving entities, activities and agents, and includes generation and invalidation times. The W3C OWL-Time specification describes temporal entities and interval relations, though its current published page is a Candidate Recommendation Draft and explicitly notes limits. A bank can use concepts from both without claiming either specification defines its full evidential semantics.

Envelopes make derived evidence honest. A model-generated summary points to the exact source versions and a generation activity. It gets its own recorded time and validity limitation. It cannot inherit the authority of the underlying policy. If the policy is corrected, the summary becomes stale even if its text remains semantically similar.

Freshness is a contract per proposition

Some facts change many times a second; others remain stable for years. Freshness cannot be one global maximum age. It is a contract among the decision, proposition, source and consequence.

For a live payment decision, account status and screening configuration may require a near-live authoritative read. A customer’s incorporation date may be read from a validated reference with a longer permissible age. A policy clause is fresh if the correct effective version and all active amendments are present, not if the PDF was downloaded recently. A research note may be current enough for background but inadmissible for the decision.

The freshness contract includes an outage disposition. must_revalidate stops a live decision if the source is unavailable. historical_only permits explanation of what was previously known but not a new action. bounded_stale may allow a low-consequence task within an approved interval. manual_source routes an authorised user to the system of record.

Staleness is a decision state, not a search penalty. Lowering a score still lets an expired waiver or retired procedure enter the answer.

Snapshot the evidence state for reperformance

An evidence packet that stores only URLs cannot be replayed. The source may change behind the URL, the index may be rebuilt, and a database query may return a different row. Reperformance needs stable versions or snapshots.

Open table formats provide useful infrastructure. Apache Iceberg’s official documentation describes snapshot-based time travel for reproducible queries. Delta Lake’s documentation describes data versioning and time travel. Microsoft temporal tables support system-time queries. These technologies preserve storage states; they do not automatically capture policy meaning, external source corrections or the data actually exposed to a model.

Pinning all sources to one wall-clock instant is not always possible. External APIs may expose only current state. In that case the manifest records the retrieval time, response version or hash, and the limitation. A decision may combine a warehouse snapshot at 10:04 with an external response retrieved at 10:05. The packet should state that boundary instead of claiming perfect transactional consistency.

Snapshot retention must align with assurance and records requirements. Iceberg or Delta time travel depends on retaining the referenced history. A snapshot ID that has been expired is not reproducibility. The programme should protect decision-linked snapshots or export a governed evidence extract, subject to privacy and retention policy.

Event time and processing time must not be confused

Streaming pipelines receive late, duplicated and out-of-order events. A payment event created at 10:04 can arrive after a case event created at 10:05. A source can resend the same correction. A clock can drift. If the temporal registry simply applies messages in arrival order, its current view may regress.

Each event needs a stable identifier, source sequence where available, event time, ingestion time, schema version and idempotency rule. The projector evaluates source-specific ordering. It can update a current view while preserving the raw event. Events outside an allowed lateness window are not silently dropped; they enter a correction or reconciliation path.

Watermarks are operational estimates, not proof that no earlier event will arrive. A low-latency agent can use the current materialised view if the decision contract accepts its completeness bound. A historical investigation can wait for reconciliation or query the immutable log directly.

Clock synchronisation also has limits. Use UTC instants for machine comparison and retain source offset or time-zone information where it affects interpretation. Record precision. Do not compare a date-only policy with a nanosecond payment event by inventing an effective instant without an approved convention.

Build temporal queries from the decision schema

The user should not have to formulate temporal SQL. The decision schema identifies which propositions need current truth, historical knowledge or a counterfactual. A temporal query compiler lowers that frame into source-specific queries and validates the returned envelope.

For “why was the payment held,” the schema asks for the payment state and screening observation valid at the decision instant, constrained to system knowledge available no later than that instant. It asks for the procedure effective for the payment event. It separately asks for later corrections so that the explanation can distinguish then-known cause from current evidence.

Temporal joins need explicit boundary conventions. Most intervals work well as half-open [start, end), which avoids double membership at a handover instant. Date-only policies need an approved effective-zone rule. Events with uncertain times require interval reasoning rather than exact equality. A source correction may change valid time retroactively while leaving the historical decision time unchanged.

Invalidate derived artefacts through lineage

Every summary, embedding, index chunk, extracted entity, answer cache and benchmark label depends on source versions. When a source is corrected or superseded, the system must identify which derived artefacts may be invalid.

The OpenLineage specification models jobs, runs and datasets and includes dataset version facets when a platform defines them. It is useful pipeline metadata, not a full assertion-level supersession model. Harbour can combine run lineage with evidence dependencies: source version → extraction run → normalised assertion → chunk → embedding → index snapshot → evidence packet.

Invalidation does not mean deleting the historical chain. It marks derived artefacts unsuitable for new current-state answers and opens impact review for past decisions where the correction could matter. The source owner defines whether a change is editorial, interpretive or decision-material. A punctuation fix need not trigger the same response as a corrected sanctions identifier.

The system needs a completeness check: all production projections of a source class must register lineage. An experimental index that is not in the graph will continue serving stale content. Access logs and package manifests can help discover undeclared consumers.

Temporal consistency across tools

An agent may retrieve a customer state, call a policy service, query a transaction store and ask another agent for analysis. If each call uses “now,” a long task can mix states that never coexisted. A payment can change from held to released midway while the narrative still cites the earlier alert.

The orchestration layer should establish a decision cut-off and propagate it. Where sources support snapshots or as_of reads, each tool uses that time or snapshot. Where only current reads exist, the receipt records actual access time and the orchestrator checks for material state changes before final output or action.

Before a consequential action, use optimistic concurrency: submit the state version on which the recommendation was based. The downstream system rejects the action if the record changed. The agent then recompiles. Temporal evidence without execution-time version checks leaves a race between reasoning and action.

Present time without hiding uncertainty

Reviewer interfaces often display one “last updated” label. That can refer to the case, screen, source or derived summary. Use labels that name the event: “source observed,” “bank recorded,” “valid from,” “policy effective,” and “packet retrieved.” Show the decision cut-off prominently.

For Harbour’s case, a timeline is more informative than a paragraph. It places the hold, analyst clearance, source correction and procedure change. The proposition ledger then shows which assertion was used for the historical explanation and which supersedes it for current status.

The interface should not colour every old item red. Historical evidence is supposed to be old. Warn when an item is invalid for the selected temporal frame, when a correction exists, when a source could not be read at the cut-off, or when the effective interval is ambiguous. Let authorised users switch between “as decided” and “current evidence” views without merging them.

Test temporal behaviour with adversarial timelines

A conventional golden set gives one query and one expected answer. Temporal evaluation needs a sequence of events and expected states at several cut-offs. The same question should produce different, controlled answers as corrections and effective dates pass.

Create fixtures for late arrival, retroactive correction, future-effective policy, partial amendment, suspension, clock skew, duplicate event, missing end time, date-only effectiveness, snapshot expiry and source outage. Run the agent at each boundary. Verify the selected versions, proposition states and wording.

Do not score only final wording. Measure temporal version accuracy, supersession resolution, historical-knowledge preservation, current-truth correction, contradiction handling and unsupported precision. Inspect whether citations point to the exact version used.

Operational metrics need temporal denominators

Freshness dashboards often show average data age. An average hides the one source class that must be live. Measure by proposition, decision type and consequence.

Set service objectives according to source and decision. A sanctions-list projection may have a strict propagation target. A policy registry may require complete supersession closure before a version becomes effective. A historical research corpus can tolerate longer ingestion lag but must preserve correction status.

Report age, lag and validity separately. A source retrieved one second ago can carry a fact valid last year; an old policy can still govern today.

Model assertions, not mutable documents

Document versioning is necessary but too coarse for many decisions. One procedure can contain fifty clauses with different amendment histories. One registry response can assert several facts with different valid intervals. One customer email can include a current address and a forecast that never becomes true. Treating the entire object as one fact makes temporal selection brittle.

The normalisation layer should emit assertions. Each assertion has a subject, predicate, value or object, evidence reference, authority class, temporal envelope and status. It can point back to exact offsets in the immutable source version. Assertions do not become “true” because they were extracted. They are claims attributed to a source and evaluated under an evidence contract.

An extraction run may be probabilistic. The asserted source text, offsets, parser version and confidence are therefore retained. High-consequence fields can require deterministic extraction, a source API or human confirmation. If a later parser extracts a different date from the same PDF, the difference is a transformation correction, not a source correction.

The graph should permit disagreement. A customer record can say one address, a registry another and a returned-payment message a third. Current-state materialisation may choose a preferred operational value under policy, but the evidence layer retains all admitted assertions. A temporal query can then ask which claims were available, which were valid for the period and which authority resolved the conflict.

Typed assertions also improve invalidation. A correction to paragraph 4 need not invalidate embeddings and summaries derived only from paragraph 9 if dependency offsets are precise. Conversely, a document-level dependency should be treated conservatively and invalidated when any material section changes.

Testable claims and falsification

This design makes six claims that a programme can test. A bitemporal store should reconstruct the evidence known at a historical decision without treating corrected facts as currently valid. A typed supersession graph should select the correct policy across effective-date and partial-amendment fixtures. Snapshot manifests should improve independent reperformance. Lineage-driven invalidation should reduce continued use of corrected source versions. Version preconditions should prevent actions against changed state. Two-ledger explanations should reduce temporal conflation in reviewer assessments.

Each claim has a failure condition. If reviewers cannot recover the original state because source history is absent, reconstruction fails. If the graph selects both predecessor and successor at a boundary, applicability fails. If manifests point to expired snapshots, replay fails. If an unregistered cache continues serving a corrected summary, invalidation fails. If an action service ignores the expected version, the race remains. If reviewers still read later evidence as proof of what was known earlier, the interface fails.

Do not claim improved compliance or reduced loss from architecture alone. Those outcomes require a defined baseline, controlled observation and enough cases. Report control coverage and limitations first.

The reference architecture

The temporal evidence system has four planes. Sources produce versioned events and artefacts. The temporal plane stores assertions, valid and system time, and supersession. The derivation plane creates projections, chunks, embeddings and summaries with lineage. The decision plane pins a frame, assembles evidence, records output and enforces action preconditions.

In Harbour’s case, the architecture can say why the hold occurred without preserving the possible match as current truth. It can apply procedure version 6 to the 10:04 event while recognising that version 7 became effective at 11:00. It can show the later correction and trigger impact review without rewriting the original decision event.

Freshness asks whether evidence is fit for this decision now. Supersession asks which version governs. Valid time asks when the proposition holds. System time asks what the institution knew. None can substitute for the others.

Define temporal answer types

The output schema should prevent a model from merging time frames. Give it distinct answer types: current_state, historical_cause, historical_reperformance, change_since, and counterfactual. Each type requires different evidence and wording.

A current_state answer selects assertions valid at the target time using knowledge available by the retrieval cut-off. A historical_cause answer reports evidence and control state available to the actor when the event occurred. A historical_reperformance answer applies the governing rule and authorised inputs as of that decision. A change_since answer compares two pinned frames. A counterfactual changes named assumptions while freezing the rest.

The schema validator checks that every material claim cites evidence admitted for the answer type. A later correction cannot support the statement “the workflow knew.” An old procedure cannot support a current recommendation. A counterfactual must not be phrased as an event that occurred.

This is safer than asking the model to “be clear about dates.” The output carries temporal roles that downstream interfaces and audit can inspect.

Reconcile current views with history

Materialised current views can drift from their event history through projector bugs, manual corrections or missed messages. Run reconciliation that independently rebuilds a sample of entities from the immutable log and compares it with the live view. Include boundary cases and recently corrected records.

The comparison should understand expected differences. A live view may intentionally omit expired values; the reconstructed state at now should match after applying the same rules. A source may have delivered a late event after the sampled cut-off; the system-time frame determines whether it belongs.

Where full rebuild is expensive, use partitioned reconciliation and source totals. Keep a deterministic set of temporal canaries whose expected state changes at scheduled boundaries. If a future-effective policy does not activate or an expired waiver remains current, the canary alerts before an analyst discovers it.

Reconciliation results need ownership and closure evidence. A mismatch is not resolved when a dashboard turns green after rerun; record whether data, ordering, time-zone logic or applicability caused it and add a regression case.

Make time-zone policy explicit

Banking events cross legal entities and market calendars. UTC is appropriate for storage and ordering, but business rules may depend on local civil time, holidays and daylight-saving changes. “Effective on 22 July” needs a governing location and convention.

RFC 9557 can encode a time-zone name alongside a timestamp, but the application must preserve the time-zone database version used to interpret historical local time. Rules can change. Do not recompute an old local instant using an unrecorded future zone database and assume equivalence.

Market dates and end-of-day controls may use business calendars rather than elapsed duration. A freshness contract saying “one business day” must name the calendar. A date-only policy activation should be expanded under an approved legal-entity convention, not the server region.

Test daylight-saving gaps and repeated local times even if the main bank region does not observe them; customers and sources may. Reject unqualified local timestamps at integration boundaries unless the source contract supplies a stable interpretation.

Temporal red-team scenarios

Temporal controls can be attacked without changing content. An adversary can replay an old signed record, delay a correction, move an effective date, reorder events or restore a superseded policy file at the same URL. Add these scenarios to security testing.

Signatures need freshness and sequence context. A valid signature proves who signed bytes, not that the version is current. The registry checks predecessor, effective state and revocation. Connectors reject sequence regression or route it to reconciliation. Indexers compare stable source versions rather than trusting modification dates.

Test a race where entitlement is revoked after evidence retrieval but before answer delivery. Test a policy suspension during a long agent task. Test an old answer-cache entry whose text remains accurate but whose source authority was withdrawn. Test a future-dated event injected to dominate “latest” sorting.

Detection uses version monotonicity, signed registry state, source heartbeat, lag alerts and cross-source reconciliation. Response follows the lineage impact process. Temporal red teaming belongs with ordinary injection and access tests because stale authority can be as consequential as forged content.

A decision ledger for implementation

Before build, record choices that otherwise become implicit code.

The ledger is reviewed by source owners, policy, records, privacy, security and operations. No single architecture team can decide every retention and authority question.

What good looks like in the harbour case

At 10:12, the relationship manager receives a two-part explanation. “As acted” states that the payment workflow applied a hold at 10:04:08 under procedure version 6 using the candidate result and source snapshot available at that instant. “Current evidence” states that an analyst cleared the candidate at 10:06 and the source issued a correction at 10:09. It does not call the customer a match.

The packet shows that version 7 was published earlier but did not become effective until 11:00. It links the exact v6 clause, payment event, screening observation, clearance and correction. The procedure, data and model versions are recorded. No later evidence is inserted into the historical-cause ledger.

If an authorised user proposes a release action, the action service checks the current payment and alert versions, current authority and effective procedure. If anything changed after the packet, it rejects the command and requests recompilation.

That result is neither a claim that every source was true nor that the hold was commercially optimal. It is a temporally honest account: what happened, what was known, what changed and what governs now.

Minimum temporal receipt

Even a small implementation should retain a minimum receipt. It names the decision and target time, knowledge cut-off, source versions, governing policy version, material assertion intervals, corrections known at assembly, transformation versions, unresolved lags and the authorised reviewer or workflow. Each item is a stable reference, not a copied data lake.

The receipt also records which temporal capabilities were unavailable. If an external source offers no historical read, say so. If a policy had only a date and the bank expanded it under a local convention, name the convention. If exact model replay is impossible, distinguish evidence reperformance from generative reproduction.

An assurance reviewer should be able to answer four questions from the receipt: what frame was requested, which versions were admitted, which later changes were excluded from the historical view, and which limitations could alter interpretation. If any answer requires the original analyst’s memory, the evidence trail is incomplete.

Temporal integrity is achieved through explicit frames, versioned assertions and honest limitations: not through a “last updated” badge.

The operating model should review temporal defects as a distinct category. A wrong value, wrong version and wrong time frame can produce the same sentence but require different remediation. Trend those causes separately. Give policy, source, platform and workflow owners named actions. Re-run the affected timeline fixtures after repair and retain the failed run beside the passing evidence. This turns a subtle temporal error into a controlled learning loop rather than another instruction added to the prompt.