Finding — Content-to-Engagement Routing (Scope Recognition)

Version. 0.1 · Date. 2026-07-01
Status. Recorded finding. NOT Room 1, NOT the upload issue — a distinct capability. Queued behind Room 1 closure and the upload work, per Operator sequencing. Likely a regression or inconsistency, not a missing feature (see the birthdays-vs-meetings comparison below) — the Operator states personal messages were previously identified well.
Origin. Operator live use, 2026-07-01, E0060 (Houseplant — Fenwick). Operator put meeting/personal notes into the plant engagement; they were captured into Fenwick's memory rather than recognized as belonging elsewhere.

Correction — 2026-07-01, from E0030 personal-space evidence

The original framing of this finding was WRONG and is corrected here. The original said meeting notes "got stuck in Fenwick / were held in the wrong engagement." Subsequent inspection of the Operator's Personal engagement (E0030, "Personal — Marvin Percival (Operator)") shows the meeting notes DID reach personal space — they are held there (E0030 Held 21–26: "Meeting on Friday at Claude code Miami", "Elder might come to the meeting", "with Justin to make him aware of steel and Loom works", etc.), alongside "Name is Marvin", "Car parked on Level 8", "Lucas's birthday is July 21", preferences, and (in Settled) the birthdays.

So personal content is being routed to personal space. The routing is NOT simply broken. What remains genuinely open:

Whether the meeting notes also wrongly landed in Fenwick (E0060), OR whether what appeared in the Fenwick view was the Companion recalling across engagements (reaching into personal space from within Fenwick) rather than the notes being duplicated into Fenwick. This needs a targeted check: are the meeting assertions present in E0060's memory, or only in E0030 and surfaced via cross-engagement recall?
Whether routing to personal happens reliably or inconsistently — the Operator's "went backwards" report still stands and is worth diagnosing, but the failure mode is subtler than "stuck in the wrong place." It may be about when/whether the Companion recognizes-and-routes vs silently dual-holds.

Net: downgrade from "routing broken" to "routing works but its consistency and dual-hold behavior are unclear." The birthdays-vs-meetings comparison below still holds as diagnostic material, but both birthdays AND meetings are in personal space — so the real question is E0060 contamination / cross-engagement recall, not "meetings lost to Fenwick."

Key diagnostic evidence — birthdays routed, meetings did not (same session, same engagement)

This is the crucial observation and the diagnostic anchor. In the SAME engagement (E0060, Houseplant/Fenwick):

Content	Outcome
Birthdays (8:35 AM "list birthdays" → 8 names)	Routed correctly — NOT in Fenwick's memory; live in the Operator's personal space; recalled cleanly across engagements from within Fenwick.
Meeting notes ("Meeting Friday at Claude code Miami", etc.)	Routed WRONG — held IN Fenwick, not routed to personal space, even after the Operator said "these are supposed to be in my personal space."

So personal-recognition-and-routing is NOT wholly broken — it works for birthdays and fails for meetings. The diagnostic question is therefore precise and findable: why did birthday-shaped personal content route to personal space, but meeting-shaped personal content get stuck in the current engagement? Candidate explanations (to test when diagnosed, NOT asserted): birthdays entered at a time/path where routing worked and meetings after a change; birthday content triggers personal-routing and meeting content does not; the two were entered through different pathways; the capture-eagerness added in CR-2026-127 (wide net, capture-shows-number, over-accept-after-offer) overrode a scope-recognition/routing judgment that previously gated capture. The Operator's report that this "went backwards" points at a regression from recent capture-path work.

Diagnosis deferred (Operator decision 2026-07-01: record, return to Finding 1b merge first). The working-case/failing-case comparison (birthdays vs meetings) is preserved here so the diagnosis stays findable when scheduled — it does not require the live session.

