What does a stored memory entry's provenance prove when an extractor wrote it during the user's own session?

### What a provenance field is actually recording On an assistant that fills long-term memory automatically, each entry typically carries some subset of: an id, the claim text, the component that wrote it, a session id, an owning account, a timestamp, maybe a confidence score. Every one of those is a fact about the *write*, not about the *claim*. That distinction is the whole question. The write genuinely happened inside a session belonging to the legitimate user, performed by a legitimate component, at a real time. Nothing in the record is forged, spoofed or anomalous. And yet the claim itself may have been authored by an unknown sender whose email the assistant read for ten seconds while triaging and never acted on. ### Why this is worse than a forged record A forged stamp is detectable in principle - signatures fail, ids do not resolve, timestamps disagree. A *truthful* stamp that answers the wrong question is not detectable at all, because there is no anomaly to find. The construction does not defeat provenance; it satisfies provenance. Whoever inherits the store is looking at thousands of records that all pass every consistency check they can run. ### The field that is missing, and why it usually is The one field that would decide the question is a pointer back to the exact source span - the message id, the offset, the sender. Auto-extraction usually does not keep it, for the ordinary reason that an extracted claim is a *paraphrase* of material spread across a transcript rather than a quotation of one span, and the transcript itself is discarded at teardown. So even where a message id survives, the text it points at may be gone, and the claim as stored may not appear verbatim anywhere. The consequence is directional and worth stating precisely: a memory entry's provenance proves which session wrote it, not that a person meant it. ### What that does to triage Someone investigating an odd assistant behaviour a month later can usually establish: | Question | Answerable from the store? | | --- | --- | | Which entry produced this behaviour | Often, if recall is logged | | When it was written, and by which component | Yes | | Which session it was written in | Yes | | Which message in that session it came from | Usually no | | Whether the account owner authored the claim | No | The first three look like a complete audit trail and are useless for the actual question. That gap is what turns a single planted claim into an open-ended adjudication problem rather than a cleanup task. ### Naming the obstacle without prescribing the fix The obstacle here is not a filter and not a screen. It is the *record itself*, which everyone reads as attribution and which attributes nothing about authorship. Recognising that is what an interviewer is scoring - candidates who say 'check the provenance' have assumed the record answers a question it was never structured to answer. ### Distinguishing this from adjacent ideas - It is not about whether the store should have a provenance field at all - that is a design conversation about write policy. - It is not about scoping reads to the right user; the entry is in the correct user's scope, legitimately. - It is not model behaviour. The model is downstream and simply reads what recall hands it. The subject is narrower and sharper: an attribution record that is completely accurate and completely unhelpful, because the write it accurately attributes is not the event anybody cares about.