Version. 0.2 (v0.1 covered three paths; v0.2 narrows to two mechanical paths and carves semantic recall out as its own foundation-effort — see below) Date. 2026-07-01 Status. Drafted, not executed. Memory-room Finding 3 — the last Room-1 finding. Base: main @ fe6edc9 (post-CR-2026-128). Already staged as 129 (SHA 912335a); this is a content revision to the same number.
v0.1 included ask_about_past_input as a third path. Step-0 found it has no topic filter — it retrieves ALL committed engagement notes and relies on the model to focus on the asked-about topic. Server-composing it without a filter would turn a focused query into a memory-dump (truthful but useless).
The Operator chose to make ask_about_past_input genuinely good — semantic/embedding-based recall (find notes by meaning, not keywords) — rather than either dump-everything or defer with a throwaway intermediate. And reframed it: "Everyone is chasing context. We have the foundations, let's cement them." Semantic recall is not a filter bolted onto this CR — it is a foundation-effort in its own right: trustworthy retrieval built on the trustworthy memory (never-forget, corrections-preserved, provenance, actor-boundaries, write-truthfulness) this room now guarantees. The industry chases better retrieval on shaky memory; Loomworks builds retrieval on memory that can't lie.
Therefore: semantic recall for ask_about_past_input is lifted OUT of this CR into its own foundation-effort (recorded separately, first effort after Room 1 closes). This CR (v0.2) covers only the two mechanical server-compose fixes — clean, low-risk, ready. Room 1 closes on these; the write side and personal recall are then fully cemented, and semantic recall is built deliberately as a foundation.
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.
Both 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. The fix mirrors show_held specifically — Step-0 confirmed show_held uses the generic reusable switch (operation_data["delegated_response"]), while orient server-composes via its own intent-keyed branch. Mirror show_held's mechanism.
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, set it as operation_data["delegated_response"] so it bypasses the model. The reply states exactly what is in the record.
personal_memories=[{"content": ...}] + total_count. Note: display_number is deliberately dropped for personal-fact recall — compose from content + count only. Empty set → say so plainly ("nothing recorded about you yet").
Minor sibling: the write is real (the grant is added via add_assertion), but the acknowledgment prose is model-composed. Fix: server-compose the acknowledgment from the write result, consistent with how the other remember_about_me acks already do it (e.g. the new-fact ack: "Got it — '{extracted}', held.", :2927). This sub-path is the one that didn't.
held (display_number, id); also extracted (the operator's phrasing), delegation.capability, delegation.approval_mode. Compose the ack from the human phrasing / capability label + "held".Not in this CR. Lifted to its own foundation-effort (embedding-based semantic recall). See the scope-change note above and the separate foundation-effort record.
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.
ask_about_past_input is untouched by this CR (unchanged behavior until the semantic-recall foundation-effort).recall_personal and the delegation-grant ack 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 personal facts against a known memory set and confirm the readout matches). Suite green.
Room 1 (Memory) closes — on the two mechanical fixes, per Operator decision (2026-07-01). All four findings addressed:
ask_about_past_input) is elevated to the semantic-recall foundation-effort, NOT left as an open Room-1 gap.Room 1 passes conformance bar v0_2 (five checks + the never-silent principle; the monitor-observability held-question carries to the boundaries arc).
Per the Operator's directive — "Everyone is chasing context. We have the foundations, let's cement them." — ask_about_past_input becomes embedding-based semantic recall: retrieve notes by meaning, then server-compose a faithful readout of exactly the retrieved set. Built as a foundation, on the trustworthy memory this room now guarantees (never-forget, corrections-preserved, provenance, actor-boundaries, write-truthfulness). This is the differentiator: trustworthy retrieval on memory that can't lie, versus the industry's better-retrieval-on-shaky-memory. To be scoped and grounded on its own (embedding approach, where vectors live, sync with never-forget/corrections, provenance-respecting retrieval) — not rushed.