Receipts

Every read — /context, /search, /query — returns a receipt id:

One Brain · chain of custodyIllustrative lifecycle

01Sources

Records

Documents

Agent writes

02Review

ProposedHuman or policy decisionAccept · edit · reject

03Context

Accepted stateCited answer[1] source passage

04Receipt

Verifiedrcp_019fWhat the read consumed

{
  "data": {
    "text": "Acme renewed at $120k for 24 months on 2026-03-14.",
    "citations": [
      {
        "source": "hubspot:deal:412",
        "quote": "Acme renewed at $120k for 24 months."
      }
    ],
    "staged": 0,
    "receipt": "rcp_019ffefe",
    "truncated": false
  }
}

Log it next to whatever your agent said. It is the difference between “our model probably had the renewal note” and “here is the exact text it was given, at 11:02 on 14 August.”

Fetching one

A receipt belongs to the key that committed it. Fetch it with the same Brain key that made the read — not your management key, and not a second Brain key on the same Brain. Either of those gets a 404: a receipt records which credential a read was served under, and that binding is what makes it evidence rather than a log line anyone could have written.

curl "$API/v1/brains/tenant:acme/receipts/rcp_019ffefe" \
  -H "authorization: Bearer $NICIA_BRAIN_KEY"

{
  "data": {
    "receipt": {
      "id": "rcp_019ffefe",
      "kind": "context",
      "consumerId": "user:4471",
      "key": { "id": "key_7f3a1c", "name": "Acme web app" },
      "committedAt": "2026-08-14T11:02:44Z",
      "items": [
        {
          "source": "hubspot:deal:412",
          "version": 2
        }
      ]
    }
  }
}

items pins the exact version of every source. If the document has been rewritten twice since, the receipt still resolves to the text that was actually shown.

What changed since

Same scoping: the key that made the read is the key that can reconstruct it.

curl "$API/v1/brains/tenant:acme/receipts/rcp_019ffefe/now" \
  -H "authorization: Bearer $NICIA_BRAIN_KEY"

{
  "data": {
    "changed": [
      {
        "source": "hubspot:deal:412",
        "shownVersion": 2,
        "currentVersion": 4,
        "status": "superseded"
      }
    ],
    "unchanged": 3,
    "deleted": 0
  }
}

This answers the question that actually comes up in an incident: the agent told a customer $120k — was that wrong at the time, or has it changed since? Here it was right when it was said.

changed[] names versions rather than text. source plus currentVersion is the address of what the document says now: GET /documents/hubspot:deal:412 serves it. Re-sending a document under the same id counts — it replaces the document, and every receipt that cited the old version reports superseded from that moment.

Correlating by consumer

Pass a consumerId on any read and you can reconstruct everything one user, job, or session was shown:

curl "$API/v1/brains/tenant:acme/receipts?consumerId=user:4471&since=2026-08-01" \
  -H "authorization: Bearer $NICIA_KEY"

consumerId is a label you choose — user:4471, job:nightly-scoring, session:abc. It is correlation only. It never restricts what a call can reach, so scoping still comes from the key.

Corrections

When something turns out to have been wrong, record the correction against the event rather than quietly overwriting it:

curl -X POST "$API/v1/brains/tenant:acme/corrections" \
  -H "authorization: Bearer $NICIA_KEY" \
  -H "content-type: application/json" \
  -d '{
    "subject": "acme",
    "predicate": "contract_value_usd",
    "value": 145000,
    "reason": "Amendment signed 2026-08-01 was not synced.",
    "correctsFrom": "2026-08-01"
  }'

Then find the answers that were affected:

curl "$API/v1/brains/tenant:acme/corrections/cor_88fe21/affected-reads" \
  -H "authorization: Bearer $NICIA_KEY"

{
  "data": {
    "reads": [
      {
        "receipt": "rcp_019ffefe",
        "consumerId": "user:4471",
        "at": "2026-08-14T11:02:44Z"
      }
    ]
  }
}

That is your notification list: every consumer who was told the old number, with the timestamp and the correlation label you gave them.

Retention

Receipts are kept for 13 months by default and are exportable. They survive document deletion and Brain deletion — an answer you gave a customer stays explainable after they churn.

Review — deciding what lands in the first place.
Context — where receipts come from.