How to handle facts that change over time

Facts change. A budget moves, a plan is replaced, a contact leaves. If you store every statement as an undated note, search finds all of them. The old value and the new value both match the query, so your agent sees 32k and 40k side by side.

The fix is to separate two times. Event time is when something happened. Arrival time is when your server sent it. A change that arrives today can describe something that happened last week. Memory needs the event time to tell which value is newer.

Memory is dated. When a changed value arrives with a newer timestamp, it becomes the current value. The earlier value stays in memory and stays answerable by date.

You set the date with the timestamp field on ingest. It is ISO 8601 with a zone. You also choose how a change relates to what you sent before. Reuse the same id for the same source: if the text changes, Harny stores a new revision, deletes the memories built on the old revision and ingests the new text. Send the same text again and the result is unchanged, at no cost.

1. Call your server, never a browser. Set the Authorization header with your app key and X-Harny-User with your id for the person.
2. Send the first fact with its event date and a stable id: POST /v1/memory/ingest {"content": "...", "id": "...", "timestamp": "..."}.
3. Read the 202 answer and keep the ingestionId.
4. Poll until the status is completed: GET /v1/memory/ingest/{ingestionId}.
5. When the value changes, send it with the newer timestamp. Use the same id if it is the same source: POST /v1/memory/ingest.
6. Ask for the current value. Recall returns the newest value for the query: POST /v1/memory/recall {"query": "...", "identity": "..."}.
7. Ask what was true on a past date. Results that happened later are dropped.

• You send the arrival time instead of the event time. The newer value then looks older than it is. Set timestamp to when it happened.
• You reuse one id for two different notes. The second text replaces the first as a new revision.
• You recall while sends are still queued. The response carries pending, so the newest value may not be there yet. Poll the ingestion first.

Nadia at Acme tells your app on March 14 that the Acme pilot budget is 32k. Later she says it is 40k. You send the second statement with its own date. A recall for the pilot budget now returns 40k as the current value.

Your support lead then asks what the budget was before the change. You call recall with queryTimestamp set to March 14 for demo-user. The 40k result happened later, so it is dropped, and the answer is 32k.