The strong rivalCurrent-state simplicity is often enough

A low-consequence public inventory question may need only the authoritative present snapshot and a short expiry. If a correction cannot materially change a decision, no dispute needs historical reconstruction and no affected party needs an explanation, storing every version adds query complexity, privacy exposure and operational burden without proportional value. A current-state store plus a bounded audit log is the stronger design.

The boundary changes when a past decision must be explained, a rule takes effect in the future, events arrive out of order, corrections are retroactive, permissions can be revoked, or obsolete context can cause consequential action. In those cases, overwriting the row erases evidence. “Latest wins” also mistakes recency for authority when two controlled sources disagree.

Temporal mechanisms are implementation choices. Event sourcing preserves changes as events; bitemporal tables model valid and recorded intervals; slowly changing dimensions retain analytical history; change-data capture transports mutations; temporal graphs qualify evolving relations. None alone establishes source authority, access, conflict rules, refresh thresholds or replay obligations.

Use the least elaborate design that can answer the decision’s real questions. If those questions include what was valid then, what was recorded then, what the authorised process could know then and what changed later, one present-state value is not enough.

Original constructThe seven-clock Temporal Truth Record

Each material fact carries a stable identifier, source and owner; value and unit; timezone or calendar rule; seven clock values; valid and recorded intervals; current, historical, scheduled or contested status; correction links; confidence or dispute; policy and entitlement versions; and dependencies on downstream artefacts. Missing clocks remain explicitly unknown rather than borrowing another timestamp.

Two mandatory questions: valid-time history asks what was true for the target interval; recorded and availability history ask what the organisation stored and could use by the knowledge cutoff. A defensible reconstruction often needs both.

A policy may be recorded today, scheduled to become valid next month and available immediately to a transition-planning service. That does not permit a production decision to apply it early. A transaction may occur Friday, be observed at the terminal Friday, be recorded Saturday and become available to the fraud service after Sunday’s index refresh. The record preserves the lag instead of rewriting Friday as Sunday.

Four visible statesDo not flatten uncertainty into one current row

Transitions are evidence-bearing. A scheduled policy becomes current at its declared effective time, not at publication or ingestion. A current fact becomes historical when its valid interval closes. A correction may supersede a version while retaining its recorded interval. Contested evidence becomes current only through a named authority or adjudication route, not because one write arrived last.

Source authority can depend on fact class and time. A civil registry may govern legal status while an operational system governs immediate fulfilment state. Conflict policy names which source controls which claim, when human verification is required and which decisions must abstain meanwhile. Recency remains one signal, never a universal trump card.

Out-of-order realityWatermarks express patience, not truth

Streaming systems separate event time from processing or arrival time because networks, devices and organisations deliver events out of order. A watermark estimates how far event-time processing has progressed. Allowed lateness determines how long a window remains revisable. Triggers determine when provisional and updated results appear. These mechanisms manage computation; they do not decide the business consequence of a late record.

If a payment occurred before a regulatory cutoff but arrived after a window closed, record both clocks. Reopen or correct the aggregate according to policy. Then identify decisions that used the incomplete window. A dashboard might simply refresh, a customer charge might require reversal, and an irreversible control action might require independent investigation. Dropping the event because state was compacted is an operational choice that must be reconciled with the decision obligation.

Duplicate and missing-event rules matter as much as lateness. Stable event identifiers and idempotent processing prevent a replay from double-counting. Sequence gaps can trigger bounded waiting, fallback lookup or abstention. Arrival order cannot substitute for causal or business order. Where the source cannot supply reliable event time, the record states that limitation and avoids precise historical claims.

Timezone rules belong to the fact contract. “Midnight” must name a zone, calendar and treatment of daylight-saving transitions or local exceptions. Store an interoperable instant with its offset where appropriate, but preserve the business zone used to interpret a local deadline. Converting everything to UTC does not remove the need to know which local rule created the boundary.

Freshness is a business toleranceThe staleness consequence ledger

A five-minute refresh interval says nothing about whether a fact is safe to reuse for five minutes. For each fact class, record its owner, change process and observed volatility; the consuming decision; maximum tolerable age or event lag; probability of change during reuse; consequence of obsolete use; detection and invalidation route; fallback; dependencies; and replay or remediation duty.

Maximum age and event lag are different. A static reference table may be recorded months ago yet remain current because its owner confirms no effective change. A sensor value recorded seconds ago may already be obsolete for a real-time control. Recency is evidence only when connected to the fact’s change process, source authority and validity interval.

