The Fact Was True, But When? Time Semantics for AI Systems

At 10:04, a procurement agent reads that a supplier is approved; at 10:07, it releases an order. A 10:12 correction says approval expired at midnight. Which audit statement is true: “approved,” “believed approved,” or “valid when ordered”?

Those claims are not equivalent. The first concerns the world, the second the system's knowledge, and the third a policy evaluated at a decision boundary. A single created_at column cannot distinguish them. Neither can a “recent” vector result or a prompt containing today's date.

The reader decision is concrete: should evidence be admitted when the system cannot state both when the fact was valid and what the decision snapshot could legitimately know? For consequential work, the safe answer is no. Preserve it for repair or use a declared fallback; do not promote an ambiguous timestamp into current truth.

Temporal truth is an operating contract, not a date format

A timestamp answers only the question named by its field. “2026-08-13T06:34:00Z” may describe when an event occurred, when a collector saw it, when a row was written, or when a decision ran. Those meanings produce different results when messages arrive late, clocks disagree, facts are corrected, or a historical decision is replayed.

RFC 3339 gives Internet applications a precise timestamp profile, including offsets and fractional seconds. It is essential syntax, but it does not define business semantics. Converting every timestamp to UTC improves comparison; it does not tell us what happened at that instant.

This distinction extends the enterprise-memory guide: retention decides what a system may remember, while time semantics decide which remembered version may answer a particular question. It also complements knowledge-graph reasoning, where provenance and valid intervals must travel with a relationship if an agent is expected to reason across change.

ZharfAI's rule is simple: every time-bearing field needs a name, owner, clock source, precision, and correction policy. If teams use timestamp differently, rename it before adding another model.

Six clocks that must not collapse into one

Most AI applications need at least the following distinctions. The exact schema may vary, but the questions must remain answerable.

Time field	Question it answers	Typical authority	Common trap
Valid or event time	When was the fact true, or when did the event occur, in the source domain?	Source system or domain owner	Substituting arrival time when the source is late
Observed time	When did this collector first observe the event?	Collector clock	Calling it event time because it is easy to capture
Recorded or ingested time	When did this store durably accept the version?	Storage service	Overwriting it during reprocessing
Snapshot or read time	Which committed versions were visible to this read?	Database or retrieval coordinator	Assuming all downstream stores share the same snapshot
Decision time	When did policy and model commit to a proposed outcome?	Decision service	Using task start or prompt-render time instead
Action time	When did the effect target accept or execute the action?	Target system	Treating model output as proof of execution

These fields form a causal chain, not six mandatory columns. A policy document may need a validity interval, record time, snapshot ID, decision time, and action receipt; a static specification may need only a version and retrieval record. The test is whether an investigator can separate what was true, what was knowable, what was decided, and what happened.

OpenTelemetry makes one useful distinction explicit. Its Logs Data Model defines Timestamp as the time an event occurred at its origin and ObservedTimestamp as the time the collection system observed it. When the original time is absent, the observation can still be preserved honestly instead of being relabelled as the event.

What established systems guarantee—and what they do not

The W3C PROV data model separates entities, activities, agents, generation, usage, and invalidation. Provenance shows which version supported a decision; it does not prove that version accurately described the world.

Apache Beam's programming guide separates event time from processing time. Watermarks estimate input completeness; triggers and allowed lateness trade latency, completeness, and cost. A watermark is progress, not proof that later evidence cannot exist.

The PostgreSQL transaction-isolation documentation says Read Committed queries see a snapshot as of each command, so successive queries can differ. Repeatable Read fixes a transaction snapshot; Serializable adds anomaly protection but may require a full retry. These modes govern database-version visibility, not upstream factual completeness.

Google Spanner's TrueTime and external-consistency documentation describes global commit ordering and multi-version snapshot reads. It answers “which committed database state did I read?”—not “when was this supplier approved?” unless the application models domain time.

These are verified properties of the cited systems. The architecture below is ZharfAI analysis: a way to compose those properties into an honest decision surface for AI products.

Put a time envelope around every consequential fact

Do not let retrieved text travel alone. Normalize evidence into a time envelope before it enters ranking, prompting, rules, or tool arguments.

Field	Purpose
`fact_id` and `version_id`	Stable identity for the claim and this recorded version
`valid_from`, `valid_to`	Source-domain interval in which the claim is asserted to hold
`observed_at`	First observation by this collection path
`recorded_at`	Durable acceptance time for this immutable version
`source_id` and `source_revision`	Authority and source-side version, not merely a URL
`snapshot_id` and `snapshot_at`	Evidence set presented to the decision
`precision` and `timezone_basis`	Minute, day, month, unknown; UTC, declared zone, or source local time
`correction_of` and `superseded_by`	Explicit relationship between versions
`provenance_ref`	Ingestion, transformation, and validation evidence
`temporal_status`	Current, future, expired, late, corrected, conflicting, or unknown

