The Companion's write claims are already truthful — when it says "saved", "held", "updated", "discarded", "removed", that message only appears when the write actually happened (CR-2026-127 and CR-2026-128 closed all write paths). The false-success audit (Finding 3) confirmed this: every write-outcome claim is gated on the real result, error paths surface failures truthfully, and the never-silent fallback is uncertainty-shaped, never fake success.
One gap remains, on the read side. When the Companion reports what it remembers — recalling personal facts, or answering "what did I tell you about X" — it hands the real memories to the language model to phrase the answer, instead of composing the answer directly from the data. The data is truthful, but the phrasing is not guaranteed to match it: under pressure the model could state a memory that isn't there, omit one that is, or misstate a count. This is a read-side false-report — nothing durable is corrupted, but the Companion can claim a memory the record doesn't hold.
That matters especially because recall is what Loomworks is for — "Memory = recall." A recall path that can misreport what's remembered undercuts the core value. This CR makes the recall responses truthful by construction, the same way the room's other truthful responses already work.
The room already has the right pattern for responses that must be truthful: server-compose the reply from the data and bypass the language model. Two paths already do this — orient (composes from the generic capability catalog; a code comment notes that routing it through the model previously "invented domain operations") and show_held (composes from the actual held list; "never claims items that aren't there"). When a reply must have a guaranteed shape or content, the room composes it in code rather than asking the model to be faithful.
This CR applies that same, proven pattern to the read paths that don't yet have it. Guarantees in code, not prompts.
All three currently set the real data into operation_data but do NOT set a server-composed delegated_response, so they fall through to the model (path-b) to phrase the answer.
router.py:1131–1181)Recalls the person's committed personal memories. Today: real memories + total_count go to operation_data, the model writes the prose. Fix: server-compose the recall reply directly from the retrieved memories (list them from the data, with the real count), set it as the delegated_response so it bypasses the model. The reply states exactly what is in the record — no more, no less.
router.py:1094)Answers "what did I tell you about X" from committed memory. Same shape, same fix: server-compose the answer from the retrieved matches, bypass the model, so the Companion reports exactly what the record holds.
router.py:2892–2909)Minor sibling: the write is real (the grant is added), but the acknowledgment prose is model-composed. Fix: server-compose the acknowledgment from the write result, consistent with how the other capture acks already work. (Lower stakes — the write happened — but closes read/ack-side truthfulness completely.)
Mirror show_held / orient exactly:
operation_data["delegated_response"] (the ConverseResponse composed in-handler) so converse.py bypasses the responder model for that turn.Do NOT change what is retrieved or stored — this is a reporting fix, not a memory-logic change. The data was already correct; only the phrasing was ungated.
orient and show_held unchanged; write-path confirmations unchanged; the responder still handles genuinely open-ended conversation (only these three reporting paths are server-composed).The Companion's memory-recall responses report exactly what the record holds — no fabricated memory, no omission, no miscount — because the reply is composed in code from the retrieved data, not phrased by the model. Verified at runtime (ask the Companion to recall against a known memory set and confirm the readout matches). Suite green.
Room 1 (Memory) closes. All four findings done:
Room 1 passes conformance bar v0_2 (five checks + the never-silent principle; the monitor-observability held-question carries to the boundaries arc). The parked boundaries arc then opens (keystone test written, not yet run).
Queued (recorded, separate from Room 1): the upload pathway (files/descriptions/folders into Memory), the content-to-engagement routing question (corrected 2026-07-01 — routing works but consistency/dual-hold unclear), the held-tray robustness edges (referent-tracking R1, over-eager-capture R2 incl. commands-as-notes and correction-duplicates), and the wide-net reduction.