Estimate staleness loss as a decision-specific exposure, not a universal score. The relevant components are the chance that the fact changed undetected during reuse, the conditional consequence of acting on the obsolete version, the time until detection, and the reversibility of the action. Use ranges and scenario classes when probabilities are weak. A non-compensable legal-status or safety gate should not be averaged away by cheap refreshes elsewhere.

Refresh cost includes source load, network and compute expense, index churn, privacy exposure, model-context rebuilding and user latency. The ledger selects among push invalidation, pull-on-use verification, scheduled refresh, short expiry, authoritative fallback, human confirmation or abstention. It also states how the system proves that the action occurred.

Correction must travelDerived context can look fresh after its source changes

A source correction does not automatically repair its chunks, embeddings, graph edges, summaries, caches, conversation state, durable memory or prior decisions. Every derived artefact needs provenance to source identifiers and versions, a temporal status, a reuse expiry and an invalidation route. Combined outputs also need dependency links because a correction to one input may change an inference even when the displayed text does not quote it.

Propagation begins with the authoritative version event. The source closes the earlier recorded interval, links the new version through supersession and emits a change carrying safe identifiers and policy context. Index and feature pipelines locate affected artefacts, invalidate or recompute them, and confirm completion. Caches stop serving earlier receipts. Conversation and memory stores re-evaluate retention and use. Decision records test whether the correction crosses their replay threshold.

Content freshness and permission freshness remain separate. A document may be factually unchanged while yesterday’s entitlement is revoked. A corrected fact may be current but unavailable to a principal. Cache reuse therefore binds both the temporal context receipt and the entitlement receipt. Either source supersession or policy-version change can end reuse.

Best-effort invalidation is insufficient where stale context can cause material harm. Define maximum propagation lag by dependency and consequence, monitor unacknowledged invalidations, rehearse partial failure and provide a safe mode. That may mean authoritative lookup, a temporarily reduced capability, human verification or abstention until the dependency graph is consistent.

Worked reconstructionWhat was true and what was knowable are different findings

An automated service declined a transaction at 14:05 on 8 March. The audit asks whether the decision used the correct account status and policy. The query first fixes the target valid time at 14:05 and the knowledge cutoff at the service’s decision time. It does not begin from today’s account row or today’s policy.

The account event occurred at 13:42 and was observed by the branch at 13:47. A source system recorded the status at 13:55, but a permission fault prevented availability to the decision service until 14:18. The fact was valid before the decision yet not knowable through the authorised production route at 14:05. That distinction exposes an availability failure without falsely claiming that the service ignored evidence it could retrieve.

The governing policy was published on 1 March and scheduled for 1 April. The decision used the still-current February policy, which was correct for 8 March. Replaying the case with today’s default policy would manufacture a different historical rule. The policy history supplies effective and recorded intervals, while the entitlement history proves which version the service could access.

At 16:20 the source corrected the account status retroactively to 13:40. The correction closes the earlier recorded version and links the replacement without deleting the original. The temporal receipt identifies the late version, the versions excluded by the original knowledge cutoff and the affected decision. Because the decline was reversible but customer-impacting, the consequence ledger routes it to review and remediation rather than silently updating a dashboard.

This reconstruction produces two legitimate statements. The best current evidence says the account status was valid before 14:05. The operational record says that version was not available to the authorised decision service by 14:05, and the later correction was not yet recorded. Accountability can now address source latency, permission propagation and customer remedy separately. Without the clocks, “the database says the account was valid” collapses those findings and assigns causality to the wrong control.

Operating disciplineMake temporal truth observable from capture to remedy

Capture clocks at their authoritative boundary

Do not manufacture event time when an event reaches the warehouse. The producing workflow should supply the event identifier, its business occurrence time and the reference system used to interpret it. The receiving platform adds recorded time and preserves the supplied value. Observation time belongs to the sensor, reviewer or source process that made the claim. Availability time belongs to the authorised consumer path and can differ across tenants, indexes or policy partitions. Decision time is emitted by the service that formed the recommendation or action. Supersession is recorded when a replacement becomes active in the information system. Each clock therefore has an accountable producer.

Where a source cannot provide a clock, record an explicit absence and the best bounded proxy. A paper form may establish an observation date but not a precise event instant. A legacy batch may provide file creation and ingestion time without source ordering. Such limitations become part of the evidence gap and can change the route for consequential decisions. Filling every blank with recorded time creates apparent completeness while making a false claim about occurrence, validity and knowability.

Define interval and boundary semantics once

