---
title: "How it works"
description: "Four properties that affect how to call it."
canonical: https://past.dev/docs/memory-api/how-it-works
last-updated: 2026-08-26
---
# How it works

> Four properties that affect how to call it.

Product: past.dev Memory API. Source: https://past.dev/docs/memory-api/how-it-works

1. **Everything is a data point** One input shape: text plus a timestamp. An email, a transcript, a ticket and a note all enter the same way. There are no entities to model, no relationships to define, and no picking what is worth remembering.
2. **Send order sets the queue order** Each project has a sequential queue, so points apply in the order they arrive. Timestamps are backdatable, so years of history can be replayed and land on their real dates.
3. **Reads are only correct once writes settle** Ingestion returns as soon as content is accepted, but derivation continues: extraction into the graph, then maintenance, then distillation. Poll until settled before reading, or the query will hit a graph that is still being written.
4. **Answers carry their evidence** Every answer returns the exact lines the model read, each attributed to its source. When the memory does not hold an answer, the model declines to generate one and sets `abstained` to true.

### Idempotency

Ingestion is idempotent. A point is addressed by your `id` when you send one, else by content hash. Re-sending an unchanged point short-circuits and returns 200 with `"unchanged": true` and the existing `ingestionId`. A crashed backfill can resume by re-running the same loop, and the part that already landed costs nothing to replay.

Changing the `timestamp`, the `group`, the `audience` or the content of an existing point is different: those are derivation inputs, so the point goes back through the whole pipeline.