Memory Provenance — Patterns

Origin as a closed enumeration, recorded at write

Problem. When origin is free text or absent, everything downstream that should depend on it — conflict resolution, the agent's hedging language, which items may be asserted to a person — has nothing reliable to branch on, and each consumer invents its own interpretation.

Approach. Define a short, closed set of origin kinds and require one on every write: stated by the subject, read from a system of record, derived from other memories, inferred by a model from unstructured input. The set is deliberately small enough that every consumer can handle all of it exhaustively, and adding a kind is a change that forces every consumer to be revisited. Store it as a typed field, not inside the item's text, so it can be filtered on.

Trade-off. A closed enumeration will not fit everything, and the ambiguous cases — a model extracting a sentence the user did in fact say — get assigned by whoever wrote that code path, inconsistently. Exhaustive handling also becomes a burden that encourages consumers to collapse several kinds into one, which quietly undoes the distinction.

Derivation edges written in the same transaction as the item

Problem. Provenance written after the fact, by a separate job or a best-effort call, is the part that fails. The memory exists and its lineage does not, and the gap is discovered during the one operation that needed it.

Approach. Make the derivation edges part of the same atomic write as the derived item, so a memory cannot exist without its lineage. Where the source is external and may be unavailable, record the reference anyway with a resolvability flag rather than omitting it. Treat an item with no edges as a schema violation on derived kinds, caught at write, rather than as a tolerable gap discovered months later.

Trade-off. Atomicity ties the memory store and the provenance store together, which forces them into the same database or into a distributed transaction, and rules out writing provenance to a system better suited to it. The strictness also means a provenance failure now blocks a memory write, trading recall for traceability at exactly the moments when the system is under stress.

Reference the source, never copy it

Problem. It is convenient to store the source sentence alongside the derived claim, so that a reviewer can see the basis without a join. The result is that the provenance table holds a second copy of user content, with its own lifetime, outside every control designed for the first copy.

Approach. Store only identifiers — conversation, turn, document, tool invocation, prior memory — and resolve them at display time through the same access checks that protect the original. When the source has been deleted, resolution returns an explicit deleted marker, which is accurate and is itself useful information. Provenance then inherits no content classification of its own and cannot become a shadow archive.

Trade-off. Reviewing a questionable memory now requires a join across systems with their own availability and their own access rules, so the common operation is slower and sometimes impossible. Once sources have been expired or erased, the surviving provenance is a chain of dangling references that proves derivation happened but can no longer show from what.

Record the producer, not just the input

Problem. Most memory defects are not caused by a bad source; they are caused by a bad producer — an extraction prompt that over-generalises, a model version that confabulates, a misconfigured agent. Input-only provenance cannot identify the affected set, so the choice is between reviewing the whole store and reviewing none of it.

Approach. Stamp each write with the identity of what produced it: the agent, the model and version, the prompt or extractor revision, and the time window. A defect then defines a cohort that can be swept, re-derived, demoted, or quarantined as a batch, and the same fields allow quality to be compared across producer versions before a change is rolled out widely.

Trade-off. Producer identity is only as reliable as the versioning discipline of the systems doing the writing, and a producer that reports a stale or generic version makes its own cohort unidentifiable. These fields also accumulate on every row and are a tempting target for removal when storage is reviewed by someone who has never needed them.