Teams must agree whether valid intervals are closed, open or half-open and how adjacent versions behave at the boundary. A common half-open convention includes the start and excludes the end, avoiding two versions being current at exactly the transition instant. The convention must be expressed in source contracts, query helpers and tests rather than left to each consumer. Scheduled policy, contractual periods, shifts and eligibility windows also need rules for holidays, leap seconds where relevant, local midnight and daylight-saving gaps or repeated local times.

A timestamp string is not sufficient when the business rule is calendar-relative. “The first working day of the month in the customer’s jurisdiction” needs the jurisdiction, holiday calendar and version of that calendar. Store the resolved instant used by the decision as well as the rule that produced it. When calendar data changes retroactively, the organisation can then decide whether the earlier interpretation remains the governing evidence or whether affected decisions require review.

Make the temporal query a typed request

Every consequential context request should state whether it asks for current state, true-at history, known-at history or a comparison across versions. It names the target interval, knowledge cutoff, permitted source set, timezone, conflict policy and completeness requirement. A helper API can expose safe forms such as current authoritative, true at T as known by K, changes between two cutoffs, and decisions affected by version V. It should reject a bare “latest” query for fact classes whose contract requires historical or contested-state handling.

The response distinguishes no current fact, no fact recorded by the cutoff, no authorised fact available by the cutoff and an unresolved conflict. Those absences have different causes and remedies. Collapsing them into null invites a model to treat missing access, late arrival and non-existence as equivalent. Typed absence also supports safe explanations that do not reveal protected versions to an unauthorised requester.

Assign freshness budgets to fact and decision pairs

A fact class may have several tolerances because its consumers face different consequences. A branch address used for a public directory may tolerate a daily snapshot, while the same branch’s emergency-closure status used for routing staff may require push invalidation and verification at use. The ledger therefore keys the budget by fact class, decision, operation and destination. It records maximum age, maximum event lag, source service level, fallback and the evidence that demonstrates compliance.

Measure the realised distribution, not just the configured interval. Useful observations include source-to-record lag, record-to-availability lag, time beyond the decision tolerance, invalidation acknowledgement lag, late-event rate, contested-state duration and decisions exposed before correction. Break them down by source, fact class and consequential route. An average of two seconds can hide a tail in which critical revocations take hours. Tail thresholds and non-compensable cases should be visible without converting the system into one temporal score.

Treat correction as a controlled change

A correction event names the version it supersedes, why the earlier claim changed, who or what authorised the change, the new valid interval and the recorded time. The platform appends rather than overwrites, then emits a dependency-safe notification. Consumers acknowledge invalidation or report a failure. The source owner can see whether the correction reached the index, derived features, graph, summaries, caches, conversation state and durable memory. A successful source update with unacknowledged downstream nodes remains an incomplete correction.

Conflicting corrections are not resolved by whichever message arrives last. The policy names source precedence for the fact class or routes the conflict to adjudication. Until then, both versions carry contested status and their provenance. Low-consequence uses may display the disagreement; high-consequence automation may abstain. Once resolved, the adjudication becomes a versioned activity that explains why one claim is current and how the alternative was retained or retired.

Replay according to consequence, not technical convenience

The dependency graph produces a candidate set of affected decisions, but impact policy determines the response. A recommendation that was never shown may need only a corrected record. A displayed but non-binding suggestion may require notice. A charge, benefit decision, safety intervention or external report may require human review, reversal, customer remedy or a new filing. Irreversibility, affected-party harm, elapsed time and legal obligations shape the route. Replaying everything can itself cause instability, while replaying nothing hides known error.

Replay must use controlled semantics. It can reconstruct the original decision under the original knowledge set, calculate the corrected decision under the new valid history and compare them. It should not casually mix the new fact with unrelated current policy or software unless the question explicitly asks for today’s outcome. Record model, code, policy, source and entitlement versions so that a difference can be attributed to the intended correction rather than an uncontrolled change elsewhere.

Keep temporal history inside privacy and access boundaries

Version history may preserve rectified, expired or highly sensitive values. Historical usefulness does not create unlimited retention or access. Define which versions must be retained, for which reconstruction or legal purpose, under which entitlement, and when they are deleted, minimised or placed in a restricted archive. A requester entitled to the current value may not be entitled to earlier values or to the fact that a dispute occurred.

Temporal receipts should therefore carry controlled identifiers and decision evidence rather than unnecessary payload. Deletion and rectification workflows trace dependencies while respecting duties to retain specific audit records where applicable. When a source value is removed, derived artefacts may need deletion or recomputation, while the audit record can preserve that a governed change occurred without preserving the value itself. The design balances explanation, correction and storage limitation rather than treating history as an indefinite warehouse.

