An AI system can quote a real policy, retrieve a real account state and calculate from real events, yet still be wrong because those facts belong to different moments. “Current” is not a property of a database row. It is a question about when a fact applies, when the organisation learned it and when a decision used it.
The reader decision is: which facts may be frozen with an AI proposal, which must be reconstructed as they were at a requested time, and which must be checked again immediately before an action commits? A team that cannot answer those three questions has a temporal correctness problem, even if its model evaluation looks excellent.
This field guide turns time into an explicit data and control contract. It separates business validity from system knowledge, prevents future information from leaking into training and replay, gives late events a declared treatment, and makes approval delays safe. The goal is not to build a temporal database for every chatbot. It is to apply the minimum time discipline required by the consequence of being wrong.
One fact can have three different clocks
AIEngine recommends distinguishing three clocks in the operating model. These labels are a practical synthesis rather than a claim that every source system uses the same terminology.
| Clock | Question it answers | Example | Failure when omitted |
|---|---|---|---|
| Valid time | When was the fact true or applicable in the business world? | A price applies from Monday until Friday | The system applies a future or expired rule |
| Recorded time | When did the organisation receive and store that version? | Friday's correction was entered on Tuesday | A replay gives the model knowledge it did not yet have |
| Use time | When did a model, reviewer or destination rely on it? | A payment proposal was created at 10:02 and committed at 10:19 | A safe draft becomes an unsafe delayed action |
The W3C Time Ontology provides a vocabulary for instants, intervals, durations and relations such as before, after and overlap. The W3C PROV data model separately models when an entity was generated, used or invalidated. Together they support an important design principle: the time a rule applies and the time a system used a particular revision are different facts.
Do not collapse these clocks into updated_at. That field might mean source modification, ingestion, correction, replication or last write. It cannot answer both “what was true on 1 June?” and “what did the service know on 1 June?” after a backdated correction arrives in July.
Write a temporal contract before changing the prompt
Classify every material input to the AI workflow. A useful contract records:
| Field | Purpose |
|---|---|
| Stable entity and fact key | Joins revisions without treating a new row as a new thing |
| Value and source revision | Identifies exactly what the system saw |
| valid_from and valid_to | Defines the business interval in which the fact applies |
| recorded_at | Establishes when this system could first have known it |
| superseded_at | Preserves when a recorded version stopped being the accepted version |
| observed_at and expected delay | Separates occurrence from sensor, feed or human reporting lag |
| Time zone and precision | Prevents a date, local time and UTC instant being treated as equivalent |
| Owner and correction reason | Makes disputes and backdated changes accountable |
Use explicit intervals and choose one boundary convention. Half-open intervals—start inclusive, end exclusive—let one version end at the exact instant its successor begins without an artificial overlap. Store unambiguous machine timestamps; RFC 3339 defines an Internet timestamp profile with explicit UTC relationships and numeric offsets. Retain the business time zone when local dates, trading days or daylight-saving rules carry meaning rather than converting everything into a context-free UTC string.
The prompt should receive resolved facts and their temporal scope, not a bag of dates it must interpret. The same discipline that keeps a context window as a controlled working set also applies to time: include the revisions valid for the task and expose any unresolved gap or conflict.
Preserve revisions instead of overwriting history
When a supplier changes a delivery window or an organisation corrects a customer status, keep the prior recorded version. A business change and a correction are not the same event. The first says reality changed; the second says an earlier record of reality was wrong or incomplete. Both require an audit trail.
Enforce rules below the model. For an exclusive state, two versions of the same fact must not claim overlapping valid intervals. PostgreSQL 18 documents temporal keys using WITHOUT OVERLAPS and PERIOD, including coverage of a referencing record for its full duration. A different database may use range exclusion, system-versioned tables or application checks; the invariant matters more than the product syntax.
A minimal current-state table is not necessarily enough. If the workflow must answer “what did we believe at 09:00, based on information recorded by then?”, retain recorded-time history as well as business-valid intervals. Append the correction, close the superseded recorded interval and link the new revision to its predecessor. Apply the release controls in the AI model change-control guide to temporal schema and resolution logic too: a change to interval boundaries can alter decisions without changing the model.
Keep future facts out of training and replay
Ordinary joins often leak the future. Suppose a fraud label was assigned two weeks after a transaction. Joining each transaction to the customer's latest profile can give the training row a risk flag, address or account state that was unavailable when the prediction would have occurred. Offline accuracy rises while the production model never receives the same information.
Build each example with a point-in-time join: for every prediction timestamp, select only feature versions available by that cutoff. Amazon SageMaker Feature Store's official dataset tooling includes as-of retrieval and point-in-time accurate joins. That feature does not prove a dataset is leakage-free. The event timestamp itself may be backfilled, corrected or delivered late, so the availability cutoff should use the recorded time that matches the production path.
Apply the same rule to evaluation and incident reconstruction. A replay must freeze the prompt, model and tool versions, but it must also reconstruct the source revisions and identity state available then. Our privacy-safe incident replay guide explains how to keep that evidence proportionate. If a replay silently uses today's corrected record, it answers whether the current system can solve an old case—not whether the original decision was reasonable from the evidence then available.
Make late events a declared business policy
Feeds do not arrive in perfect order. A warehouse scan can be delayed offline, a bank event can be posted after reconciliation, and a human correction can be backdated. The system must choose how long to wait, what counts as late and whether a late event corrects a result, triggers review or is retained only for history.
Apache Flink's event-time and watermark documentation shows the engineering mechanism: event timestamps describe occurrence, while watermarks express progress and an assumption about how much out-of-order data to expect. AIEngine's operational interpretation is that every time-sensitive workflow needs the equivalent policy, even without a streaming framework.
Declare four things per input: expected delay, maximum tolerated lateness, provisional-output behaviour and correction path. A short watermark favours speed but accepts more later corrections. A long wait improves completeness while making the service less timely. There is no model setting that removes this tradeoff.
Never let a late event silently rewrite a completed external action. It may update an analytical result or open a reconciliation item, but money sent, access granted or a customer message delivered needs an explicit recovery process. Temporal correction and transaction compensation solve different problems.
Revalidate volatile facts at the commit boundary
An AI proposal and an executed action are two separate decisions. Approval queues, retries and tool latency create a gap in which permissions, balances, inventory, prices or case status can change.
| Fact class | Safe treatment | Examples |
|---|---|---|
| Immutable evidence | Snapshot and retain its digest | Signed order line, received document revision |
| Schedule-bound rule | Resolve against the decision's valid time | Tax table, service policy, contracted rate |
| Volatile operational state | Re-read immediately before commit | Available balance, stock, account hold, user authority |
| Derived AI output | Expire or regenerate when a dependency changes | Recommendation, route, action arguments |
Attach a dependency manifest and expiry to the proposal. At commit, compare the current revisions of volatile dependencies, rerun deterministic constraints and reject a stale proposal rather than asking the model whether the change “looks material”. The related AI cache safety framework makes the same separation for reused computation: equivalence, freshness and permission are independent.
For high-consequence actions, use optimistic concurrency or a destination-side precondition so the check and write cannot drift apart. A reviewer approving a screen is not proof that the underlying state remained unchanged after the screen loaded.
Work through a delayed refund
Consider an illustrative refund assistant, not a claimed deployment. At 10:02 it proposes a £180 refund using order revision 7, policy revision 12 and an account state recorded at 09:59. A reviewer opens the proposal at 10:14. Meanwhile, at 10:08, the fraud team records a hold that is valid from 09:55 because the underlying event arrived late.
The system now needs two defensible answers:
- Why did the assistant propose the refund? Reconstruct the knowledge available at 10:02. The hold was not yet recorded, so it should not appear in that explanation.
- May the refund commit now? Re-read volatile account state at 10:14. The backdated hold is currently known and blocks the action, even though the original proposal was reasonable from its snapshot.
Store the proposal's source revisions, valid-time query, recorded-time cutoff and generation time. At approval, record the revalidation result and destination precondition. Route the conflict rather than rewriting the original trace. This preserves both accountability and present safety.
Test boundaries, corrections and delayed approvals
A temporal test set should include more than “fresh versus stale”. Exercise:
- exact interval boundaries and adjacent versions;
- overlapping or missing validity periods;
- backdated corrections recorded after the event;
- events arriving beyond the declared lateness budget;
- local dates across daylight-saving changes;
- training joins that attempt to use future records;
- a permission or balance change during human review;
- retry and replay against the original knowledge cutoff; and
- deletion, retention and legal-hold rules across historical versions.
Measure temporal provenance coverage, overlap rejection, late-arrival rate by source, point-in-time join violations, stale proposals rejected at commit, correction time, replay completeness and actions executed from superseded state. Slice by workflow and consequence; one aggregate freshness average can hide the feed that controls the riskiest action.
The NIST AI Risk Management Framework Core calls for ongoing monitoring, safe operation within knowledge limits, change management and documented incident response. Temporal limits belong in that operating evidence. Record the threshold that pauses a workflow when source delay, unresolved overlap or commit-time conflicts exceed tolerance.
The release gate
Before a time-sensitive AI workflow goes live, require evidence that:
- each material fact has an owner, valid-time meaning and availability timestamp;
- interval boundaries and time zones are explicit;
- history survives corrections instead of being overwritten;
- training and evaluation use production-faithful point-in-time joins;
- late events follow a tested correction or reconciliation path;
- volatile state is revalidated immediately before consequential writes;
- every action trace names the revisions and cutoff it used; and
- monitors can detect overlap, lag, leakage and stale execution.
Temporal correctness is not about putting more timestamps in a log. It is the ability to say what was true, what was known and what was used—then to stop an old proposal from acting as if nothing changed.
