An assistant remembers that you prefer a particular tool. You remember asking whether that tool was worth trying. Those are different statements, and the difference matters the next time it recommends something in your name.
I want memory to save me from repeating useful context. I don't want a passing question to become a permanent preference. A remembered claim should come with enough of a trail to explain where it came from and what could overturn it.
You can audit one claim without building a memory service. You need access to the relevant conversation or document, permission to inspect the memory that used it, and somewhere private to keep the result. The worksheet works on paper. All examples here are synthetic, not extracts from anyone's assistant.
Separate the statement from the conclusion
There are three things worth keeping distinct:
| Kind | What it establishes | What it does not establish |
|---|---|---|
| Raw record | Someone wrote a particular message, or a tool returned a particular result, at that time. | That the statement was correct, permanent or about the current task. |
| Inferred memory | A system formed a conclusion from those records. | That the person explicitly said it or would agree with it. |
| Authoritative live state | The system responsible for a fact reports its current value when checked. | That an old conversation or cached summary has caught up. |
For a writing preference, the person's current instruction is the authority. For an open support case, inspect the case system. A transcript saying "I closed it" establishes what someone reported; it isn't a substitute for reading the case back.
Hermes's built-in memory uses bounded MEMORY.md and USER.md stores. It also has session search for retrieving past messages. Those give you different evidence: a curated note and the conversation it may summarize.
Honcho's peer representations include conclusions drawn from messages. The Hermes integration exposes both search and synthesized reasoning. An answer about a preference is still an answer to examine, even when a memory system produced it.
Audit the claim that affected an answer
Choose something specific: "prefers Tool Cedar for every project," rather than "knows my preferences." Ask the assistant to identify where that claim came from without dumping the rest of your profile. Request the exact relevant passage, speaker, time and source identifier, plus any later correction. If it cannot retrieve the source, record that gap.
Honcho's evidence feature can return the conclusions and message references its chat reasoning read. That is useful, but its docs make an important distinction: the list can include material the answer did not rely on. Message references also require a separate retrieval to see the text. Evidence collection is opt-in; don't assume your Hermes integration exposes it just because Honcho supports it.
Use the available sources to fill this out:
Synthetic worked audit, not a provider schema
Claim: Prefers Tool Cedar for every project.
Stored in: Example assistant preference note.
Kind: Inference, not an explicit preference.
Source: Fixture conversation A, message 4, user, April 3.
Exact passage: "Try Cedar for this disposable prototype."
Scope supported: One prototype trial.
Later evidence: Fixture conversation B, message 2, user, April 10:
"Keep Cedar out of the next project. I haven't chosen a default."
Source event time: April 3; correction effective April 10.
Memory last verified against sources: Not recorded.
Authority now: The user's explicit correction.
Decision: Replace the general preference with the scoped correction.
Recheck trigger: Before recommending a default for another project.
Verification: Inspect the corrected entry and ask in a fresh session.
Remaining uncertainty: Whether the trial itself was useful.
The worksheet's labels are a review convention, not fields that Hermes or Honcho promises to maintain automatically. Keep source pointers rather than copying an entire private conversation into another store.
Freshness depends on the question
A new memory timestamp can describe an old event. Record when the source event happened separately from when you checked it. If the event time is missing, say so instead of borrowing the summary's creation date.
A writing preference can stay useful for years. A server version needs another check before an operation that depends on it. Recheck a preference when the person changes it, the scope changes, or contradictory evidence appears. "No contradiction retrieved" is weaker than "the person confirmed this today."
Correct the store, then check the next answer
Approve a narrow correction before applying it. For built-in Hermes memory, the documented memory tool can replace or remove an entry. Check the resulting entry, then try a fresh session: Hermes freezes its built-in memory snapshot at session start, so changing the file doesn't rewrite the old prompt.
If you also use an external memory provider, identify which store supplied the claim and check each affected copy. Don't assume correcting one store repaired every derived conclusion. Honcho's deletion guide explicitly says derived conclusions can survive deletion of their source session. Deletion is a separate, destructive operation, not a casual correction shortcut.
Ask the original question again and one nearby question with a different scope. Check that the answer uses the correction without inventing a new universal preference. These are suggested human evaluation steps, not a reported behavioral test of Hermes or Honcho.
A useful audit can end with "source unavailable; ask before relying on this." I'd rather keep that uncertainty visible than let a fluent answer settle it for me.