Test the failure modes as temporal scenarios

Unit tests for timestamp parsing are necessary but insufficient. Run scenario tests in which a future rule is published early, a late event crosses a window, two authorities disagree, a daylight-saving boundary repeats an hour, a correction changes an earlier valid interval, an index misses invalidation, and an entitlement is revoked while content stays unchanged. Assert the route, selected versions, safe absence, expiry, dependency acknowledgements and replay decision. Also test the simple current-state case so temporal machinery does not block harmless work.

The operating test is whether the organisation can answer, for one consequential output, which facts and rules were valid, which were recorded and authorised for use, why later evidence was excluded, when the context expires, and what will happen if a source changes. If any answer depends on reading the newest row by hand, the temporal contract is not yet implemented.

Decision evidenceThe temporal context receipt

The receipt records the current-state or historical intent; target as-of time; known-at cutoff; source, policy and entitlement versions considered; valid and recorded intervals; timezone and calendar basis; excluded late evidence; conflicts; freshness decision; transformations; dependencies; expiry; invalidation acknowledgements; and replay trigger. It is a compact explanation of temporal selection, not a copy of every source row.

For a present-state answer, the receipt names the authoritative snapshot and maximum reuse age. For reconstruction, it states both the valid-time and recorded or available-time predicates. For contested evidence, it preserves competing version identifiers and the authority gap. For refresh, it names the stale dependency. For replay, it links prior decisions and required remediation without exposing information outside their entitlement.

Receipts make temporal claims testable. An auditor can reproduce the version set under the same query semantics. Operations can locate caches and memory tied to a superseded source. Product teams can measure how often late or contested facts change outcomes. Retain the receipt under its own privacy and access purpose, particularly where version history contains rectified or expired personal data.

Interactive instrumentTemporal Context Resolver

Set the query intent, consequence, clock quality, source state and dependency condition. The Resolver returns one of five operational routes with the clock basis, evidence gap, expiry and downstream action. It does not average the inputs into a freshness or maturity score.

Exactly five outcomesChoose a temporal action, not a freshness score

Use the current authoritative state with bounded expiry

Use this route for a present decision when the source is authoritative, the fact is current, its age and event lag are inside the consequence-specific contract, timezone semantics are declared and no material dependency or entitlement is stale. The receipt makes reuse finite.

Reconstruct decision-time truth from valid and recorded history

Use this route for audit, appeal, replay analysis or any historical question. Query what was valid at the target time and what was recorded and available by the decision cutoff. Preserve later corrections as later knowledge rather than silently inserting them into the original context.

Preserve competing versions and ask or escalate

Use this route when authoritative sources conflict, a material clock or timezone is ambiguous, a scheduled fact is being applied prematurely, or correction remains pending. Retain both claims and name the missing authority or adjudication step.

Refresh or reindex before making the decision

Use this route when the source may be valid but the accessible snapshot, embedding, graph, summary, cache or memory is outside its tolerance or bound to a revoked entitlement. Repair the context path before consequential use.

Invalidate and replay affected downstream decisions

Use this route when late evidence, retroactive correction, revocation or stale derivation crosses the recorded impact threshold. Stop reuse, trace dependencies and review, reverse, recompute or remediate affected decisions according to consequence.

Negative controlsTen cases that prevent temporal shortcuts

Evidence boundaryRepresentations, operational controls and applicable duties

Temporal database research supports valid time, transaction time and historical queries. SQL standards provide system-versioned and application-time periods. W3C and IETF records support explicit instants, intervals, reference systems and interoperable timestamp forms. Streaming research supplies event-time, watermarks and late-data mechanisms. These are technical foundations for the Temporal Truth Record, not evidence that every system needs the full design.

Provenance explains which entity, activity or agent generated, derived or invalidated a version. It does not decide whether the claim was valid in the represented world. Fresh retrieval research shows the importance of time-sensitive sources but does not turn search recency into authority. Temporal graph methods represent evolving relations but are optional when tables or event logs are adequate.

Data-quality, AI-risk and production-ML sources support lifecycle governance, monitoring and dependency control. The GDPR’s accuracy, rectification, storage limitation and security requirements apply within the relevant processing, lawful basis, role and jurisdiction. EU AI Act data governance, logging, monitoring, record-keeping and corrective duties depend on the system classification, actor, provision and applicable timeline. Neither instrument prescribes this seven-clock record.

This article’s seven-clock record, four statuses, staleness consequence ledger, receipt and Resolver are an operating synthesis. Organisations must map them to their own source authorities, contracts, legal obligations, retention limits and decision consequences.