Loomworks — first-class personal-recall — scoping note — v0.1

Version. 0.1 Date. 2026-06-10 Status. Scoping note — grounds the CR for a first-class personal-recall capability (Fix B). Drafted from the Step 0 inspection (read-only, against engine main a41ebf5). Awaiting Operator review before the CR is drafted. Technical-consumer document — Markdown primary. Author. Claude.ai (scoping) on direction from Marvin Percival (DUNIN7 Operator). Relates to. The personal-memory reach divergence diagnosis (E0005 vs E0060, this session); the orient capability (CR-2026-099) whose responder-bypass exposed the fragility; the memory=recall reframe (seed-level candidate — explicitly NOT triggered by this work; see §7).

Plain-language summary

The Companion is supposed to recall the Operator's personal facts — birthdays, preferences, who's who — from any engagement, because personal memory is committed as cross-engagement. A browser session showed it failing: asked "birthdays" in one engagement it returned the list (from personal memory); asked the same word in another engagement it returned a menu and no birthdays. Same word, same person, same personal-memory store — different result.

The diagnosis: personal-memory storage is correct and cross-engagement, but personal recall has no first-class capability of its own. It's emergent — it works only when a turn happens to reach the responder, which then reads a personal-memory block dumped into its prompt. When the same query misroutes into a responder-bypassing intent (orientation), recall silently fails. And even when it works, the block is loaded only for engagement-scoped turns and is budget-clipped, so old facts can drop silently.

This work makes personal recall first-class and reliable: a routed, retrieval-backed recall_about_me intent that mirrors the existing engagement-recall intent (ask_about_past_input), pointed at the personal store. It reads the personal engagement directly (works regardless of scope), retrieves the committed personal facts authoritatively (no silent clip), and the Companion composes the answer from them. Plus the classifier guidance that makes the intent fire reliably for the queries it should, and a complementary tightening so bare topic words stop being stolen into orientation.

Recall is retrieved wholesale — the complete set of the Operator's personal facts. Any future topic-filtering is a subset of that complete set; the foundation is the whole, retrieved authoritatively.

This is the engineering fix that honors the cross-engagement commitment. It is not the memory=recall seed reframe (§7) — it makes recall reliable and complete, without making the seed-level claim that recall is the product. That reframe stays separate, Operator-commissioned future work.

1. The problem (grounded)

Personal memory is committed as cross-engagement: person-scoped facts that travel across all the Operator's engagements (classifier: remember_about_me — "Person-scoped: the fact travels across all the Operator's projects"; functional spec §4.1: personal Memory loads alongside every engagement turn by default). The storage honors this — personal facts are committed assertions on the person's invisible personal engagement (Phase 41), the same assertion model as engagement Memory, keyed to the person, not to any engagement. The same store loads identically from every engagement.

But recall diverged: "birthdays" surfaced personal facts in engagement E0005 and not in E0060. The cause is classification/routing, not storage:

• There is no personal-recall intent. The taxonomy has remember_about_me / forget_about_me (writes) and ask_about_past_input (engagement recall), but nothing for reading personal facts back.
• Personal recall is emergent: the responder's prompt carries a personal-memory block ("Things you've told me about yourself"), and the Companion answers personal queries only because the responder reads that block.
• Orient bypasses the responder (the lever-3 server-compose path hardened in CR-2026-099). A turn classified orient never sees the personal-memory block.
• So "birthdays" classified into a responder-bound intent in E0005 (responder ran, read the block, returned birthdays) but into orient in E0060 (server-composed the menu, bypassed the responder, no birthdays). Same word, different per-engagement classifier context, different access to personal memory.

Two further fragilities make even the responder path unreliable (Step 0 flags): the personal-memory block loads only when project_id is not None (project-less converse surfaces none), and it is budget-clipped newest-first (~500 tokens) so old facts drop silently.

Verdict: a real bug against the committed cross-engagement recall, whose locus is that personal recall has no first-class, reliable capability of its own.

2. The design — mirror ask_about_past_input at the personal store

The fix is not a new pattern. ask_about_past_input is already a retrieval-backed, responder-composed recall intent for engagement memory: it classifies → dispatches to a handler → the handler runs list_assertions(engagement_id, committed) → packs results into operation_data → the responder composes from that. A personal-recall intent is the same shape with three swaps:

• engagement_id → person.personal_engagement_id
• the no-project guard → a no-personal-engagement guard
• the engagement-recall template → a personal-recall template

This is the house-standard recall shape, pointed at the personal store. It makes personal-recall and engagement-recall siblings — architecturally consistent, not bespoke. It reads the personal engagement directly (works regardless of scope, removing the project_id gate) and puts the recalled facts authoritatively into operation_data (removing the budget-clip fragility — the responder composes from the retrieved facts, not from a clipped prompt block).