Use half-open validity intervals—[valid_from, valid_to)—unless the domain has a stronger convention. They avoid double-counting the boundary shared by two versions. Preserve the original source string and timezone alongside the normalized instant when legal or operational interpretation may depend on local time.

Unknown precision is data, not permission to invent it. “Effective August 2026” must not become midnight on August 1 without a domain rule. Missing valid_to can mean open-ended, not eternal. A source without domain time must carry that limitation rather than borrow recorded_at.

Store corrections as new knowledge, not rewritten history

For mutable facts, a bitemporal pattern is often the clearest model. One interval describes when a version was valid in the source domain; another describes when the system recorded that version. The first supports “what was true on August 10?” The second supports “what did we know at 10:04 on August 13?”

Suppose version A says approval was valid from August 1 onward and was recorded August 2. On August 13, version B arrives saying the approval ended August 12. Do not edit version A until it looks as if the system always knew the expiry. Close A's recorded interval, append B, and link B as a correction. Then both queries remain answerable:

Current best view: approval was valid from August 1 through August 12.
Historical knowledge view: at 10:04 on August 13, the decision system had only version A.

That separation supports audit evidence and assurance. An audit package should reproduce the evidence available to the decision, while a present-day review should also show corrections received later. Hiding either produces a misleading history.

Append-only storage still needs rules for overlapping intervals, duplicate revisions, retractions, authority precedence, and disputed facts. If policy cannot resolve a conflict, expose it; do not let retrieval score select reality.

Define the decision snapshot before retrieval begins

A decision snapshot is the bounded evidence universe a decision is allowed to use. Give it an immutable ID and create it before final ranking or prompt assembly. At minimum, record:

decision purpose, subject, and policy version;
snapshot_at and the storage/read consistency used;
source cutoffs, watermark or freshness bounds, and permitted staleness;
exact fact-version IDs and document digests admitted;
exclusions, conflicts, unknown time fields, and fallback taken;
model, retrieval, tool, and release versions;
proposed decision time and downstream action receipt.

A database snapshot covers only its participating database. If a prompt mixes PostgreSQL, a search index, cached APIs, and a vector store, “transactional read” is not a cross-store guarantee. Materialize immutable version IDs, enforce a shared cutoff, or declare the inconsistency window.

This is where the release-passport pattern becomes useful: the running assembly and the evidence snapshot are two sides of reproducibility. One tells us which software could decide; the other tells us which facts it was allowed to see.

Treat late data as a policy event

Late evidence is normal: networks partition, humans backdate records, and sources correct facts after action. The danger is silently merging it into “current” results without asking what happens to completed decisions.

For each decision class, define a correction matrix:

Late-evidence condition	Default response	Why
Arrives before decision commit and within allowed lateness	Rebuild snapshot and reevaluate	Decision has not crossed the commitment boundary
Arrives after proposal but before human approval	Mark proposal stale; require refreshed evidence	Approval must bind to a known snapshot
Arrives after a reversible action	Reevaluate and create a compensating proposal	Preserve history; do not erase the original action
Arrives after an irreversible action	Escalate with impact evidence	Automatic replay may deepen harm
Corrects a non-material field	Record and close review with policy reason	Avoid needless operational churn
Source authority or event time is unknown	Quarantine or use a declared conservative fallback	Recency cannot be inferred honestly

Materiality must be domain-owned. A changed postal code may be immaterial to a credit decision but material to delivery. A one-minute clock difference may be irrelevant to a monthly report but decisive in market, access, or incident systems. Models can summarize the difference; policy must decide whether it requires reconsideration.

Worked example: release a purchase order or pause it

Consider a purchase-order agent with four evidence streams: supplier approval, sanctions screening, budget availability, and a contract price. The agent may release an order only when all four are valid at the policy's evaluation time.

At 10:00, the coordinator creates snapshot S-184 with a 09:59:59Z cutoff. Supplier approval version 17 is open-ended, screening is valid for 24 hours, budget version 42 reserves enough funds, and contract version 8 covers the item. The prompt receives summaries and version IDs—not whatever ranks highest two minutes later.

At 10:03, the model proposes release. A deterministic guard rechecks eligibility and versions, then stores the proposal digest, S-184, policy version, and decision time. At 10:05, the target accepts the order and returns a receipt.

