World Time, Reasoning Time, and Action Time
Why AI systems need to distinguish between when something happened, when the model learned about it, and when the action shipped
The Conventional Framing
When AI systems get something wrong because their context is stale, the issue gets framed as "data freshness." Reindex more often. Shrink the cache TTL. Pull from the system of record instead of the snapshot.
That framing treats time as a quality problem. As long as the data isn't too old, the answer will be good enough.
Why Freshness Is The Wrong Frame
In 2018-era event-driven systems there were two dates that mattered: the actual event date and the processed date. If the late bus arrived after the principal counted heads, her count was wrong unless the architecture handled reconciliation.
AI systems have more clocks. There is world time (when something actually happened), ingestion time (when the source system learned about it), retrieval time (when the AI system pulled it into context), reasoning time (when the model produced an answer or selected an action), and action time (when a tool actually changed something).
A scenario:
A sales rep asks an AI assistant about a customer's contract status at 2:42pm. The model retrieves the customer record from a vector store last reindexed at 2:00pm. At 2:31pm, the contract was amended — a new clause was added by legal. The reindex hasn't run yet. The model reads the pre-amendment version, summarizes it confidently, and recommends the rep send a renewal email with terms that are no longer accurate. The rep, trusting the assistant, ships the email at 2:43pm.
World time of the amendment: 2:31pm. Retrieval time: 2:42pm against a 2:00pm snapshot. Reasoning time: 2:42pm. Action time: 2:43pm. The model reasoned correctly given the context it had. The context was forty-two minutes stale. The action shipped anyway.
The architectural question has changed.
The old question was: did the event arrive late? The new one is: did the model reason from the right version of reality, and does the system know when it didn't?
"Freshness" underplays the problem because it treats this as a quality issue. It's actually a correctness and accountability issue. An action that was right at reasoning time and wrong at action time still happened. The customer still got the email.
Architecture
Components:
- World time— when the fact actually became true
- Ingestion time— when the system of record learned about it
- Snapshot time— when retrieval indexes were last rebuilt
- Retrieval time— when context was pulled for this turn
- Reasoning time— when the model produced its output
- Action time— when the tool changed something in the world
Trust Boundaries
- Source → Snapshot — snapshot lag — known and bounded
- Snapshot → Retrieval — retrieved context inherits snapshot age
- Retrieval → Reasoning — model reasons against a frozen view of the world
- Reasoning → Action — action ships against world time, not reasoning time
Threat Surface
| Threat | Vector | Impact |
|---|---|---|
| Stale-context-correct-reasoning | Model reasons correctly from outdated context; action is wrong against world time | Confident wrong actions — the most dangerous failure mode |
| Snapshot lag exploitation | Attacker times an action to land between source change and reindex | Authorized action against a state that no longer exists |
| Irreversible action on stale state | Email sent, refund issued, account locked based on context older than the underlying fact | External-world consequences that can't be undone by reindexing |
| Time-of-check vs time-of-use | Permission was valid at reasoning time, revoked before action time | Action ships under stale authorization — TOCTOU at the AI layer |
| Cache poisoning amplification | Bad data in a snapshot persists across many reasoning events until next reindex | Single corruption affects many decisions, not one |
The ZIVIS Position
- •Stamp every event with all clocks.World time, ingestion time, snapshot time, retrieval time, reasoning time, action time. Every event in the chain carries all of them. Cost is one row in a span; benefit is the ability to ask which clock the action ran against.
- •Staleness budgets per action class.A read-only summary can tolerate hours of staleness. An outbound email can tolerate minutes. A contract amendment can tolerate seconds. The budget belongs in the action's authorization policy, not in the cache config.
- •Reconcile at action time, not reasoning time.Before a high-impact action ships, re-check the source against the snapshot the model reasoned from. If they diverge, abort or escalate. The cost of the round trip is paid once, against the largest blast radius.
- •Distinguish 'correct then' from 'correct now'.Audit logs need to record both the state the model reasoned from and the state at action time. 'The model was right when it decided' is a defense for the model. It is not a defense for the user the action affected.
- •Freshness is necessary, not sufficient.Faster reindexing reduces but does not eliminate temporal divergence. Any system with a snapshot has a window. Treat the window as a security property, not a performance one.
What We Tell Clients
If your AI system takes action — emails, tickets, refunds, code changes, customer updates, contract operations — you have a temporal-provenance problem whether or not you've named it. Most teams discover it after the action that shouldn't have shipped shipped.
The fix isn't faster caches. The fix is making time a first-class property of every event, with staleness budgets attached to every action class, and reconciliation before any action with external consequences.
Your architecture should be able to distinguish between an action that was correct at reasoning time and an action that was correct at action time — and refuse or escalate when they diverge.
Related Patterns
- Event-Driven Architecture— where the multi-clock problem lives
- Semantic Caching— the most common source of snapshot lag
- Naive RAG— retrieves from snapshots without surfacing their age
- Capability Tokens— where staleness budgets attach to action authorization
- Audit Logging— must record both reasoning-time and action-time state