Wholesale retrieval (v1, confirmed). Recall retrieves the complete set of committed personal assertions — the whole. The responder composes the answer from the complete set (picking out "Lisa's birthday" for a Lisa query, or listing all for "what do you know about me"). Any topic-filtering is a subset of this complete set — a future optimization for scale, never a capability the wholesale path lacks. The complete set is the correct foundation; subsetting narrows it, never extends it. (The deterministic matcher _match_assertions_for_forget exists and could back a future topic-filter, but v1 does not use it — wholesale is complete and correct.)

3. The load-bearing part — classifier guidance

Step 0's emphatic finding: the whole bug is a classification miss; the handler is mechanical. The routing/handler changes make the correct classification reliable once it lands — but the classifier reliably picking recall_about_me for the queries it should is the substance. The classifier work:

• A new recall_about_me section in the classifier guidance, mirroring remember_about_me's person-scoped framing, with example phrasings ("when's Lisa's birthday", "what do you know about me", "what are my preferences", bare topic nouns that are personal facts).
• Two load-bearing disambiguations:
• recall_about_me vs ask_about_past_input — personal facts (about the Operator, cross-engagement) vs project content (about the current engagement). The Companion must route "what do you know about me" to personal recall and "what did we decide here" to engagement recall.
• recall_about_me vs orient — recalling a fact is not a capability query. "Birthdays" (a personal fact) must not classify as "what can I do here" (orientation). This is the disambiguation whose absence caused the bug.

4. Complementary fix — tighten orient (independent, defense-in-depth)

Independently of the recall intent, tighten orient's classification so bare topic words do not get stolen into the responder-bypassing orient path. This is classifier-guidance-only (the orient section + the no-match default, which already says bare/ambiguous input should fall to general_conversation, not orient). The two changes compose:

• The recall intent gives "birthdays" a correct, retrieval-backed home.
• Orient-tightening stops "birthdays" being stolen into the bypass in the first place.

Defense-in-depth: even if classification of the new recall intent is imperfect at the edges, a bare personal noun that misses recall_about_me should fall to general_conversation (which reaches the responder and the block), never to orient. The orient bypass should never be the landing for a recall query.

5. Scope

In scope:

• New recall_about_me intent: IntentLabel Literal, classifier guidance (the load-bearing part, §3), router dispatch, _route_recall_about_me handler (mirrors _route_ask_about_past_input, pointed at personal_engagement_id), a personal-recall intent-instruction template.
• Wholesale retrieval: list_assertions(personal_engagement_id, committed) into operation_data; responder composes.
• The two disambiguations (§3) and the orient-tightening (§4).
• The taxonomy count-lock test updates (the orient work hit the same — len(IntentLabel.__args__) asserted in phase-54/55 tests).
• A live-classifier checkpoint (classifier behavior fails silently — confirm empirically, per the orient lesson).

Out of scope (deferred, named):

• Topic-filtered / relevance-ranked personal recall (the subset optimization — a fast-follow for scale; where the memory=recall "find the relevant thing" vision lives).
• Semantic/embedding search over personal memory (none exists; the matcher is keyword/substring only).
• The personal-memory budget-clip on the responder block (the retrieval path makes recall not depend on it; the block itself is a separate concern).
• The memory=recall seed reframe (§7) — explicitly not triggered by this work.

6. Build shape (for the CR)

The orientation rhythm: Step 0 (done — this inspection) → CR → build with checkpoints.

• Handler + intent (mechanical): the recall_about_me intent, handler mirroring ask_about_past_input, template. Wholesale retrieval into operation_data.
• Classifier guidance (load-bearing) — Checkpoint for Operator voice/disambiguation review: the new section, the two disambiguations, the orient-tightening. This is the substance; it gets a real review, like the orientation registry content did.
• Live-classifier checkpoint (the silent-failure guard): empirically confirm "birthdays" / "when's Lisa's birthday" / "what do you know about me" classify as recall_about_me; that they do NOT classify as orient; that "what did we decide here" stays ask_about_past_input; that personal writes ("remember my…") stay remember_about_me. The orient work taught that classifier behavior must be confirmed live, not just by prompt-content tests.
• Browser review before push: the original bug, re-run — "birthdays" in both E0005 and E0060 returns the personal facts identically. Separate push after Operator confirms.

7. Not the seed reframe (explicit)

This work makes personal recall first-class by mirroring an existing recall intent (ask_about_past_input) — a consistency fix, not a new commitment. It does not make the seed-level claim that recall is the product (the memory=recall reframe). That reframe — and the relevance/topic-filtering vision it carries — stays separate, Operator-commissioned future work. This CR advances the reframe (recall becomes first-class and reliable) without requiring the seed to change. Decoupled by Operator direction.

8. Open calls for Operator review

1. Intent name: recall_about_me (mirrors remember_about_me / forget_about_me). Alternative: recall_personal. Lean: recall_about_me (the about_me family is established).
2. Wholesale confirmed (§2) — recall the complete personal set; topic-filtering deferred as a subset optimization. (Operator-confirmed.)
3. Decoupled from the seed reframe (§7) — scoped as the engineering consistency fix. (Operator-confirmed.)

DUNIN7 — Done In Seven LLC — Miami, Florida Loomworks — first-class personal-recall — scoping note — v0_1 — 2026-06-10