# Where a memory came from

A memory changes behaviour, so it has to be answerable for. Every row belongs to exactly one workspace and one tier, carries its own tags, and came from one of four places: a person, the Assistant on request, the end of a call, or a deliberate correction. Actions taken under it are recorded separately in the audit trail, including the ones that were refused.

- **Status:** Available
- **Audience:** both
- **In the app:** #/relationships, #/activity
- **Last verified:** 2026-09-10
- **Canonical:** https://connectbyjbrh.com/docs/memory/provenance/

## Why origin is part of the fact

A claim that shapes what a business says to its customers is not the same kind of object as a note in a spreadsheet. Six months after it was written, the only questions that matter about it are whether it is still true and who thought it was. Without the second answer, the first cannot be settled by anything except opinion.

The pattern is the same one Connect applies to files, which are created and modified as new versions with provenance and audit rather than overwritten. Anything that can change an outcome keeps a record of how it got there.

## The four origins

| Origin | How to recognise it | What to check when it looks wrong |
|---|---|---|
| A person, in the viewer | Written in a human register, usually at the tier of the screen it was added from | Whether the tier still matches the intention |
| The Assistant, on request | A tool call inside the workspace, under the same isolation as any other write | Which record the request was actually about |
| The end of a call | Arrives with the summary, a moment after the conversation closes | Whether the conversation cleared the summariser floor at all |
| A deliberate correction | Written after something went wrong, often contradicting a broader tier | Whether the broader row it corrects is still there |

There is no fifth origin on the written channels: reading an email or a chat does not write memory. A row that nobody can account for is therefore worth treating as a question rather than a fact — most often it turns out to be a call-derived line on a person whose identity resolved differently from what you assumed.

## What the record keeps

**The workspace** — Every row belongs to exactly one, filtered by the SQLAlchemy kernel and again by row-level security. There is no shared or global memory.
**The tier** — Which of workspace, channel, endpoint or contact owns it — visible in the viewer's grouping and in the memory sheet of the grid.
**The tags** — Including any directive. Tags are behaviour, not description, so they are part of the provenance question rather than incidental to it.
**The action trail** — Separate from the row. The audit trail records what was decided, by what, under which rule, and what happened — refusals included, because a refusal is a decision.

For the exact stored shape of a row — the column names and what each one holds — `backend/app/connect_memory.py` is the authority. This page describes the behaviour a person can see and rely on, which is a deliberately smaller claim than a schema listing.

## Writing a row that explains itself

The strongest provenance is the one carried in the text, because that is the part that travels. A row read aloud in a phone brief has no screen around it, no thread beside it and no author panel — it is one sentence in an instruction, and it either stands up on its own or it does not.

1. Name the source of the claim in the sentence when the source is what makes it credible.
   - Result: "Their finance lead asked for statements by post" outlives "send by post" by years, because the second one is unarguable-with and the first is checkable.
2. Give it a rough time when it is the kind of thing that expires.
   - Result: A reader in six months can tell a durable preference from a situation that has probably resolved.
3. Keep it to one claim, and put anything longer in [Knowledge](/docs/knowledge/) where it can be retrieved and cited.
   - Result: The row stays inside the budgets, and material that should be quoted gets to be quoted rather than paraphrased from memory.

## Questions

### Can I tell which call a memory came from?

The record and the conversation are both in the workspace, so a call-derived row can usually be matched to the conversation that produced it by time and person from the timeline. The more reliable habit is to write the row so it does not depend on that — a sentence naming what was agreed is legible on its own.

### Is a memory written by the Assistant less trustworthy?

It is written on somebody's instruction, under the same isolation and the same rules, so the question is really who asked for it and about which record. The screen context the model is given is checked against the database before it is trusted, which closes the case where the request was about a record it was not actually looking at.

### Does the audit trail record memory changes as well as sends?

The trail exists to record what was decided and what happened, refusals included. It is the place to look for actions taken under a memory. For the history of a claim itself — what it said before it changed — [superseding](/docs/memory/superseding/) is the mechanism that keeps it.

## Related

- [How a memory is created](https://connectbyjbrh.com/docs/memory/creating-memory/)
- [Superseding a memory](https://connectbyjbrh.com/docs/memory/superseding/)
- [Memory from a phone call](https://connectbyjbrh.com/docs/memory/memory-from-call/)
- [Seeing what Connect knows](https://connectbyjbrh.com/docs/memory/viewing/)
- [Security and isolation](https://connectbyjbrh.com/docs/security/)
- [Making a next-best-action defensible](https://connectbyjbrh.com/research/evidence-for-next-action/)

## What this page is based on

- docs-source/sources/GENERAL.md §6 — memory rows, tiers and tags
- docs-source/sources/GENERAL.md §5 — what the audit trail records
- docs-source/sources/GENERAL.md §9 — files as new versions with provenance and audit
- docs-source/sources/GENERAL.md §3 — workspace scoping and RLS