Loomworks — Quick-capture Engagement Investigation — v0.2

Version. 0.2 Date. 2026-05-09 Status. Investigation. Thinking material — pattern crystallized, not yet specified for build. Author. Claude.ai (investigation layer). Operator: Marvin Percival. Provenance. v0.1 produced architectural framing for quick-capture as a substrate intent-class engagement. v0.2 absorbs three live conversations after v0.1 landed:

Companion identity at the wake-word surface — what happens to "Hey Companion" when the Operator has named the Companion "Freda."
Three-utterance temporal-coherence example — parked on level 10 then where did I park then parked on level 7. Surfaced supersession-resolution and the query class as siblings to capture.
Trinity → quartet → bidirectional reframing — v0.1's methodology-trinity framing (Companion-proposes/commits, converses, routes-and-records) was the wrong shape; quick-capture is one class of bidirectional Memory traffic on a fast path with three modes (write-clean, write-with-resolution, read), not a third write-class peer.

Informed by. Phase 41 (Companion identity, personal engagement, companion_name column, PATCH /me/companion-name). Phase 42 (intent classification, three-stage pipeline, ask_about_past_input and general_conversation intents). Phase 43 (personal memory contribution, remember_about_me / forget_about_me, held + conversational commit, cross-promotion instruction, retraction discipline). Phase 38 (declare-and-register pattern; engagement specification grammar). Methodology v0.20 (Companion identity, executor opacity, Memory expectations). Companion as Agent Investigation v0.1. Closed-loop Engagement Investigation v0.1 (Companion as attribution channel; observation distributed and attribution centralized). Knowledge Elevation Pathway Investigation v0.1 (held + commit lifecycle as universal write path).

1. The framing question

The Operator's question carries three claims worth unpacking:

Companion present on mobile — a capture-device claim.
Always listening — a posture claim about the device.
I parked on level 10 — a payload claim about what the Companion does with the captured utterance.

Claims 1 and 2 are mobile-presence questions, treated in the companion investigation. This document treats claim 3.