At 10:12, approval version 18 says approval expired at 00:00 and corrects version 17. The monitor joins it to decisions using 17 and marks the order “requires review.” It does not rewrite S-184 or pretend version 18 was available. Policy sees a material change after a reversible action and creates a hold/cancellation proposal for an authorized reviewer.

The evidence now says precisely: the source asserts the supplier was not approved; the system did not know that at S-184; and the accepted action is under remediation. That is more useful than “AI error” or “correct decision.”

Keep temporal eligibility outside semantic ranking

Vector similarity and model attention are not validity controls. An expired policy may outrank a current one. Filter by temporal and authority rules before semantic ranking, then carry eligibility into the final guard.

A robust retrieval order is:

resolve subject and decision purpose;
select permitted source authorities;
apply valid-time, record-time, and snapshot cutoffs;
remove superseded or conflicting versions according to policy;
rank the remaining evidence semantically;
build a manifest of admitted versions;
revalidate that manifest before committing an action.

The data-quality observability guide explains why freshness and lineage need measurable contracts. Add temporal eligibility to that contract. “Index updated recently” is not enough if the newest record describes an event from last month or corrects a decision made this morning.

Measure the uncertainty your timestamps create

Monitor the distances and exceptions that reveal temporal risk, not just pipeline uptime.

Measure	Interpretation
Event-to-observation lag	Source or network delay
Observation-to-record lag	Collector and ingestion delay
Record-to-index lag	Search-surface staleness
Snapshot-to-decision duration	Exposure to change during reasoning
Decision-to-action duration	Risk that preconditions age before effect
Unknown-time rate	Evidence whose validity cannot be evaluated
Overlapping-validity rate	Conflicting or malformed domain intervals
Late-correction rate	Versions that change completed decision evidence
Reconsideration rate and age	Operational cost and responsiveness after correction
Replay divergence	Difference between original snapshot and current-best evaluation

Segment measures by source, decision class, risk tier, and timezone path. Global averages hide sources that backfill material facts. Thresholds should reflect the reversal window, not generic freshness.

Use two replay modes. Historical replay uses only versions recorded by the original snapshot and tests reproducibility. Current-best replay applies corrections known now and tests whether an outcome deserves reconsideration. Mixing them creates hindsight.

Failure modes to reject in design review

Failure	Required correction
One timestamp called `date`	Name its semantics and retain the raw value
Latest row wins	Query by valid interval and knowledge cutoff
In-place correction	Append a linked version and preserve historical knowledge
Database isolation treated as truth	Record the upstream time contract
“Use current data” in a prompt	Enforce eligibility before and after inference
Watermark treated as certainty	Keep lateness and reconsideration policy separate
Automatic replay after correction	Create a guarded compensating proposal
Millisecond precision without source support	Store declared precision and uncertainty

A temporal-truth review checklist

Before allowing an AI workflow to make or execute a consequential decision, verify:

every time field has one documented meaning, source clock, timezone rule, and precision;
domain validity is separate from observation and storage time where facts can arrive late;
corrections append new versions and link to what they supersede;
the decision snapshot has an immutable ID and exact evidence-version manifest;
cross-store reads have a common cutoff or a documented inconsistency bound;
temporal eligibility runs before ranking and again before action;
approvals bind to the snapshot and operation digest they reviewed;
late evidence enters a materiality and reversibility policy;
action receipts distinguish a proposal from an accepted real-world effect;
historical replay and current-best replay are separate modes;
lag, unknown-time, overlap, correction, and reconsideration measures have owners;
ambiguity fails to a visible state rather than a plausible timestamp invented by a model.

What to monitor and when to revisit the contract

Revisit the design when a source is added, consistency changes, a decision becomes less reversible, the lateness window moves, or replay divergence rises—and after timezone changes, clock incidents, migrations, or bulk corrections.

The goal is not a perfectly synchronized world. That does not exist. The goal is an evidence system that can say, without hindsight: this was the best version we were entitled to use at this snapshot; this was the policy and software that interpreted it; this was the action actually accepted; and this is what later evidence changed. When those statements are first-class, AI can operate over changing facts without pretending that knowledge and reality move in lockstep.

Source notes — reviewed August 13, 2026

RFC 3339: Date and Time on the Internet — verified timestamp syntax, offsets, and normalization boundaries.
W3C PROV-DM — verified provenance concepts for generation, usage, invalidation, entities, activities, and agents.
OpenTelemetry Logs Data Model — verified the distinction between origin event time and observation time.
Apache Beam programming guide — verified event time, processing time, watermarks, triggers, and late-data behavior.
PostgreSQL transaction isolation — verified statement and transaction snapshot behavior and Serializable retry requirements.
Google Spanner: TrueTime and external consistency — verified commit ordering and multi-version snapshot-read properties.