---
title: "Event time vs ingestion time in AI memory"
description: "Event time vs ingestion time: why AI memory must order facts by when things happened rather than when they were imported, and how to backfill history safely."
canonical: https://past.dev/guides/event-time-vs-ingestion-time
last-updated: 2026-09-02
---
# Event time vs ingestion time in AI memory

Source: https://past.dev/guides/event-time-vs-ingestion-time

Event time is when something happened, taken from the source record. Ingestion time is when the memory system received that record. The event time vs ingestion time distinction matters because the two can differ by years: a support ticket from 2024 may be imported in 2026. A memory system should order facts, answer date questions and build validity windows from event time, while recording ingestion time separately for audit. Systems that only track ingestion time answer every date question with the import date.

## Two timestamps with different meanings

Event time is when something happened in the world, read from the source record itself: the date header of an email, the created field of a ticket, the meeting date on a transcript. Ingestion time is when the memory system received the record. For live traffic the two sit minutes apart. For imported history they can differ by years, and every temporal feature built on the wrong one inherits the error.

The vocabulary comes from stream processing, where windowed computation over the wrong clock produces wrong aggregates. [Apache Flink's documentation on notions of time](https://nightlies.apache.org/flink/flink-docs-stable/docs/concepts/time/) defines event time and processing time for streams, and memory systems inherit the same distinction.

| Property | Event time | Ingestion time |
| --- | --- | --- |
| Meaning | When it happened | When the system received it |
| Comes from | The source record's own timestamp | The system clock at write |
| Should drive | Ordering, validity windows, date answers | Audit, debugging, reprocessing |
| During a backfill | Unchanged by the import | The afternoon the import ran |

## The backfill trap

A backfill is the import of pre-existing history into a new system. A team adopts a memory layer in August 2026 and loads two years of CRM notes, tickets and email in one afternoon. If the system stamps records at arrival, every fact in the store now carries the same August 2026 date.

- **Date questions return the import date.** Asked when the Acme contract was signed, the agent answers August 2026, because the store has no other date.
- **Orderings collapse.** Two years of sequence compress into one afternoon. A renegotiation, the complaint that caused it and the cancellation that followed become simultaneous, and every question about what led to what is unanswerable.
- **Recency ranking misfires.** Retrieval that boosts recent facts treats a 2024 pricing note as new information.
- **Supersession inverts.** When the old value is imported after the new value, a last write wins rule promotes stale data to current.

The trap is quiet. Ingestion succeeds, recall returns text, and the damage only becomes visible when someone asks a question with a date in it.

## Late arrivals and corrections

Out-of-order arrival continues after the initial backfill. A meeting transcript is uploaded a week after the meeting. An invoice correction arrives a month after the invoice. A system ordered by ingestion time files each record on the day it arrived rather than the day it describes.

Ordering by event time places a late record in its true position, and a correction supersedes the value it corrects as of the correct date. Keeping ingestion time as a second, separate timestamp preserves a different capability: reconstructing what the system knew on a given day. Storing both clocks is the bitemporal model, covered in [bitemporal data](/guides/bitemporal-data).

## What to require from a memory layer

Backfill safety is a property of the write path. Four requirements cover it:

1. **An explicit timestamp on every write.** The ingest call must accept the record's own event time as a `timestamp` field alongside the `content` text. A write API with no timestamp field cannot backfill correctly.
2. **Event time drives ordering and windows.** Fact ordering, [validity windows](/glossary/validity-window) and date answers must all derive from event time.
3. **Ingestion time recorded separately.** Arrival time answers audit and debugging questions. It must never replace the source date.
4. **Point-in-time recall.** With both clocks stored, the system can answer as of a past date. [Point-in-time recall](/glossary/point-in-time-recall) defines the operation.

One edge case needs a rule: a record with no usable source date. Receipt time is the only option there, and the record should be marked so a source date can replace it if one turns up.

## How past.dev assigns the two clocks

past.dev takes event time from the caller. POST /api/v1/ingest accepts raw text in a `content` field plus a `timestamp` field carrying the source's own date, and each stored fact takes its event time and validity window from that source timestamp rather than from the moment of import. The request format is documented in the [quickstart](/docs/memory-api/quickstart).

## Testing a backfill

One test catches the whole failure class. Backfill a small fixture carrying original timestamps, then ask a date question.

```backfillfixturewithsourcedates
ingest { "content": "Board note, 2025-03-14: Acme moved its HQ to Austin.",
         "timestamp": "2025-03-14T00:00:00Z" }

ingest { "content": "Update, 2026-01-09: Acme opened a Denver office.",
         "timestamp": "2026-01-09T00:00:00Z" }

recall { "query": "When did Acme move its headquarters to Austin?" }

Pass: the answer cites March 2025, taken from the source record.
Fail: the answer cites the day the import ran.
```

Run the fixture again in reverse ingestion order and assert that no answer changes. Temporal questions of this shape appear in public memory benchmarks; the [benchmark methodology](/benchmarks/methodology) page describes how they are constructed and scored.

## Frequently asked questions

### What is the difference between event time and ingestion time?

Event time is when something actually happened, taken from the source record's own timestamp. Ingestion time is when the memory system received the record. They can differ by years when historical data is imported.

### Why does my AI agent think everything happened on the day I imported my data?

The import stamped every record with its arrival time, and the system has no other date to use. Re-ingest the history with each record's original timestamp through a memory layer that orders by event time.

### Should an AI memory system order facts by event time or ingestion time?

Order and answer by event time, because users ask about when things happened in the world. Keep ingestion time as a separate field for audit and debugging.

### How do I backfill historical data into an AI agent's memory?

Send each record through the normal write path with its original timestamp instead of letting the system stamp it at arrival. Then verify with a date question: the answer should cite the source dates rather than the import date.

## Related

- [Bitemporal data](https://past.dev/guides/bitemporal-data)
- [Temporal databases](https://past.dev/guides/temporal-database)
- [Facts that change over time](https://past.dev/guides/facts-that-change-over-time)
- [Point-in-time recall](https://past.dev/glossary/point-in-time-recall)