The payload is subtly different from anything the converse pipeline currently handles. I parked on level 10 is not a project conversation. It is not a remember_about_me (the fact is not about the Operator's identity, preferences, or constraints — it is about the world, and only briefly). It is not add_knowledge (no project context). It is not general_conversation (no expectation of dialogue). It is closer to dictation that lands somewhere, plus the ability to read what landed there.

The framing question this document treats: what class of turn does Loomworks need to handle bidirectional Memory traffic on a fast path — utterances that log a fact and stop, queries that read what was logged, and follow-ons that update or replace what was logged?

2. What lands

The architectural form of the answer:

There is a class of turns — quick-capture turns — that are structurally distinct from conversation. The class is one class with three modes, not three classes:

Write-clean. New fact; no conflict with active Memory. Capture, route, author held assertion, brief acknowledgment, stop.
Write-with-resolution. New fact conflicts with or supersedes a structurally similar prior assertion. Capture, route, detect conflict; either auto-supersede with the acknowledgment naming the supersession, or surface a single disambiguation question, resolve, stop.
Read. A query against what quick-capture has captured. Read the relevant Memory; render a short answer; stop. No new assertion authored.

All three share: bypass of the conversational pipeline's full machinery, dictation-class voice register, terminal turn shape (no dialogue accumulation), engagement-determined destination via the Companion's routing, Operator-authoritative naming of the Companion at every surface.

The following crystallize:

Quick-capture is bidirectional Memory traffic on a fast path. Writes (with three modes) and reads share the same surface, the same router (which now must resolve destination and identify whether this is a query against existing Memory), and the same voice register family. v0.1's framing of quick-capture as a write-only third class was wrong; reads are sibling on the same fast path.
The destination is engagement-determined, not capture-determined. The same utterance — "I parked on level 10" — could land in personal Memory (if no specific engagement claims it), a parking engagement (if one exists), or a daily log engagement (if one is the Operator's catch-all). The Companion routes; the device only captures.
Routing is a Companion responsibility, not a capture-device responsibility. A mobile shortcut, a keyboard shortcut, a watch complication, and a browser extension all deliver the same utterance to the same routing logic.
Voice register is its own family. Four templates at minimum: clean ack, query response, disambiguation question, post-resolution ack. All short; all dictation-class; resistant to the conversational pipeline's tendency toward warmth and elaboration.
The held + commit lifecycle still applies and gets sharper. Quick-captured assertions enter at held and progress through the standard lifecycle — and the held layer is exactly where supersession resolution happens cheaply. Held is not just methodologically conservative; it's the layer where the temporal-coherence pattern works without ceremony.
Companion-name authority lives in companion_name (Phase 41) and propagates to every quick-capture surface. Wake-word at the OS layer, foreground listener inside the mobile app, watch complication label, browser extension popup label, chat surface label — all read from the same source.
Quick-capture composes with existing Loomworks substrate. No new engagement-class concept; no new actor kind; no new room. Existing pieces in a different order, plus a small new surface.

What does not land in this document: which of two architectural shapes (intent-class extension vs. pre-classifier fast path, or hybrid) the substrate uses to deliver the class. That is the central open question at §7.

3. The working-through (v0.1)

v0.1's six rounds of working-through are preserved here in compressed form for the Discovery record. The substantive new working-through is in §4 (added in v0.2).

3.1 Round one — is this just `remember_about_me`?

Initial framing. I parked on level 10 is a personal fact; Phase 43's remember_about_me already handles personal facts; quick-capture is just remember_about_me from a voice surface.

Why it fell. Three structural mismatches: scope (parking-location is transient, not lifetime; would pollute personal Memory), lifecycle (remember_about_me requires a conversational confirmation turn — quick-capture must not), and conversational shape (the full converse pipeline's overhead is wrong economics for dictation-frequency turns).

What landed. Quick-capture is a different kind of turn. It might use remember_about_me-style routing for personal-fact destinations, but the turn shape is distinct.

3.2 Round two — what does dictation actually need?

The dictation-class turn structurally requires capture, routing (operator-declared rules → engagement-context default → light heuristic, with personal-Memory fallback), authoring as held, brief acknowledgment, and stop. Notably not required: classifier-LLM call across seven-or-more intents, persona-system-prompt assembly, full responder LLM call. The dictation-class turn requires less of the converse pipeline than conversational classes do.

3.3 Round three — routing as the substantive piece

Three routing-shape candidates surfaced — engagement-context routing, content-classification routing, Operator-pre-declared routing. None exclusive; the workable router is all three, layered:

Operator-declared rules (Memory-stored) consulted first when present.
Engagement-context default when capture device surfaces context and no rule fires.
Light heuristic (string matching on engagement names; keyword maps; personal-fact detection per Phase 43 boundary) as fallback.

LLM classification reserved for ambiguity the deterministic layers can't resolve.

3.4 Round four — acknowledgment as its own voice surface (v0.1 framing; sharpened in §4.4)

v0.1 named three properties: capture-confirming (echoes enough of the captured fact for the Operator to spot speech-to-text errors); routing-confirming when ambiguous; silent on the obvious. v0.2 sharpens — the surface needs four templates, not one. See §4.4.

3.5 Round five — the held-vs-committed question (v0.1 framing; sharpened in §4.5)

Three options: lands committed directly (Option 1, requires post-Phase-45 delegation contract); lands held with asynchronous batch commit (Option 2, alpha-recommended); lands held with auto-commit-after-delay-unless-touched (Option 3, structurally complex). Option 2 was the alpha recommendation. v0.2 sharpens — Option 2 is more than methodologically conservative; it's the layer where supersession resolution works without ceremony. See §4.5.

3.6 Round six — the engagement that doesn't exist yet

Add milk to the grocery list when no grocery-list engagement exists. Three responses surfaced — auto-create (rejected: long tail of single-use engagements); prompt at next chat open (recommended: matches engagement-creation discipline); route to default catch-all as alpha fallback (acceptable). Connects to the queued direction Engagement creation assistance + Discovery-to-seed skill.

4. The working-through (v0.2 — three new rounds)

4.1 Round seven — the three-utterance example

The example. Sequenced utterances raised in conversation:

"Freda, I parked on Level 10."
"Freda, where did I park?" (later)
"Freda, I parked at level 7." (later still)

Initial framing. All three are quick-capture turns of the v0.1 shape — capture, route, ack, stop.

Why it fell. Only utterance 1 fits that contract. Utterance 2 is a query against what utterance 1 captured — no new assertion authored, a read instead. Utterance 3 looks like utterance 1 but the Companion now has context: there's a recent (same-day, plausibly same-trip) parked_at assertion. Authoring a second parked_at without addressing the first creates an ambiguity — different building, moved car, mishearing — and three different Memory shapes follow.

What landed. Three things:

Quick-capture has sub-modes. v0.1's "capture, ack, stop" describes write-clean. Two further write modes — write-with-supersession (Companion notices conflict and acts; ack names what was replaced) and write-with-disambiguation (Companion notices conflict and asks one focused question, resolves, stops) — are needed for the temporal-coherence cases.
Read is a sibling mode on the same surface. Utterance 2 is not a separate Phase 42 ask_about_past_input invocation; it's the same fast-path surface used to answer a query against what quick-capture wrote. The same wake-word path, the same routing layer (which now also locates the answer), the same voice register family.
The trinity framing from v0.1 §10 was wrong. v0.1 named a "third class" — Companion-routes-and-records — alongside Companion-proposes/commits and Companion-converses. But reads (utterance 2) don't fit "routes-and-records," and forcing them into a fourth class makes the taxonomy unwieldy. Better framing: quick-capture is one class of bidirectional Memory traffic, with sub-modes. The methodology distinctions carry on the axis of write-vs-read and clean-vs-needs-resolution, both within quick-capture.

The reframing has methodology weight worth recording. v0.1 was making a class-of-turn distinction at too coarse a level; v0.2 lands it at the right level (quick-capture as one class; write/read and clean/conflicting as orthogonal sub-mode axes).

4.2 Round eight — the temporal-coherence pattern

Utterance 3 surfaces a property the methodology has not (to my knowledge from project knowledge) explicitly named: single-valued slots vs. multi-valued lists.

parked_at is single-valued. There's one current location at a time. New assertion supersedes the prior one because the slot updates over time.
items on the grocery list is multi-valued. The list accumulates. New assertion adds; doesn't supersede.
I'm allergic to peanuts is single-valued or multi-valued depending on framing — single-valued if the Operator means "this fact about me," multi-valued if it's "another allergy added to my list of allergies."

The methodology so far has treated assertions as additive (every contribution lives; retraction is explicit per Phase 43 / forget_about_me / standard non-erasure lifecycle). Quick-capture surfaces a class of facts where additivity is the wrong default — not because retraction is wrong, but because the retraction-of-prior-when-superseded is implicit in single-valued slot semantics, not Operator-explicit.

Three working observations:

Observation A — slot semantics are an engagement property. The grocery-list engagement says "items are multi-valued, additive." A parking engagement says "current-location is single-valued; trip-history is multi-valued." A daily-log engagement might say "everything is multi-valued" (a log accumulates). The semantics live with the engagement, not with the router or the substrate.

This connects to the Phase 38 declare-and-register pattern. Engagements declare their slot-shapes; the router consults the declarations when deciding whether to propose supersession. Phase 38's pattern was originally for DeclaredShapeTypes / DeclaredRenderTypes; extending it to declared slot-semantics for Memory assertions is a natural generalization but not a v0.2 commit — worth naming as an open direction.

Observation B — Companion-noticed supersession is a different Operator authority than Operator-explicit retraction. Phase 43's forget_about_me is Operator-explicit ("forget that I told you my birthday"). Quick-capture's write-with-supersession is Companion-noticed ("you just said level 7; replacing the earlier level 10"). Both are valid; both should preserve the methodology's commit-by-Operator stance — but Companion-noticed acts on the held layer (no commit exists yet to undo), so it's structurally different from retracting a committed assertion.

This is why §4.5 ends up sharpening §3.5: the held layer is exactly where Companion-noticed supersession works without ceremony. Supersession before commit is "the new held assertion replaces the old held assertion"; supersession after commit would require explicit Operator retraction. Held is the right layer.

Observation C — the time-window heuristic. "Earlier today" matters; "three months ago" doesn't. If both parked_at utterances are within ~30 minutes (or ~hours; configurable), supersession is almost certainly right and the Companion can act with a clean acknowledgment. If hours-to-days apart, it's likely a different trip; both should land. The window is engagement-property too — parking is short-window; I'm based in <city> is months-to-years-window.

The time-window heuristic determines whether the Companion acts unilaterally (write-with-supersession) or asks (write-with-disambiguation):

Same-day, same-engagement, same-slot, single-valued → write-with-supersession (auto; ack names the replacement).
Cross-day or ambiguous → write-with-disambiguation (ask one question, resolve, stop).

What landed. The temporal-coherence pattern is real; it's broader than quick-capture (Phase 43's remember_about_me faces it too — "I'm based in Miami" then three months later "I'm based in Austin" should probably supersede, but Phase 43 doesn't currently do that); the engagement-declares-slot-semantics framing is the cleanest fit. Worth landing as a methodology finding for the next manifest pass — single-valued vs. multi-valued slots as an engagement-declared property; supersession as Companion-noticed action on the held layer. The investigation surfaces it; settling it (whether to retrofit to Phase 43; whether to extend Phase 38's declare-and-register; what the slot-declaration grammar looks like) is downstream.

4.3 Round nine — Companion-name handling at the wake-word surface

Companion identity is already Operator-authoritative inside Loomworks. Phase 41 added companion_name as a column on person, defaulting to "Companion." Phase 42 wired it into the persona system prompt. Phase 41 also shipped PATCH /me/companion-name. Inside the chat surface, notification cards, voice templates that reference the Companion in third person — "Freda" already works.

What the wake-word question targets is the surfaces outside the existing Loomworks UI. Four surfaces with four answers:

Surface 1 — App Intents / App Actions (recommended primary path for mobile). iOS Siri and Google Assistant own the wake word; that's non-negotiable. The invocation phrase after the wake word is what addresses the app. Three options for "Freda" working as part of "Hey Siri, Freda…":

(a) The app's display name set to "Freda." Device-wide; app icon shows "Freda" instead of "Loomworks." Some Operators want this; many don't.
(b) A Siri Shortcut named "Freda" wired to the Loomworks quick-capture intent. Operator confirms a one-tap shortcut at mobile-app onboarding; the app pre-fills the shortcut name from companion_name. Operator says "Hey Siri, Freda" and Siri matches the shortcut. App icon stays "Loomworks" on home screen; invocation uses Freda. Cleanest fit for Operator-authoritative naming.
(c) Static invocation phrases declared in the app's INIntent configuration. Build-time-baked; can't be Operator-configurable. Wrong for this case.

Recommendation: (b). Apple's INShortcut API lets the app suggest the shortcut to Siri with the right name pre-filled. The friction is the one-time confirmation; the payoff is Operator-authoritative naming surviving into the OS voice surface. Several voice-app shippers use this pattern.

Surface 2 — Foreground listening inside the Loomworks app. When the app is open and the mic is granted, the listener uses whatever wake phrase the Operator has configured. The mobile app reads companion_name from the substrate; configures the on-device wake-word detector (Picovoice Porcupine, Snowboy, or platform-native) for "Hey Freda"; routes captured utterances to the quick-capture surface. Most flexible — the wake word literally is the configured companion_name. No Apple or Google constraint applies at this surface. Cost is on-device wake-word training and always-on-mic battery while foregrounded.

Surface 3 — Watch / wearable complications. Tap-to-speak; no wake word. The complication's visible label carries the naming ("Note to Freda"). Trivial: bind to companion_name on substrate read.

Surface 4 — non-voice surfaces (keyboard shortcut, browser extension, watch tap, desktop shortcut). No wake word. Visual label binding to companion_name. Trivial.

The unifying principle. Companion-name authority lives in one place — the companion_name column. Every surface reads from there. What changes per surface is how the OS-or-device wake-word constraint interacts with the Operator-chosen name. The principle that the name belongs to the Operator does not change.

Implications for the routing layer: the router is name-agnostic. It receives an utterance and a destination, not a wake-word-keyed dispatch. Wake-word recognition is upstream of the router; the router doesn't care which name was used to invoke the surface. This matters for the substrate design: the quick-capture endpoint and the routing logic are decoupled from the Companion's name.

Smaller adjacent points worth flagging. Multi-device naming consistency: substrate is single source; each device pulls on launch / connect; rename takes effect on next session start. Cross-engagement reach: Companion identity is per-person, not per-engagement; "Freda" is the Operator's Companion across all their projects; quick-capture's routing-to-engagement doesn't change which Companion is involved. Multi-Operator household / family case: substrate identity is on (person_id, companion_name), not companion_name alone — two Operators who both name their Companion "Freda" don't collide because device authentication disambiguates.

4.4 Round ten — voice register expanded to four templates

v0.1 §3.4 named the acknowledgment as its own register. The three-utterance example expands the register to a family of at least four templates:

Clean-ack (write-clean). "Got it. Level 10." Capture-confirming; short; no follow-up.
Query-response (read). "Level 10 — at 9:13 this morning." Echoes the answer with relevant temporal context.
Disambiguation-question (write-with-disambiguation). "Got it — earlier today you said level 10. Replace it?" Surfaces the conflict; offers Operator the resolution path; one-question-only.
Resolution-ack (write-with-resolution after disambiguation, or write-with-supersession when Companion acted unilaterally). "Done. Level 7 it is." Or, for supersession: "Got it. Replacing the earlier level 10." Confirms the resolution; names what was superseded.

Properties carried across the family:

Short — dictation-class, not conversation-class.
Specific enough to surface speech-to-text errors (echo enough of the captured fact for the Operator to spot misunderstanding).
Routing-confirming when ambiguous; silent on the obvious.
Temporal context only when relevant (the disambiguation question; the query response).

Properties that vary across the family:

Acknowledgment (declarative) vs. question (interrogative). The disambiguation-question is the only interrogative; it must invite a one-token answer.
Identification of what was superseded — only in resolution-ack and supersession-ack; not in clean-ack.
Time-stamp echoing — only in query-response and disambiguation-question; not in clean-ack or resolution-ack.

Likely ships through a voice loader analogous to the credit_voice loader from Phases 49 and 50: loomworks/orchestration/quick_capture_voice.py (or comparable). Each template is a separate file with its own AI-invisibility carve-out (the dictation register may need to name engagement names — "Daily log: level 10" — which makes engagement vocabulary visible; whether that warrants the carve-out's bounded named exception treatment is a scoping question).

4.5 Round eleven (revisiting §3.5) — held layer as supersession-resolution surface

v0.1 §3.5 framed held-vs-committed as alpha posture: Option 2 (held with asynchronous batch commit) was the recommendation, methodologically conservative. v0.2 sharpens: held is more than conservative; it's the layer where the temporal-coherence pattern works without ceremony.

Why held is the right layer for supersession.

Supersession in held is cheap. A new held assertion replacing an old held one is a state transition on objects that aren't yet in the canonical Memory layer. No commit log entry is undone; no audit trail rewrites; no Operator-noticed retraction. The retracted-on-supersession state is just "this held assertion was replaced before it ever committed."
Supersession after commit is expensive. A committed assertion that gets superseded later requires explicit retraction (per the methodology's non-erasure discipline). The audit trail records "X was committed, X was retracted because Y arrived, Y was committed." All correct, but ceremonial.
The held layer is where Companion-noticed action lives. Phase 43's forget_about_me is Operator-explicit retraction; quick-capture's write-with-supersession is Companion-noticed. Held lets Companion-noticed action operate without rewriting committed Memory.

The asynchronous-commit window is the supersession window. When the Operator opens a chat surface, an end-of-day batch fires, or some configurable trigger crosses, held quick-capture assertions migrate to committed. Within the window, supersession is fluid; once committed, supersession requires explicit retraction. This naturally bounds the temporal-coherence pattern: the Companion can supersede freely up to commit, and only the Operator can supersede after.

Configurability. The window length is per-engagement, plausibly per-slot. Parking might be a one-trip window (held assertions commit on next "different location" or end-of-day). Personal facts might be longer (held until the Operator has seen them in a chat surface). Grocery-list items might be no-window (commit immediately; no supersession expected for additive lists).

This makes the alpha posture stronger than v0.1 framed it. Option 2 isn't a defensive fallback; it's the architecturally-required layer for the temporal-coherence pattern.

5. The architectural shape that emerged (revised in v0.2)


[Capture device — wake-word recognized via Companion-name surface (Hey Freda)]
       │
       ▼  (utterance text + minimal context — active engagement if known,
       │   capture device id, timestamp, optional explicit engagement tag)
       │
[Quick-capture entry surface] ──────────┐
       │                                 │  (the §7 architectural question:
       │                                 │   intent-class extension or pre-classifier
       │                                 │   fast path, or hybrid; both reach the same
       │                                 │   router and the same voice surface)
       ▼                                 │
[Mode discriminator]                     │
   write-clean | write-with-supersession |
   write-with-disambiguation | read     │
       │                                 │
       ▼                                 │
[Router — three layers + slot-semantics consultation]
   1. Operator-declared rules           │
   2. Engagement-context default        │
   3. Light heuristic / classifier      │
   Engagement slot-semantics            │ (single-valued? multi-valued? supersession-window?)
   Fallback: personal Memory            │
       │                                 │
       ▼                                 │
[For writes: held assertion authored in destination engagement]
[For reads: Memory query against destination engagement; render answer]
[For writes-with-supersession: prior held assertion transitions; new held assertion authored]
[For writes-with-disambiguation: pause for one-question resolution; resolve; complete]
       │                                 │
       ▼                                 │
[Acknowledgment — voice template family (clean-ack | query-response |
 disambiguation-question | resolution-ack)]
       │                                 │
       ▼                                 │
[Stop. Turn ends.]                      │
                                         │
[Asynchronous commit path — held quick-capture assertions accumulate; commit per engagement
 supersession window or on Operator chat-surface open. Within window: Companion-noticed
 supersession is fluid. Post-commit: only Operator-explicit retraction.]

The substrate work is small to moderate: a router (modest complexity, three layers + slot-semantics consultation); a voice surface (small, four templates); a mode discriminator (small — write/read/conflict-detection); an entry surface (the §7 question — small if intent extension; larger if fast path; either-way moderate if hybrid). The methodology weight is in routing rules, slot semantics, the held + asynchronous-commit lifecycle with supersession, and the voice register family.

6. Composition with existing methodology (revised in v0.2)

Quick-capture composes cleanly with existing methodology. Worth tracing the composition explicitly because each composition is a property the methodology already has, used in a new combination.

Phase 41 — Companion identity. The Companion is the actor on held assertions for writes. ActorRef(kind="companion") — exactly the existing pattern. The companion_name column carries Operator-authoritative naming to every quick-capture surface (§4.3). Phase 41's PATCH /me/companion-name is the one-source-of-truth for naming.

Phase 42 — intent classification. The §7 question depends here. If quick-capture is an intent extension, the classifier extends. If it's a fast path, the classifier is bypassed. In the read mode specifically, Phase 42's ask_about_past_input is structurally adjacent — the read mode might be ask_about_past_input reached through the fast path, with a routing layer that knows to read from the recent-quick-capture-Memory subset rather than the project-narrative-Memory.

Phase 43 — held + commit lifecycle. Inherited directly. Quick-capture lands held; commit is per-engagement asynchronous (the §4.5 sharpening). Phase 43's remember_about_me boundary heuristic powers the router's heuristic layer. Phase 43's forget_about_me is the Operator-explicit retraction path; quick-capture's write-with-supersession is the Companion-noticed path. Both use retraction; the actor differs.

Phase 38 — declare-and-register pattern. Quick-capture's slot-semantics declaration (single-valued vs. multi-valued; supersession-window per slot) extends Phase 38's declare-and-register pattern. Phase 38 was for DeclaredShapeTypes / DeclaredRenderTypes; this is declared slot-semantics for Memory assertions. Same shape; new layer. Open direction; not v0.2 commit.

Phase 45 — delegation contract. Quick-capture is a delegation-contract case in waiting. Auto-commit for trusted quick-capture categories (Option 1 from §3.5) is structurally identical to Phase 45's pre-authorized engine-operation execution. Alpha is asynchronous-commit (Option 2); post-Phase-45 enables Option 1 for trusted categories.

Phase 49 — bimodal dispatch. Quick-capture is plausibly Operator-direct in its commit path. The Companion routes and captures, but does not propose for approval-then-commit. Bimodal dispatch from Phase 49 (delegation_required: bool) is the natural seam if a dispatcher is involved.

Phase 50 — Companion-as-Authority pattern, by contrast. Quick-capture is not Companion-as-Authority. The Companion is not making a proposal for the Operator to approve before action — the Companion is logging or reading a fact. (Write-with-disambiguation might look like a proposal because it asks a question, but the question is about resolution semantics, not about whether to act at all — the Operator already initiated the action by dictating.) This composition note replaces v0.1's "third class in the trinity" framing — see §4.1.

Closed-loop investigation v0.1 — Companion as attribution channel. Quick-capture is a clean instance: many possible observers (phone, watch, browser extension, keyboard shortcut), single attribution channel (the Companion authors the held assertion). Observation distributed; attribution centralized. The principle generalizes to capture devices.

Knowledge elevation pathway investigation v0.1 — held + commit as universal write path. Quick-capture is a high-frequency exercise of this pattern. The asynchronous-commit window from §4.5 is the operational refinement that makes the high-frequency case workable. Worth verifying the held queue UX scales to dozens of held assertions per day — a forcing function the elevation-pathway document didn't have.

7. The architectural question this investigation does not answer (revised in v0.2)

The central design question: how does the quick-capture class (write-clean / write-with-resolution / read) reach the substrate? Three options.

7.1 Option (a) — intent-class extension

Shape. Quick-capture modes become new intents on the existing Phase 42 classifier (quick_capture_write, quick_capture_read, perhaps further granular). Utterances enter the converse pipeline normally; the classifier identifies the intent; the router dispatches; the responder produces the dictation-class voice template-rendered output.

Composition advantages. Reuses classifier, persona system prompt, responder pipeline. Intent extensions are well-trodden ground (Phase 43 added two this way). The intent-class taxonomy stays the canonical statement of "things the Companion can be asked to do." Cross-promotion (Phase 43's "I noticed you mentioned X — should I remember that?") composes naturally.

Composition costs. Two LLM calls per dictated fact (classifier + responder); ~500-800ms+ for the classifier alone. For dictation-frequency utterances, wrong economics. Engagement context loading wastes ~2,000 tokens per quick-capture turn. Conversation-history accumulation pollutes the conversational state. Persona-system-prompt and full responder LLM call for what is structurally a dictation-tone confirmation.

7.2 Option (b) — pre-classifier fast path

Shape. Quick-capture utterances enter through a different surface (a POST /quick-capture endpoint; a Siri shortcut delivering directly to a fast-path handler). The fast-path handler runs the deterministic mode discriminator and router, authors held / reads / handles supersession; emits a voice template-rendered acknowledgment. No classifier LLM call. No persona system prompt. No responder LLM call.

Composition advantages. Cost-appropriate; sub-200ms responses for the deterministic-resolution case. Conversation history stays clean. Different class of input gets a different class of pipeline — methodologically honest. The fast path serves all capture devices (keyboard, browser extension, watch, mobile) with the same machinery.

Composition costs. New surface; new handler; new route. Substrate addition rather than intent-taxonomy extension. Classifier-bypass means no LLM-quality routing for ambiguous cases unless the fast path explicitly delegates to a classifier when its deterministic layers can't resolve. Two pipelines for adjacent operations; methodology must be clear about when each fires.

7.3 Hybrid — intent on the classifier, fast-path on dedicated surfaces

The same intent class with multiple surfaces, just as add_knowledge can be reached through the Memory contribution UI (Phase 16) or chat (Phase 42). High-frequency case (mobile shortcut, watch complication, keyboard shortcut → POST /quick-capture directly): fast path. Chat-pathway version (Operator typing "I parked on level 10" into a chat box): intent extension on the classifier path. Same router, two entry points.

What landed. The hybrid is most likely. Deciding factors are operational cost (LLM-call cost at expected dictation frequency), UX cohesion (how confusing is two surfaces), implementation complexity (the fast path is more new substrate code than the intent extension is). All three are scoping-time questions, not investigation-time questions.

7.4 What the next-stage scoping document needs to decide

Which of the three options.
If hybrid: the seam between the two pipelines (where they converge — likely at the router; potentially at the held-authoring step).
The voice register for the four templates: voice loader at loomworks/orchestration/quick_capture_voice.py analogous to credit_voice? Per-template files with AI-invisibility carve-outs?
The router's three-layer specification (rule format; context-resolution path; heuristic implementation; ambiguity-fallback to LLM or to personal-Memory-default) — plus the slot-semantics consultation per §4.2.
The mode discriminator's implementation (deterministic vs. classifier; how cheap is the conflict-detection check against recent held assertions).
Held vs. committed posture for alpha (Option 2 from §3.5 / §4.5 is alpha; Option 1 reachable post-delegation-contract).
Per-engagement supersession window configuration (§4.5).
Engagement-creation-on-the-fly posture (Option (b) from §3.6; capture device behavior when destination engagement doesn't exist yet).
Companion-name surface integration: Siri Shortcut suggestion at mobile-app onboarding; foreground wake-word detector configuration from companion_name; visual label bindings on non-voice surfaces.

These are scoping questions. The investigation's job is to surface them; the scoping note's job is to settle them.

8. What this investigation does not produce

A scoping note. The next-stage document settles the §7 architectural question and §7.4 sub-decisions.
A CR. CRs come after scoping settles.
An intent-classifier prompt amendment. Depends on §7.4 decisions.
Voice templates. Depend on the four-template register decisions in §4.4.
A routing-rules schema. Depends on the router's layer-1 (Operator-declared rules) decisions in §7.4.
A slot-semantics declaration grammar. The §4.2 framing is investigative; the grammar is downstream of a scoping decision (likely tied to a later phase or to a Phase 38-extension scoping).
A migration. There may not be one — quick-capture might compose with existing tables. Or warrant a small quick_capture_log table for capture-device tracking. Scoping decides.
An engagement-creation-on-the-fly mechanism. The Discovery-to-seed skill queued direction owns that work.
Mobile-app-side specifications (App Intents schema, Siri Shortcut suggestion, on-device wake-word detector configuration, foreground-vs-background mic posture). These belong to the mobile-presence investigation.

This investigation produces architectural framing and a list of decisions for next stages. The output is thinking material, not building material.

9. Open questions for the next stages

Carrying forward into next-stage scoping:

(a) intent extension vs. (b) pre-classifier fast path vs. hybrid. §7. Most likely hybrid; deciding factors operational cost, UX cohesion, implementation complexity.

Mode discriminator. §2 / §4.1 / §5. Deterministic conflict-detection (slot-semantics-aware lookup against recent held assertions) vs. classifier-LLM call. Probably deterministic for the common case; LLM only when the slot-semantics declaration is missing or ambiguous.

Routing-rule schema. §3.3 / §4.2. What does an Operator-declared routing rule look like as a Memory assertion? Likely follows the Phase 49 / Phase 50 cross-engagement-Memory pattern. Boundary question: are rules in personal Memory, in a designated "Loomworks settings" engagement, or per-capture-device configuration?

Slot-semantics declaration. §4.2. How do engagements declare single-valued vs. multi-valued slots and supersession windows? Phase 38 declare-and-register extension? New mechanism? Open methodology direction.

Voice register family. §4.4. Four templates at minimum (clean-ack, query-response, disambiguation-question, resolution-ack). Voice loader at loomworks/orchestration/quick_capture_voice.py? AI-invisibility carve-out treatment for engagement-name visibility?

Held vs. committed posture for alpha. §3.5 / §4.5. Option 2 (held + asynchronous-commit) is alpha. Sub-question: where does the Operator see the queue of held quick-capture assertions for batch commit? Existing chat surface? Dedicated surface? Memory room of the destination engagement? What's the per-engagement supersession-window default?

Engagement-creation-on-the-fly behavior. §3.6. Option (b) (prompt at next chat open) is the recommendation. Sub-question: where does the in-flight assertion live until the engagement is created?

Cross-device deduplication. Same fact dictated through Siri shortcut and watch complication within seconds — do both land? Probably idempotency on (utterance, time-window, person), not (utterance, person), to avoid eating legitimate repeats hours later.

Speech-to-text quality interaction with routing and conflict detection. Misheard utterance ("level 10" → "level Ben") could route differently and also fail to conflict-detect against the prior assertion. Verbatim acknowledgment surfaces this; the conflict-detection layer needs string-similarity tolerance.

Quick-capture and Multi-Contributor engagements. Multi-Contributor quick-capture would have to authenticate which Contributor is dictating. Capture device's auth posture handles Operator-class; multi-Contributor cases need scoping.

Audit and FORAY attestation. Whether quick-capture warrants its own FORAY flow (attesting "this dictation reached this assertion via this route") is open. Probably no for alpha; possibly yes when capture devices proliferate and routing-rule audit becomes a concern.

Companion-name onboarding ceremony for mobile. §4.3 surface 1 (App Intents). Siri Shortcut suggestion at mobile-app first-run with the name pre-filled from companion_name. Friction: one tap of confirmation. Mobile-presence investigation owns the mobile-side specifics.

Temporal-coherence beyond quick-capture. §4.2 observation. Phase 43's remember_about_me faces the same single-valued slot question (city of residence, current employer). Whether to retrofit Phase 43 with supersession or leave it Operator-explicit is a methodology decision worth surfacing.

Relationship to the mobile-presence investigation. Pair sequencing; the mobile-presence document is drafted next and references this one.

10. Implementation-readiness assessment

Quick-capture is not implementation-ready. The §7 architectural question and the §7.4 sub-decisions need scoping. A scoping note is the next document; a CR follows.

Three upstream considerations bear on implementation timing:

Persona-emergence dependency. The voice register family (§4.4) depends on persona stability. Quick-capture acknowledgments fire dozens of times per day; voice quality matters more than at lower-frequency surfaces. Persona-emergence through Phases 42/44/49/50 voice tuning should reach a stable register before the quick-capture voice surface lands.

Mobile-presence dependency. The highest-value surface is mobile. Building quick-capture without mobile presence ships a feature reachable only through chat (defeating most of the value). The two should ship in proximity — paired sequencing, not independent build streams.

Slot-semantics declaration dependency. §4.2's pattern is methodologically important but architecturally significant — extending Phase 38's declare-and-register pattern to slot-semantics is its own scoping question. Quick-capture can ship without it (using engagement-defaulted heuristics, or a hardcoded "single-valued for parking, multi-valued for grocery-list" set), but the declaration-grammar extension is the more durable answer. Whether to ship quick-capture's alpha with or without slot-semantics-declaration support is a scoping call.

The earliest reasonable phase is post-Phase-50 close, post-mobile-presence-investigation, post-scoping-pair. Phase 53+ feels right — one phase for routing substrate; one for acknowledgment voice family; one for capture-device entry surfaces (mobile, keyboard, browser extension); slot-semantics declaration may slip later or land alongside if the scoping reveals smaller surface than this investigation suggests.

11. What this investigation calls forward

The mobile-presence investigation (drafted next; pairs with this one). Capture-device-shaped questions, App Intents / App Actions integration, foreground-vs-background mic posture, iOS vs Android coverage, federation with the desktop/web Operator Layer. The Companion-name handling at the mobile surface (§4.3 surface 1) is mobile-presence's territory in detail.

A scoping note answering §7 and §7.4. After mobile-presence investigation lands so the scoping is informed by the capture-device end.

A CR for the intent extension or fast path or hybrid. Phase 53+.

A queued-direction entry in loomworks-queued-directions-and-deferred-work-v0_2.md for the pair, with cross-references to:
Engagement creation assistance + Discovery-to-seed skill (§3.6 forcing function).
Persona-prompt artifact extraction (§10 dependency on persona stability).
The closed-loop and knowledge-elevation investigations (§6 composition material).
Phase 38 declare-and-register extension to slot-semantics (§4.2 open direction).

A methodology consolidation finding for the next manifest pass: single-valued vs. multi-valued slots as an engagement-declared property; Companion-noticed supersession on the held layer as distinct from Operator-explicit retraction. The investigation surfaces this; the manifest's Section 2 principles slot would fit it. Worth flagging that v0.1's "trinity" framing was reverted in v0.2 in favor of bidirectional-Memory-traffic-with-modes — the methodology distinction is on write-vs-read and clean-vs-conflicting axes within quick-capture, not on a third write-class peer alongside Companion-proposes/commits and Companion-converses.

12. Changelog

v0.1 (2026-05-09). Initial investigation. Six rounds of working-through (§3.1–§3.6). Architectural question (a) intent extension vs (b) fast path raised. Trinity framing proposed (Companion-proposes/commits, Companion-converses, Companion-routes-and-records). Ten open questions for next stages. Implementation-readiness Phase 53+.

v0.2 (2026-05-09). Three substantive absorptions:

§4.1 — three-utterance example surfaces sub-modes and the read class. v0.1's write-only framing replaced; quick-capture is one class with three modes (write-clean, write-with-resolution, read). Trinity framing reverted: quick-capture is bidirectional Memory traffic on a fast path, not a third write-class peer. Methodology distinctions live on write-vs-read and clean-vs-conflicting axes within quick-capture, not at the class-of-turn level. Discovery-trajectory note: trinity framing was wrong shape; v0.2 lands it at the right level.

§4.2 — temporal-coherence pattern surfaced. Single-valued vs. multi-valued slots as an engagement-declared property. Companion-noticed supersession (held layer) as distinct from Operator-explicit retraction (Phase 43's forget_about_me). Time-window heuristic determining write-with-supersession (auto) vs. write-with-disambiguation (one question). Connection to Phase 38 declare-and-register pattern. Methodology-finding-grade observation; surfaced not settled.

§4.3 — Companion-name handling at four surfaces. Companion identity already Operator-authoritative inside Loomworks (Phase 41). Wake-word surface external to Loomworks: App Intents (Siri Shortcut suggestion the cleanest fit), foreground listener (most flexible — wake-word detector reads companion_name), watch complication (visual label binding), non-voice surfaces (visual label binding). Unifying principle: name authority lives in companion_name column; every surface reads from there; routing layer is name-agnostic.

§4.4 — voice register family expanded to four templates. clean-ack, query-response, disambiguation-question, resolution-ack. Likely ships through loomworks/orchestration/quick_capture_voice.py analogous to credit_voice.

§4.5 — held layer's role in supersession sharpened. v0.1's Option 2 (held + asynchronous-commit) was framed as conservative alpha; v0.2 frames it as architecturally required for the temporal-coherence pattern. Asynchronous-commit window doubles as the supersession window. Per-engagement, plausibly per-slot configurability.

§5 architectural shape revised to incorporate mode discriminator, slot-semantics consultation in router, voice-template family.

§6 composition sharpened: Phase 41 (companion_name and naming surface), Phase 38 (declare-and-register extension to slot-semantics as open direction), Phase 43 (forget_about_me is Operator-explicit retraction; quick-capture's write-with-supersession is Companion-noticed — both retraction shapes; actor differs).

§7 architectural question restated to cover the full class (write-clean, write-with-resolution, read), not just write.

§9 open questions expanded from 10 to 14, adding mode discriminator, slot-semantics declaration, supersession-window defaults, and Companion-name onboarding ceremony.

§10 implementation-readiness adds slot-semantics declaration as a third upstream consideration alongside persona-emergence and mobile-presence.

§11 calls forward updated: trinity framing reverted; methodology finding now lands as single-valued vs. multi-valued slots + Companion-noticed supersession on held. v0.1's "third class in the trinity" framing is recorded as the alternative considered and set aside.

Discovery-trajectory v0.1 → v0.2: three live conversations after v0.1 produced one large reframing (trinity → bidirectional with modes), one new methodology pattern named (temporal-coherence / single-valued slots), one substantive surface treatment added (Companion-name across four surfaces), one voice-register expansion (one template → four), and one held-layer sharpening (alpha conservative → architecturally required). v0.1 not superseded as Discovery material; preserved for the trajectory record. The reframing is the most consequential change — v0.1's framing made a class distinction at too coarse a level; v0.2 lands it at the right level (sub-modes within quick-capture, not classes alongside it).

DUNIN7 — Done In Seven LLC — Miami, Florida Loomworks Quick-capture Engagement Investigation — v0.2 — 2026-05-09