Plain-language summary. The Companion captures whatever the Operator says into the current engagement, without judging whether the content actually belongs there. In the observed session, meeting and personal notes ("Meeting on Friday at Claude code Miami", "want to make Justin aware of steel and Loom works", "Aldous might come to the meeting") were held as notes inside the Houseplant (Fenwick) engagement — a plant-care record now holds work-meeting notes.

The Operator's expectation: the Companion should recognize that a note isn't about Fenwick and route it to the Operator's personal space (or offer to), rather than hold it in the wrong engagement.

What's telling about the observed behavior

The Companion can detect the mismatch — but doesn't act on it:

At one point it said: "this meeting doesn't connect to Fenwick's care record, so it's outside the scope of this project. Do you have another project where meeting notes belong, or would you like to start one?" — so the recognition capability exists.
But it still held the note in Fenwick anyway, and for the other meeting notes it didn't flag the mismatch at all — it just captured them.
The Operator even said explicitly "These are supposed to be in my personal space" — a direct destination signal — and the notes were still held in Fenwick, not routed.

So the gap is precise: recognition happens inconsistently and is not connected to action. The Companion notices "this is off-scope" sometimes, comments on it, but neither routes the note nor reliably asks — it defaults to capturing into the current engagement regardless.

The decided expectation (Operator, 2026-07-01)

Recognize off-topic content and route it to the right space (or offer to). When captured content doesn't fit the current engagement, the Companion should recognize that and route it to the Operator's personal space — or offer to — rather than (a) silently holding it in the wrong engagement or (b) refusing to hold it and blocking.

Preferred over "refuse and ask where it belongs first" — the Operator wants the helpful routing behavior, not a gate.

Why this is its own capability (scope + design)

This is neither a Room 1 conformance issue nor the upload issue. It's a third capability — content-to-engagement routing / scope recognition — and it touches concepts already in the architecture:

Personal engagement / personal space — the destination for personal notes exists as a concept (the forget-about-me work operates on personal-memory assertions).
Engagement scopes and the membership/reference model (the domain-composition work — engagements belonging to different scopes) — routing content between engagements is adjacent to how engagements relate.
The capture classifier — today it classifies capture-intent but does not classify destination. Adding "does this belong here, and if not where" is a new judgment layer on capture.

Design questions to ground before scoping:

How does the Companion judge "belongs / doesn't belong" reliably (not just occasionally)? It's a fuzzy content-vs-engagement-topic judgment — the same build-wide-then-reduce caution as the natural-language work applies.
Does it auto-route to personal space, or propose ("This looks like a meeting note, not about Fenwick — save it to your personal space instead?") and let the Operator confirm? (Consistent with Operator-authority: likely propose, not auto-act — the machine surfaces, the Operator approves. But the Operator said "route it to my personal space (or offer to)" — so at minimum offer.)
What are the destinations? Personal space is one. Are there others (route to a named other engagement — "this belongs in the Aldous project")? The Operator has multiple engagements.
Interaction with over-eager capture (finding R2): both are about the capture moment judging content better — may share a solution.

Sequencing

Per Operator (2026-07-01): finish Room 1 first (Finding 1b + Finding 3), then uploads, then this. Upload is friction-to-fix-soon; this routing finding is recorded and queued. Likely grouped with or sequenced near the held-tray robustness work (R1/R2) since all three are about the capture moment being smarter.

Queue as it stands:

Room 1: Finding 1b (retract — built, awaiting merge) → Finding 3 (false-success audit, small) → Room 1 closes.
Upload pathway: files-of-all-types + text descriptions of file contents + folder uploads, entering Memory (friction-to-fix-soon; grounded against prior upload-pathway work).
Held-tray robustness (R1 referent-tracking, R2 over-eager-capture) + this scope-recognition finding (related — all capture-moment judgment) + the wide-net reduction.
Boundaries arc (parked; keystone test written-not-run) — after Room 1.

DUNIN7 — Done In Seven LLC — Miami, Florida · Loomworks — Finding: Content-to-Engagement Routing — v0.1 — 2026-07-01