Version. 0.11
Date. 2026-05-12
Author. Marvin Percival (DUNIN7 Operator) with Claude.ai
Provenance. Memory archive consolidation. v0.1 (2026-05-04) supersedes prior memory edits and absorbs the obsolete #16. v0.2 (2026-05-07) adds Section 5 (Agent capability development) capturing two entries from the Phase 47 scoping arc: Claude Dreaming as a Companion behavior pattern, and Claude Managed Agents conceptual primitives. The metadata-driven-runtime section in particular preserves the conversational trajectory that the 500-character memory limit had to compress out. v0.3 (2026-05-09) adds Section 6 (Mobile presence and quick-capture engagement pair) capturing the architectural framing produced by the two paired investigations — loomworks-quick-capture-engagement-investigation-v0_2.md and loomworks-mobile-presence-investigation-v0_1.md. Two entries: the substrate intent-class engagement (quick-capture as bidirectional Memory traffic on a fast path) and the capture-device engagement (mobile presence as a layered composition of OS-mediated, foreground, tap-to-speak, and conversational surfaces). Plus a small mobile-engineering-capacity note that's pacing-readiness, not architecture. v0.4 (2026-05-09) adds Section 7 (Multi-instance fleet and jurisdiction governance) absorbing the substance of two memory edits whose source documents now exist in project knowledge — loomworks-deployment-strategy-v0_2.md, loomworks-hosting-cost-analysis-v0_1.md, and loomworks-white-label-multilanguage-analysis-v0_1.md. Two entries: the multi-instance fleet via DevOps engagements as the deployment topology, and the protocol triangle (Loom + FORAY + OVA) as the methodology framing that makes per-instance regulatory jurisdiction a first-class product feature. v0.5 (2026-05-09) adds Section 8 (External information seams) capturing two entries from a chat session that surfaced the github.com/public-apis catalog and sharpened it into a load-bearing architectural move. Two entries: the general-purpose external API gateway specialist (one specialist for all public APIs, FORAY-attested and OVA-scoped, configuration-driven via Phase 38 declare-and-register), and the public-apis catalog as the reference universe for the gateway. The trajectory note on 8.1 preserves the Operator's reframe from "ship 10-15 first-party adapters" to "build one general-purpose gateway and let the API catalog live as supplied domain in engagement Memory" — a reframe that converts an N-adapter build direction into a build-once-then-configure pattern. v0.6 (2026-05-10) adds Section 9 (Companion ambient context) capturing the Operator's recognition that the Companion should maintain standing awareness of the Operator's current state and relevant environment — substantially more powerful in context than Siri-class voice assistants. One entry in three subsections: ambient context as a first-class capability (the composing posture); the ambient-context decomposition pattern (universal-from-clock-or-seam plus specific-from-personal-Memory); and the relevance bridge (the Companion knowing which ambient context matters for which question, including offering it proactively). The methodology recognition is that trivial-seeming questions decompose into a Memory-lookup component plus an engine-clock or external-seam component, and this decomposition generalizes to a class of ambient-context questions (time, weather, calendar, location relevance, schedule, world-state-relative-to-Operator). v0.7 (2026-05-10) adds Section 10 (The standing Companion) capturing the architectural construct that subsumes Section 9 and several other cross-engagement behaviors. Triggered by the Operator's question "is 'keep me in your thoughts and remember stuff for me; alert me to other Engagement's activity when appropriate' an Engagement?" The unpacking surfaces that what the Operator described isn't an engagement — it's the standing Companion, the Operator-bound mode of the Companion that runs continuously across all engagements. Five subsections: 10.1 names the architectural construct and the standing/engaged distinction with executive-assistant analogy; 10.2 names standing Memory as its own Memory scope distinct from personal-engagement Memory (substrate-shaped decision; load-bearing for v0.21 consolidation); 10.3 names authority and scope (Operator-derived authorization; Operator-declared proactivity scope; the relevance bridge as judgment layer over scope layer); 10.4 names standing/engaged composition (context bridge, observation upload, mode handoff); 10.5 names relationships to existing sections (Section 9 ambient context as a capability of the standing Companion; Section 6 mobile/quick-capture as surfaces of it; Section 5.1 Claude Dreaming as a background-attention pattern). Three Operator decisions captured: standing Memory is its own scope; the standing/engaged Companion vocabulary; the executive-assistant analogy retained. v0.8 (2026-05-10) adds Section 11 (Observer — cross-fleet usage observation engagement) capturing the Operator's recognition that Loomworks itself needs an observation layer to surface UX friction, token-use inefficiencies, methodology drift, and cross-Operator patterns — and his sharp framing that this observation must be content-blind by construction, not by discretion. Five subsections: 11.1 names Observer as a meta-engagement category (engagements whose subject is the operation of other engagements); 11.2 names the content-vs-shape distinction as the load-bearing privacy boundary, structurally enforced at the event-emission layer rather than at Observer's discretion; 11.3 names the two-view architecture (anonymized-cohort view always-on; Operator-identifiable view opt-in with explicit consent); 11.4 names Observer's substrate as event-stream-plus-shape-Memory with views layered on top, and surfaces the substrate decision (event-emission-with-redaction in the fleet topology) as a current architectural prerequisite even though Observer itself is post-fleet; 11.5 names the relationship to existing constructs (cross-references to Section 7 fleet, Section 10 standing Companion, and FORAY/OVA), making explicit what Observer is not. Three Operator decisions captured: Observer name retained; both anonymized-cohort and identifiable-with-consent layers; explicit cross-reference to standing Companion as architectural contrast. v0.9 (2026-05-10) adds Section 12 (Structural defensibility — cross-reference) as a discoverability pointer to two companion documents — the methodology investigation loomworks-structural-defensibility-investigation-v0_1.md (internal architectural recognition) and the positioning document loomworks-structural-defensibility-positioning-v0_1.md (external audience-facing). Triggered by the Operator's recognition that the "illegal use" framing permeating AI discourse should be examined against Loomworks's architecture. The unpacking surfaced that Loomworks's defensibility is structural (rules-in-Memory plus upstream OVA enforcement plus FORAY attestation) rather than filtering-based (model-layer detection of harmful content) — a methodology principle that operates now rather than future work. Section 12 is a queued-direction pointer; the substantive content lives in the two companion documents. Three Operator decisions captured: investigation-plus-queued-direction filing shape; both internal and external audience documents; both render-boundary and protocol-triangle frames carried (render-boundary as simpler external story, protocol-triangle as deeper architectural reality). v0.10 (2026-05-11) absorbs Phase 55 close (Engagement Creation Assistance — Conversational Surface). The engagement creation arc's product loop is now closed end-to-end (Phase 53 substrate primitive + Phase 54 terminal commit symmetry + Phase 55 upstream conversational surface). Section 1 receives substantive updates: §1.1 (Engagement creation assistance pattern) advances current-state from "pattern being practiced in chat / not captured as a product feature" to delivered — the conversational engagement creation surface is live at /operator/create-engagement with two terminal-turn output paths (write-up-as-Discovery-record vs commit-as-brief); §1.2 (Discovery-to-seed skill) current-state extends to note the skill is now reached through Phase 55's Discovery-record output path (the second production caller alongside Phase 53's direct upload-driven extraction); §1.3 (NEW: Engagement creation arc substrate refactor residues) records the two refactor candidates surfaced by Phase 55 Step 3's halt-surface (split draft_engagement into engagement-allocation and Seed-drafting halves; add a raw-Markdown variant of extract_discovery_to_seed_skill); §1.4 (NEW: Phase 31 / Phase 53 multi-path unification verdict) records that the unification question is now verdict-able with full end-to-end evidence and is queued for Phase 56+ as a clarification-scoping candidate. Section 2 receives one current-state update: §2.2 (Phase 32 marketing engagement) advances from "deferred until Marvin asks to revisit" to newly first-class actionable with the close-handoff §9 recommendation surfaced (Phase 32 as strongest Phase 56 candidate; Option C — Discovery-trajectory + Discovery-record render specialists — as alternate; recommendation not binding). The Option D intent_hint Literal refactor candidate (held outside this document's numbered sections in the v0.9-era working notes) is closed: absorbed as Phase 55 Step 1; ConverseRequest.intent_hint now derives from classifier.IntentLabel; parallel-enumeration cascade risk eliminated. Three Operator decisions captured in v0.10: section §1.3 + §1.4 filing shape (refactor residues and architectural verdict opportunities sit inside the engagement creation arc section rather than spawning a new top-level section); Phase 56 recommendation surfaced inside the queued-directions document via §2.2 current-state update (recommendation not binding); methodology candidates surfaced by Phase 55 (inherit prior-phase cost decisions promoted to named principle in manifest v0.40; build-time enumeration sharpening; Operator-probe-as-correction-mechanism; CR-drafting cross-function composition checks; build-close hygiene; tag style annotated-not-lightweight) live in manifest v0.40 not in queued directions. v0.11 (2026-05-12) absorbs Phase 56 close (Engagement Creation Surface — Voice Work). Phase 56 voice-tuned the conversational engagement creation surface Phase 55 shipped — additive coverage-expansion of per-field elicitation prompts, plain-terms-discipline applied across the surface, persona-transcript calibration discipline established. Section 1 receives one substantive in-place update: §1.1 (Engagement creation assistance pattern) current-state extends to note the voice-discipline now applied to the surface (plain-terms-discipline; per-field elicitation coverage of voice / constraints / success fields; persona-transcript calibration). Section 6 receives one new entry: §6.4 (NEW — Explain affordance for Companion comprehension recovery) carrying the three candidate phase shapes from loomworks-explain-affordance-investigation-v0_1.md (button-mode-first / wait-for-voice-modality / audible-first-via-lightweight-substrate); selection deferred to post-Phase-32 calibration evidence; positioned in Section 6 because its substrate adjacency to mobile presence + quick-capture (voice modality overlaps in audible mode) outweighs adjacency to engagement creation arc (Phase 32 only generates the calibration evidence, doesn't drive the substrate). The new entry preserves the trajectory note that the affordance was discovered through the Phase 56 scoping arc as the recovery surface for the discipline-plus-recovery principle (named in manifest v0.41 §2 as a v0.21 candidate). Section 2 receives one current-state extension: §2.2 (Phase 32 marketing engagement) status unchanged at "newly first-class actionable" but now carries Phase 56-tuned surface as input — the marketing engagement creation now has voice-discipline polish to surface real-use comprehension-gap evidence. Phase 56 voice work itself closed — the option from manifest v0.40 §4 carry-forward that became Phase 56 is removed from carry-forward (was not in this document's numbered sections; closure recorded in changelog only). The five methodology contributions Phase 56 surfaced (two promotions to named principles — branch-and-tag-name-collision refspec convention, Step 0 branch lifecycle; three v0.21 candidates — discipline-plus-recovery, gap-diagnosis-precedes-gap-implementation, dialog-example-as-scoping-instrument sharpening; plus the minor instruction-refinement-during-absorption extension) live in manifest v0.41 §2, not in this document. Three Operator decisions captured in v0.11: filing the explain-affordance entry under Section 6 (substrate adjacency outweighs engagement-creation-arc adjacency); preserving discovery trajectory in §6.4 of why the affordance was scoped (the discipline-plus-recovery principle's first instance); the queued directions document continues to hold queued future directions while the manifest holds named principles (Phase 56's promotions stay in manifest v0.41 §2, not surfaced here as queued).
Purpose. Queued future directions and deferred work that don't need to load into every fresh chat but should be retrievable when the relevant topic comes up. Foundational fresh-chat orientation stays in memory; topical futures live here.
Discoverability keywords. engagement creation assistance, Discovery-to-seed, blank-page problem, code health audit, semantic duplication, Phase 30 induction, Phase 32 marketing, deferred phases, external rendering services, render specialist SDK, Novi AI, Steve AI, Story.com, image generation, Goosey, Nano Banana, Gemini Flash Image, storybook art, upload facility extension, file type extensibility, contribution skill, metadata-driven runtime, configuration-extensible, code-extensible, multi-stage extraction, multi-output extraction, non-text assertions, assertion content kind, Claude Dreaming, AutoDream, agent memory consolidation, memory hygiene, cross-engagement pattern detection, observation to Shape, Accounting reconciliation, Claude Managed Agents, outcomes, grader agent, multi-agent orchestration, lead and sub-specialist composition, sessions and webhooks, agent fabric, agent capability development, quick-capture, dictation, mobile presence, Hey Companion, Hey Freda, App Intents, App Actions, Siri Shortcut, foreground listener, Picovoice Porcupine, wake word, watch complication, tap-to-speak, share sheet, parking, parked on level 10, voice register family, single-valued slot, multi-valued slot, temporal coherence, supersession, held layer, Companion-noticed retraction, asynchronous commit window, name-agnostic router, Operator Layer mobile, federation, offline queue, mobile engineering capacity, multi-instance fleet, DevOps engagement, control plane, Authority instance, Instance A, Instance B, Instance C, Instance D, Hetzner, Railway, AWS, Cloudflare Pages, fleet management, cross-instance traffic, email registry, abuse boundary, grant flow, public marketing website, credit request form, jurisdiction governance, GDPR, EU data residency, Schrems II, data sovereignty, regulatory framework, retention policy, white-label, managed hosting, product tier, protocol triangle, Loom remembers, FORAY proves, OVA scopes, prove data never left, external information seams, external API gateway, general-purpose API specialist, public-apis catalog, github.com/public-apis, REST API integration, FORAY-attested external calls, OVA-scoped credentials, API gateway tiers, API-key auth, OAuth pagination, response transformation, semantic mapping across services, declarative API configuration, API specifications as Memory, build-once-configure pattern, ship-N-adapters reframe, weather API, FX rate API, holiday API, geocoding API, current-state-from-external-services, ambient context, Companion ambient awareness, Operator current state, environmental relevance, what time is it, ambient-context decomposition, Memory-lookup plus engine-clock, Memory-lookup plus external-seam, time-zone awareness, calendar awareness, location awareness, schedule awareness, world-state-relative-to-Operator, proactive surfacing, relevance bridge, more-than-Siri, Siri comparison, standing posture, current-state model, ambient questions, situational awareness, leave-for-meeting, traffic-aware reminder, weather-aware suggestion, daypart-aware response, awake-or-asleep, workday vs weekend, holiday awareness, ambient as supplied domain, standing Companion, engaged Companion, Operator-bound mode, engagement-bound mode, Companion posture, standing Memory, Memory scope above personal engagement, Operator-scope assertions, executive assistant analogy, attendant Companion, cross-engagement awareness, watch-for-this requests, Operator-declared proactivity, proactive scope, threshold of utility, do-not-disturb scope, mode handoff, standing-to-engaged context bridge, engaged-to-standing observation upload, what's in the Operator's mind, continuous attendance, principal-attendant relationship, is this an engagement, Observer, cross-fleet observation, fleet-wide observation, content-vs-shape boundary, shape-only observation, content-blind by construction, event emission with redaction, meta-engagement, observation engagement, UX friction surfacing, methodology drift detection, token-use optimization, cost-per-operation, capacity signal, onboarding friction, Companion behavior calibration, intent-classification confidence gap, proactive-surfacing relevance miss, anonymized cohort view, identifiable view, opt-in observation, two-view architecture, Operator consent for identifiable observation, DUNIN7-facing engagement, view layer over shape Memory, Observer is not surveillance, Observer is not FORAY, Observer is not the Operator dashboard, Observer is not the standing Companion, what Observer is not, methodology validation feedstock, cross-Operator pattern surfacing, aggregate pattern observation, structural defensibility, structural vs filtering, filtering-based defensibility, model-layer filtering, illegal use, AI harm framing, render boundary, render boundary frame, protocol triangle for harm prevention, rules in Memory, upstream enforcement, mechanical attestation, jailbreak resistance, rules-not-filters, considered work versus consequential commitment, four-room separation, architecturally impossible harms, detection as fallback, audit-trail completeness, regulatory positioning, compliance investigation substrate, governance as substrate concern, conversational engagement creation, terminal-turn affordance, write-up-as-Discovery-record, commit-as-brief, EngagementCreatedFromAssistance, /me/engagements/create-from-conversation, /operator/create-engagement, mode banner, engagement creation arc product loop closed, multi-path unification verdict, Phase 31 deprecation candidate, Phase 53 deprecation candidate, halt-surface refactor residue, split-draft_engagement, raw-Markdown extract variant, Phase 32 first-class actionable, inherit prior-phase cost decisions, Operator-probe-as-correction-mechanism, build-time enumeration aperture, build-close hygiene branch deletion, tag style annotated, CR-execution boundary first firing, third instance of substrate-evidence-can-re-rationalize-selection, six consecutive phases unconsumed reserved slots, Phase 56 candidate, Option C render specialists alternate, plain-terms-discipline, discipline-plus-recovery, gap-diagnosis-precedes-gap-implementation, dialog-example-as-scoping-instrument, voice principles document, per-field elicitation prompts, persona-transcript calibration, calibration-gated tests, LOOMWORKS_RUN_CALIBRATION, forward-looking persona discipline, explain affordance, comprehension recovery, comprehension-residue, voice modality, button-mode-first, wait-for-voice-modality, audible-first-via-lightweight-substrate, hybrid voice composition, speech-to-text, wake-word push-to-talk, refined close protocol, local-and-remote branch deletion, branch-and-tag-name-collision, refspec convention, refs/heads explicit, refs/tags explicit, Step 0 branch lifecycle, instruction-refinement-during-absorption, recursive-verification-discipline extension, Phase 56 voice work closed, Phase 57 candidate, fourth instance substrate-evidence-can-re-rationalize-selection, seventh consecutive phase unconsumed reserved slots, seven consecutive zero-amendment phases, Phase 31 create_project plain-terms residue, 22 voice templates outside creation flow.
Each entry below carries four slots:
Entries are organized topically, not chronologically. New queued directions arriving in future conversations should be added under the right section (or a new section) with the same four-slot structure.
The two entries in this section are complementary parts of the same arc: assistance during Discovery (helping an Operator reach the point of having a Discovery record), then transformation of the Discovery record into a candidate seed.
Trigger. Any conversation about how a new Operator gets started; the blank-page problem; conversational creation of an engagement; Operator Layer Arc 2 (Companion brain) discussions touching engagement onboarding; the Operator-supplied vs Operator-elicited information distinction; or an actual instance of Claude helping an Operator articulate a new engagement (e.g. the marketing engagement creation that prompted this entry).
Substance. The process of soliciting information from an Operator to build a seed and its six fields is itself a product capability, not just a thing Claude does for Marvin in chat. Every new Operator faces the blank-page problem: they have a domain, they have intentions, they have material in their head — but they don't have it in the form a candidate seed needs. The assistance Claude provides to help Marvin create new engagements is the template for what the Loomworks product should offer built-in to every new Operator.
Current state. Delivered at Phase 55 (2026-05-11). The conversational engagement creation surface is live. An Operator visits /operator/create-engagement (Operator Layer; 12th prerendered route), talks to the Companion through a dedicated mode (mode banner attaches at top; three prompt template components govern the flow's tone, gap-marker discipline, and terminal-turn affordance language), and at terminal turn picks one of two output paths via the terminal-turn affordance: (a) write up as Discovery record — Companion produces structured Discovery markdown, uploads via Phase 16's pipeline, and delegates extraction to Phase 53's extract_discovery_to_seed_skill; (b) commit as brief — Companion authors brief, _allocate_candidate_engagement helper allocates the engagement, draft_seed / induct_seed produce and induct the candidate. The Companion creates the engagement and routes the Operator to it. Substrate-side: POST /me/engagements/create-from-conversation endpoint; EngagementCreatedFromAssistance Memory event class with _ANCHOR_PRIORITY entry at "standard" (FORAY-anchored); three new IntentLabel literals; conversation turns stored in the Phase 42 relational table (per the V7 reshape's inheritance of Phase 42's cost decision); terminal-commit Memory event written on commit-as-brief and on Discovery-record commit alike. Conversational flow handler tested via 45 new substrate tests + 10 new OL vitest at Phase 55 close. Voice-tuned at Phase 56 (2026-05-12). The conversational surface now applies plain-terms-discipline to its product-surface voice (no methodology nouns leak through to the Operator; vocabulary is on the page, not in code). Three per-field elicitation prompts authored in plain language from the start cover voice / constraints / success fields (Phase 55's surface elicited Fields 1–2 cleanly; Fields 3–5 were not elicited at all — the additive coverage-expansion landed at Phase 56 per the v0.1 → v0.2 reshape of the scoping arc). A new load_per_field_components(stage) loader at prompt_assets.py and dispatcher splice at prompt.py:817 read operation_data["field_coverage"] (a map populated by the active-template Companion-judgement) and splice in one missing-field component at a time (break-after-first preserves one-question-at-a-time conversation discipline). The matcher token-set extension at router.py recognizes both legacy and plain-terms terminal-turn phrasings. Persona-transcript calibration fixtures at tests/fixtures/voice-calibration/ plus test helper at tests/helpers/voice_calibration.py provide the calibration surface; tests gated on LOOMWORKS_RUN_CALIBRATION=1 per P56-D7 (skip in CI; pass locally with env var set). The OL banner string revised in-place at ChatView.tsx:254. The Phase 56 close handoff names the voice principles document (docs/voice-principles-v0_1.md in the engine repo, 146 lines) as the methodology-grade authoring deliverable governing this discipline plus framing the discipline-plus-recovery principle whose first recovery affordance (the explain affordance, §6.4 below) is Phase 57+ candidate work.
Trajectory. Originally framed as "Claude does this for Marvin in chats" — a manual operator-side activity. Reframed (pre-Phase-53) as "this is itself a product capability" because every Operator who ever uses Loomworks will face the same problem and the manual chat process is the prototype for the in-product assistance. The reframe matters because it changed what was worth capturing during Discovery sessions: not just the output (the Discovery document), but the process (the sequence of questions and elicitations). Phase 53 (2026-05-10) shipped the substrate primitive (Discovery-to-seed skill). Phase 54 (2026-05-10) established terminal commit symmetry (both extraction paths reach induct_seed). Phase 55 (2026-05-11) shipped the upstream conversational surface closing the arc's product loop end-to-end — Operator can now create a new engagement entirely through dialogue with the Companion. Methodology trace from Phase 55 V7. The v0.1 → v0.2 scoping reshape on storage-mechanism (Memory-event-for-turns → relational-for-turns, inheriting Phase 42's cost decision) is methodologically preserved as the surfacing event for the now-named principle inherit prior-phase cost decisions; don't re-litigate (manifest v0.40 §2). The Operator's two-question probe — "which scales?" / "how about cost?" — drove the reshape; carries to v0.21 as the Operator-probe-as-correction-mechanism candidate (single instance to date; awaiting amplification). The higher-level Option A selection held through the reshape — third instance of substrate-evidence-can-re-rationalize-selection. Methodology trace from Phase 56 scoping arc. Phase 56's v0.1 → v0.2 → v0.3 trajectory adds three more methodology surfacings to this entry's trajectory record. v0.1 diagnosed vocabulary leak through a dialog-example reshape ("the Operator will not understand"); v0.2 Step 0 evidence reframed the gap as coverage expansion (Fields 3–5 not elicited; existing prompts already used plain-language wrappers); v0.3 named the comprehension-residue gap and the discipline-plus-recovery recovery surface (the explain affordance — §6.4). Three new candidates for v0.21 surfaced: gap-diagnosis-precedes-gap-implementation (Step 0 verifies the shape of the gap, not only the touch surface); dialog-example-as-scoping-instrument (sharpening — dialog examples are productive-when-wrong-enough-to-probe); discipline-plus-recovery (any UX discipline reducing an incidence rate needs a recovery affordance for the irreducible residue). The v0.1 → v0.2 work-category shift (revisional → additive) while higher-level selection held is the fourth instance of substrate-evidence-can-re-rationalize-selection (after Phase 54, Phase 53, Phase 55); frequency at four instances strongly supports manifest v0.40 §2's "load-bearing principle" framing. The Phase 56 close also surfaced two operational principles now promoted to named principles in manifest v0.41 §2: branch-and-tag-name-collision refspec convention; Step 0 branch lifecycle.
Trigger. Any conversation about transforming a Discovery document into a candidate seed; bridging Discovery to engagement creation; the seed-induction loop; or the gap between "Operator has talked through what their engagement is" and "engagement exists in Loomworks with seed v0.1 ready for induction."
Substance. A skill (in the Loomworks sense — bounded structural transformation, no registered actor, no instruction set) that creates a candidate seed conforming to R-A5 through R-A11 from a Discovery document landed in Memory. The skill takes the Discovery record as input and produces a draft seed with the six fields filled in. The candidate seed then enters the seed-induction loop normally, where any gaps or ambiguities surface as findings the Operator addresses.
Current state. Delivered at Phase 53 (2026-05-10). Reached through two production paths since Phase 55 (2026-05-11): (a) the original direct upload-driven path (Operator uploads a Markdown Discovery document via Phase 16; extraction triggers at /engagements/{eid}/seed/extract); (b) Phase 55's Discovery-record output path (Operator articulates the engagement through dialogue at /operator/create-engagement; at terminal turn, Companion writes the Discovery markdown; same Phase 16 upload + Phase 53 extraction pipeline runs). induct_seed production callers: 5 at Phase 55 close (Phase 53's direct extraction path + Phase 54's brief-commit wrapper + Phase 55's brief-commit terminal path + two prior callers). The skill is bounded-contract (single-shot LLM call wrapped by strict input/output contract; gap markers preferred over fabrication; manifest v0.38 §2 principle).
Trajectory. Originally considered building this as an agent (LLM call with prompt). Set aside in favor of the skill framing because (a) the transformation is bounded — there's a known input shape and a known output shape, (b) an agent's flexibility is not what's needed; the value is precisely the constraint, (c) the skill pattern composes with the rest of Loomworks (extraction skills, materializer registry, etc.) and an agent here would be the only agent in the upload-side pipeline. Phase 53 P53-D1 settled a related tension: queued-directions §1.2's "bounded skill" framing initially implied no-LLM; the live design required real interpretation work to map heterogeneous Discovery shapes onto R-A5–R-A11. The discipline that survived crystallization was bounded contract, not no-LLM (manifest v0.38 §2). Phase 55's Discovery-record path consumes the skill exactly through its bounded contract surface; the contract held under second-caller pressure.
Trigger. Any conversation about refactoring draft_engagement or extract_discovery_to_seed_skill; about the Phase 55 Step 3 halt-surface and what it leaves behind; about why Phase 55's terminal-commit orchestration inlines helpers rather than composing function calls; about whether the engagement-allocation half of draft_engagement should be callable separately from the Seed-drafting half; about whether the Discovery-record path needs to consume Phase 53's skill through raw Markdown rather than through Phase 16 upload helpers; or any future scoping that touches the engagement creation arc's substrate decomposition.
Substance. Phase 55 Step 3 produced a halt-surface event (docs/phase-impl-notes/phase-55-halt-surface-2026-05-11-step-3-cr-5_4-orchestration-v0_1.md, engine repo) when CR §5.4's 8-step orchestration for the terminal-commit endpoint surfaced internal inconsistency during implementation: the brief path called draft_engagement (which creates a Seed) followed by _call_seed_commit_from_brief (which expects to read a Phase 31 Memory event to retrieve the Seed — but Phase 55 stores conversation turns in the Phase 42 relational table, not as Phase 31 Memory events). Two failure modes compounded: either the first Seed gets orphaned, or the second call reads a Memory event Phase 55 never wrote. Note-first-discipline per the CR-execution boundary of friction-discipline-pattern-family (manifest v0.39 §2); in-session resolution preserved the build/draft separation. Two substrate refactor candidates remain as carry-forwards:
draft_engagement into engagement-allocation and Seed-drafting halves. The two halves were fused in earlier phases (Phase 31 and Phase 25 era); Phase 55 had to inline-replicate the split as a new _allocate_candidate_engagement helper plus separate draft_seed / induct_seed calls. The proper refactor decomposes draft_engagement so the engagement-allocation half can be called separately from the Seed-drafting half, eliminating the inline-replication. Phase 56+ candidate; non-urgent since the inline-replication works.extract_discovery_to_seed_skill. Phase 55's Discovery-record output path inlines engagement-allocation plus Phase 16 upload helpers plus delegates to Phase 53's extract wrapper. A raw-Markdown entry-point variant (extract_discovery_to_seed_skill_from_markdown or similar) would let the Discovery-record path skip the Phase 16 upload helpers (which were designed for Operator-driven file upload, not Companion-authored Markdown). Phase 56+ candidate; non-urgent since the inline-replication works.Current state. Both candidates are non-urgent residues from a working substrate. Neither blocks any current capability; both would reduce the substrate's inline-replication count and tighten the engagement-creation-arc orchestration layer. Worth recording because Phase 55 Step 3's halt-surface specifically generated them, and because future engagement-creation-arc scoping should consider whether either refactor lands well alongside that scoping's primary work.
Trajectory. The halt-surface itself is the load-bearing artifact — it caught a CR-orchestration internal inconsistency before build-time error compounded, demonstrating the first active firing of the CR-execution boundary in production (manifest v0.40 §2 records this as the first-firing event of the friction-discipline-pattern-family CR-execution boundary). The two refactor candidates are themselves valuable, but their generation — through the friction-discipline-pattern-family's halt-and-surface mechanism — is what makes the trajectory worth preserving. Future halt-surface events that generate substrate refactor candidates should be filed here (or in a sibling section) alongside their generative halt-surface document.
Trigger. Any conversation about whether Phase 31 (the original conversational-creation path that produced briefs) and Phase 53 (the Discovery-to-seed extraction skill) should be unified; about whether one of the two paths should be deprecated; about how the engagement creation arc's multi-path architecture should evolve now that both paths are production-shaped; about whether induct_seed's multi-caller surface should be tightened; or any clarification-scoping for Phase 56+ that touches the engagement-creation-arc terminal symmetry.
Substance. Phase 53 introduced the Discovery-to-seed extraction skill as the engagement creation arc's substrate primitive. Phase 31 (the original conversational creation path) and Phase 53 (the new extraction skill) both produce candidate seeds that reach induct_seed; Phase 54 established terminal commit symmetry between them. Phase 55 demonstrated the multi-path is product-shaped end-to-end — an Operator can reach induct_seed via Phase 31's brief-commit terminal path, Phase 53's direct upload-driven path, or Phase 55's two terminal-turn output paths (each of which routes to one of the prior two). The unification question — should the multi-path stay multi-path indefinitely, or should one path deprecate the other? — was filed as a Phase 53 CR §18.1 carry-forward item; Phase 54 closed item 4 (Phase 31 induct-seed gap clarification per P53-D11) but did not resolve unification. Phase 55 closure makes the verdict newly verdict-able with full end-to-end evidence: both paths now have product surfaces; both routinely produce seeds; both flow through induct_seed cleanly. The verdict has three candidate answers:
Current state. Verdict pending. Phase 56+ candidate for clarification-scoping (similar shape to Phase 54's three-answer clarification scoping on Phase 31's induct-seed gap). The clarification scoping would surface evidence for each answer and let the Operator articulate the right one. Substrate work depends on the verdict: Answer A is zero substrate work; Answer B is moderate substrate work (deprecate Phase 31's brief-commit terminal turn; carry the Companion to Phase 53's path through Phase 55's surface); Answer C is substantial substrate work (less plausible).
Trajectory. Filed at Phase 53 CR §18.1 as a deferred-verdict item; Phase 54 closed an adjacent item (Phase 31 induct-seed gap clarification — Answer C / C3 settled). The clarification-scoping shape Phase 54 used (three-answer space, surfaced evidence, Operator articulates) is the precedent for the unification clarification scoping. The methodology candidate clarification-scoping discipline (manifest v0.39 §2's scoping-time boundary of the friction-discipline-pattern-family) names the discipline this Phase 56+ scoping would inherit. The verdict is not architecturally forced — Phase 55 shows the multi-path is working — but it is methodologically worth resolving so that future scoping doesn't carry the open question forward indefinitely.
These are phases that are scoped well enough to draft CRs against but explicitly held back. They will resume when their preconditions are met or when Marvin asks to revisit.
Trigger. Any conversation about Enrollium, ExpenseDesk, or FarmGuard entering Loomworks; about how the three pre-existing engagements get on-boarded; about deriving seeds from prior REQ-format material; or about the one-off induction solution that lives separately from Loomworks itself.
Substance. The three existing engagements (Enrollium, ExpenseDesk, FarmGuard) need to enter Loomworks. They have prior material — REQ-format requirements specifications, conversational history, specification artifacts — that should drive their seed creation. The induction solution is a one-off: it derives seeds from prior material rather than from Discovery sessions, and it lives outside Loomworks (it's a migration tool, not a Loomworks feature).
Current state. Deferred until Marvin asks to revisit. Not blocking any current work. The architectural separation (induction solution is not part of Loomworks) is settled; what remains is execution.
Trigger. Any conversation about creating the Loomworks marketing engagement; about practicing the conversational engagement creation pattern (Section 1.1) on a real engagement; about marketing content authored through the methodology; about Loomworks marketing in general.
Substance. Create a Loomworks marketing engagement through the conversational creation process. This is both (a) the marketing engagement itself (real product output) and (b) the first practice of the engagement-creation-assistance pattern on a non-trivial engagement, captured as the prototype for the in-product Discovery assistance feature.
Current state. Newly first-class actionable since Phase 55 close (2026-05-11); voice-tuned input surface since Phase 56 close (2026-05-12). Phase 55's conversational engagement creation surface (§1.1 delivered) provides the prerequisite product surface; Phase 56 applied voice-discipline polish to that surface (plain-terms-discipline; per-field elicitation coverage for voice / constraints / success Fields 3–5; persona-transcript calibration). Phase 32 remains the natural first real application — and the canonical real-Operator-evidence input for the explain-affordance candidate selection (§6.4). The loomworks-marketing-creation-flow-content-v0_3.md and related drafts hold the working material from earlier sessions — Phase 32 has substantial pre-work already done. Per the Phase 55 close-session handoff §9 (reaffirmed by the Phase 56 close handoff §9), Phase 32 is the recommended (but not binding) Phase 57 candidate — reasoning carries from v0.10 with one Phase 56-specific addition: the marketing engagement creation now has voice-discipline polish to surface real-use comprehension-gap evidence that informs the explain-affordance selection. Alternate Phase 57 candidates are Option C — Discovery-trajectory + Discovery-record render specialists (rendering-layer counterpart to §1.1; still strong) — and §6.4 explain affordance (button-mode-first or audible-first; less likely as first-line given Phase 32's now-ready posture, but defensible). Any of the three is defensible; Phase 57 scoping decides.
Trajectory. Held deferred through Phases 47–55 while the credit/form-flow/marketing arc and then the engagement creation arc were prioritized. Phase 53 opened the engagement creation arc (substrate primitive); Phase 54 established terminal symmetry; Phase 55 shipped the upstream conversational surface that Phase 32 now consumes. The substrate dependency chain (Phase 53 → 54 → 55 → 32) was fully visible at v0.8 / v0.9 absorption; Phase 32's "newly first-class actionable" status at v0.10 absorption is the explicit recognition that its prerequisites are now all shipped. The recommendation is preserved as not-binding because Phase 56 scoping may surface evidence that Option C (render specialists) compounds more value at this point, or that some other queued direction becomes load-bearing.
Trigger. Any conversation about codebase consolidation, semantic duplication, shared utilities, refactoring, or "is the codebase getting messy"; or any concrete observation of duplicated logic across components; or whenever the current bug-fix wave stabilizes and a consolidation phase becomes natural.
Substance. A lightweight consolidation phase similar to Phase 24. Scan the codebase for semantic duplication — repeated business logic across components, similar helper functions in multiple files, parallel implementations of the same pattern. Extract shared utilities. Establish conventions to prevent future duplication. This is maintenance work, not feature work; the goal is to reduce the cost of every subsequent build phase rather than to deliver new capability.
Current state. Scheduled after the current bug-fix wave stabilizes. Not blocking any current work. Worth doing eventually because semantic duplication compounds — a duplication tolerated for one phase becomes three duplications tolerated for the next phase, and so on.
These two entries cover Render-side work that depends on engine phases not yet shipped.
Trigger. Any conversation about Novi AI, Steve AI, Story.com, or other external rendering services; about integrating LLM-as-a-service render providers; about the render specialist pattern; about post-Phase-D adapter work; or about the question "how does Loomworks render content via external services."
Substance. External rendering services (video, animation, complex generated content) integrate as render specialists, not as enumerated built-in integrations. The pattern: a specialist SDK that providers (or the Operator on their behalf) implement against; rendering rules that carry service-specific parameters; the existing render-specialist registry mechanism dispatches by render type to the right specialist. The specialist pattern is the integration surface — extensibility-first.
Current state. Prerequisites for this are now partly shipped: Phase 34 (external-service polling for specialists) landed; Phase 35 (render content kinds — binary blob, external reference, multi-file) is the next engine phase and brings binary content support. After Phase 35, the substrate carries what's needed to support specialists that produce binary or external-referenced content. The specialist SDK design itself is post-Phase-D adapter work.
Trajectory. Originally considered building enumerated integrations (one for Novi, one for Steve, one for Story.com) similar to how API integrations sometimes get built. Set aside in favor of the specialist SDK pattern because (a) the rate of new external services arriving is high and growing, (b) enumerated integrations would force engine releases for every new provider, (c) the specialist pattern already works for the existing render side and composes naturally.
Trigger. Render comes up in a Goosey context (specifically: post-Phase-D adapter work; depends on engine Phases 35 and 38); or any conversation about children's storybook art generation; or any other engagement that needs character-consistent illustrated content; or general image-generation cost/quality assessment.
Substance. Operator wants help identifying a cost-effective image-generation solution for Goosey storybook art and similar children's storybook engagements. Key requirements: character consistency across pages (the moose should look like the same moose in scene 1 and scene 12), ability to refine conversationally (the workflow is iterative — first draft is rarely final), reasonable cost per image (storybooks have many pages; per-image cost compounds).
Current state. Initial assessment 2026-05-04: Nano Banana 2 (Gemini 3.1 Flash Image) likely fits — character consistency across pages is a stated capability, conversational refinement is a stated capability, cost is in the $0.02–0.15/image range. Worth comparing against Midjourney, Flux, DALL-E successors at decision time; the field moves fast and the assessment will be stale within months.
Trajectory. Image generation has been on the radar since Goosey's first storybook render in early 2026 but was deferred because the substrate couldn't carry binary content. With Phase 35 in flight, the substrate constraint is being removed and the image-generation question becomes near-term. The Nano Banana 2 assessment is intended as a starting point for the actual evaluation, not a recommendation.
This section is more substantial than the others because the underlying conversation covered more ground. Three sub-sections: what's already extensible and how, three categories of future data type that don't fit the current shape, and the metadata-driven runtime as a future direction.
The current upload facility (Phase 16 amendments) is code-extensible. Adding a new file type is:
ExtractionSkill protocol (async def __call__(*, file_path, engagement_id, db) -> ExtractionResult).registry.register("image/", describe_image_skill, label=..., mode=...)).This is not zero-code-change extensibility, but it's small-code-change extensibility. The contribution endpoint, the frontend's mode-button logic, and the supported-types discovery all work without modification — a new file type adds one Python file, one registration line, and (sometimes) one dependency. The architecture is set up to make per-file-type cost low.
This handles every variation of existing categories cleanly: new audio formats, new image formats, new document formats, spreadsheet contents flattened to text, code files, email files. The ExtractionSkillRegistry's content-type-keyed dispatch is the right shape for these.
These are categories where "file → text → assertion" doesn't fit cleanly. Each one is real future work; each one has a known architectural response.
Category 1 — Multi-stage extraction (file → intermediate → text). Some data types need intermediate processing before text extraction makes sense: a video file needs frame extraction → per-frame Vision description → assembled narrative; a long audio recording needs speaker diarization → per-speaker transcription → structured transcript; a 3D model file needs orthographic projection → vision-based description; a compressed archive needs enumeration → recursive extraction of each member. Today's ExtractionSkill protocol can technically handle these (a video skill could do all the intermediate work inside its __call__), but the per-call duration goes from "seconds" to "many minutes," which the synchronous contribution endpoint can't accommodate. Architectural response: apply Phase 34's external-service polling pattern. Extend ExtractionSkill to optionally return a handle (ExtractionInProgress) the way RenderSpecialist now optionally returns ExternalProductionHandle; the contribution endpoint surfaces a "processing" state; a polling loop drives completion. This is real work but a known pattern.
Category 2 — Multi-output extraction (file → many assertions). The current architecture commits each contribution to a single assertion. Some data types naturally produce many: a long meeting transcript should yield one assertion per topic, not one massive assertion; a spreadsheet of measurements should yield one assertion per row; an email thread should yield one assertion per message; a multi-page PDF where each page is a distinct topic should yield one assertion per page. Today the skill returns ExtractionResult.text: str (singular), and the user gets one held assertion. The cleanest extension: ExtractionResult becomes list[ExtractionResult] (or the protocol gains an extract_many variant); the contribution endpoint creates N held assertions, each with its own slice of provenance metadata pointing back to the same source file; the frontend (already capable of displaying multiple held assertions per Phase 17's redirect work) handles the UI side without change. Architectural response: small CR extending ExtractionResult to support a list, plus the endpoint create-loop.
Category 3 — Non-text-shaped knowledge. Some knowledge isn't usefully shaped as text. A photograph as evidence (the assertion is the image, not "this image shows X"); a spreadsheet of structured data (the assertion is the data); a recorded conversation where audio carries information transcription would lose; a diagram where structure matters. This is the deepest strain, because the methodology assumes assertions are propositions in language. Two viable directions:
text | structured | image | audio with a discriminator, conceptually parallel to what Phase 35 just did for RenderEvent (added content_kind discriminator with multiple storage shapes). The same pattern would apply to Assertion: assertion_kind: Literal["text", "image", "audio", "structured"] plus appropriate storage fields. This is bigger work — touches the assertion model, the four rooms (which all consume assertions), the methodology document (which currently treats assertions as propositions), and operator surfaces. Not a near-term lift. But it's the architecturally honest answer for true non-text knowledge.Direction A handles every case that's actually arrived. Direction B is queued for whenever non-text knowledge becomes a real engagement requirement.
Architectural asymmetry worth noting. The upload boundary (the contribution endpoint and the registry) is well-shaped for extension. The downstream consumers (Manifestation, Shaping, Render) currently assume text-shaped assertions. If non-text knowledge becomes important, the bigger work isn't extending upload — it's extending what comes downstream. Direction B's full cost is at the consumer side, not the producer side.
Trigger. Any conversation about whether the upload facility can be extended without modifying the codebase; about Operator-defined extraction; about plugin systems for Loomworks; about cross-surface DSLs (extraction, rendering, shaping all describable in the same metadata language); about the gap between "code-extensible" and "configuration-extensible"; about how a non-developer Operator could add a new file type.
Substance. A metadata-driven runtime would replace today's code-extensible pattern (write a Python skill, register it) with a configuration-extensible pattern (author a data record describing the extraction; a runtime interpreter executes it; new file types added without writing Python). Three layers exist within this direction:
audio/, send the bytes to this URL with this auth shape, parse this JSONPath out of the response, treat the result as the assertion text." Pure configuration. The runtime needs to know HTTP, a few auth patterns, JSONPath. This is how n8n, Zapier, and many ETL tools handle integrations. Within a category (transcription, OCR, document extraction), swapping providers becomes config; new providers are config records, not code.Three trigger conditions justify reaching for a metadata-driven runtime (any one of which would make the build worth it):
Current state. Not built. Today's code-extensible pattern is right-sized for current loads, current Operator model (one Operator + Claude, not many self-serving Operators), and current new-skill arrival rate. The path is well-understood; the build is queued, not pursued.
Trajectory (load-bearing). This is the entry where preserving the conversational trajectory matters most.
The first response in the conversation called the metadata-driven runtime "wrong-shaped for the product" — a permanent judgment, implying the door was closed. Marvin pushed back: "But does the extensibility accommodate new file types without modifying the code base?" — surfacing that the original answer had been too quick to dismiss. The corrected framing was "premature given today's loads" — a queued judgment, implying the door is open and the conditions for opening it just haven't arrived.
The distinction matters because:
The error in the first response was treating a current-state cost-benefit judgment as if it were a permanent architectural judgment. The two are different things, and conflating them is the kind of mistake that closes doors that didn't need to be closed.
The corrected position: the metadata-driven runtime is the right architecture for a future Loomworks where Operators define their own extraction, where the new-skill rate is high, and where the same runtime composes across multiple surfaces. None of those conditions bind today. All of them are plausible in the medium term. Reach for it when at least one of them starts to bind, not before.
The two entries in this section emerged from the Phase 47 scoping arc (2026-05-07) when external-platform agent developments at Anthropic — Claude Dreaming and the broader Managed Agents primitives — surfaced as relevant to Loomworks' Companion and specialist trajectory. Neither is Loomworks-native; both are external work that maps usefully onto Loomworks elements. Captured here so the mapping survives across sessions and so the relevant Loomworks attachment points are explicit.
Trigger. Any conversation about agent memory consolidation; about pruning, merging, or reorganizing accumulated knowledge; about "is the engagement Memory getting messy" or similar concerns about long-running engagements accumulating low-signal assertions; about Claude Dreaming, AutoDream, or /dream (the Claude Code variant); about cross-session pattern detection; about whether the Companion should observe and act on patterns across an engagement's history; about Accounting engagement reconciliation as a recurring evaluator task; about observation-to-Shape transitions where accumulated Memory becomes a structured specification proposal; about whether Loomworks should incorporate dreaming-style behaviors as agent capabilities mature.
Substance. Anthropic shipped Claude Dreaming for Managed Agents in research preview on 2026-05-06: a scheduled process that reviews past sessions and memory stores, extracts patterns, prunes stale entries, merges duplicates, and resolves contradictions. In Claude Code specifically, Auto Dream consolidates CLAUDE.md and MEMORY.md files between sessions. The capability addresses a real problem: as agent memory accumulates, it becomes redundant, contradictory, and stale; the agent's effective context degrades.
The same problem applies to Loomworks engagement Memory at scale. As an engagement runs over months, assertions accumulate. Some become redundant (different assertions saying overlapping things). Some contradict newer assertions. Some become stale. The Companion's context window fills with low-signal material.
The governance model is what differs. Claude Dreaming modifies memory autonomously by default (with optional human review). Loomworks is built on Operator authority — the machine surfaces and signals, the Operator approves. Autonomous memory modification is a category error in Loomworks. Loom Protocol's no-erasure guarantee is structural.
The Loomworks-native version of dreaming routes through the engagement pipeline. The Companion proactively reviews Memory and proposes consolidations or retractions. "Assertions #12 and #23 say overlapping things — want me to retract #12 and amend #23 to cover both?" That proposal enters Shaping. The Operator approves. The retraction is FORAY-attested. The provenance survives.
Specific applications across Loomworks:
Current state. The infrastructure exists. Phase 44 trigger evaluator + proactive observation pathway + four-room pipeline give the Companion everything it needs to "dream" — the missing pieces are specific evaluator implementations and prompt instructions for each application above. None are urgent today. They become valuable when:
Trajectory. Originally framed as "should Loomworks adopt dreaming?" The corrected framing: dreaming is not a capability to adopt — it's a use case for capabilities Loomworks already has. The substantive question is which evaluator tasks and prompt instructions to build, not whether to graft external machinery onto the substrate. The methodology and governance differences (autonomous vs. pipeline-governed) are what they are; they're not in tension because Loomworks isn't trying to compete with Managed Agents on agent infrastructure — they're at different altitudes.
The relationship: Anthropic is publicly working out the conceptual primitives for long-running agent memory. Loomworks borrows the vocabulary (consolidation, hygiene, pattern extraction) and applies it through Loomworks' governance model. The borrowing is honest because both are addressing the same underlying reality.
Trigger. Any conversation about agent infrastructure platforms; about Anthropic's Managed Agents service; about lead/sub-agent orchestration patterns; about grader agents or outcome-based evaluation; about session lifecycle, vault credentials, or webhooks for agent platforms; about whether the Companion should be implemented on Managed Agents or on Loomworks' own substrate; about specialist composition extending to multi-agent decomposition; about how external systems should subscribe to engagement lifecycle events (post-Arc-2 external connectors); about render review or quality assessment for composed Render outputs; about the relationship between Loomworks-as-methodology and external agent platforms.
Substance. Anthropic's Managed Agents (GA April 2026; expanded 2026-05-06 with Outcomes, multi-agent orchestration, and webhooks alongside the Dreaming research preview) is a managed agent infrastructure platform. The platform's vocabulary gives Loomworks four conceptual primitives worth tracking as the Companion and specialists develop into full agents.
Primitive 1 — Outcomes and grader agents → Shape-as-acceptance-criteria + review specialist. Managed Agents lets users define criteria for what "good" looks like; a grader agent evaluates output against those criteria. Loomworks already has the criteria — the Shape is a complete specification (Phase 38 grammar declaration formalizes this). What's missing is the explicit grader. A review specialist that reads the Shape and the Render and produces an acceptance assessment is a natural extension of Loomworks' specialist pattern. Becomes important when (a) render specialists compose other specialists' work (Phase 37 territory) and "is this Render faithful to the Shape?" needs to be answerable without the Operator personally reading every output, (b) automated quality gates become valuable at platform scale.
Primitive 2 — Multi-agent orchestration → lead/sub-specialist composition with engagement Memory as shared substrate. Managed Agents supports lead agents that decompose work and assign to sub-agents working in parallel on a shared filesystem, with results consolidated through the lead agent's context. Loomworks has render specialists, and Phase 37 introduced adapter chaining and composition — partway there. The Managed Agents pattern points where this extends: a lead specialist that orchestrates sub-specialists, with the engagement's Memory as the shared substrate (instead of a generic filesystem). The shape-grammar declaration work (Phase 38) makes this more tractable because sub-specialists can declare what fragments they produce and the lead can compose them. As specialists become richer, this orchestration vocabulary becomes the way to describe them.
Primitive 3 — Memory + Dreaming → engagement Memory + governed consolidation. See 5.1. The conceptual primitive: persistent agent memory needs active maintenance. Dreaming validates the problem; Loomworks governs the solution differently.
Primitive 4 — Sessions and webhooks → engagement participation periods + lifecycle events. Managed Agents treats sessions as first-class objects with lifecycle events that external systems can subscribe to. Loomworks has engagement participation but no equivalent first-class session boundary or webhook surface. When Arc 2's external service connectors come online (Stripe link, messaging, calendar, third-party render services), the question "how do external systems know what's happening in an engagement?" needs answering. Webhooks on engagement state transitions, render completions, approval events — that's the integration surface. The Managed Agents shape gives the primitive without prescribing the implementation.
The relationship between Loomworks and Managed Agents. Managed Agents is an agent infrastructure layer. Loomworks is a methodology and governance environment for agent-mediated work. They're at different altitudes. Loomworks could run on Managed Agents under the hood, or run its own substrate; the methodology doesn't change either way. What matters is that Anthropic is publicly working out conceptual primitives — outcomes, orchestration, memory, dreaming, sessions — and those primitives compose well with what Loomworks is building. Borrowing the vocabulary is cheaper than inventing parallel terms, and the mapping is honest because both are addressing the same underlying reality of long-running agent work.
Current state. None of the four primitives are built into Loomworks today. Each maps to a specific future direction:
Trajectory. Considered framing as "should Loomworks build on Managed Agents?" Set aside because the question conflates two layers. Managed Agents is infrastructure; Loomworks is methodology. The implementation choice (own substrate vs. Managed Agents) is independent of the conceptual borrowing. The conceptual borrowing is the load-bearing insight: vocabulary that Anthropic is making canonical in the broader ecosystem can be adopted in Loomworks without coupling Loomworks' substrate to Anthropic's platform.
The corrected position: Loomworks builds its own substrate and borrows external vocabulary where it composes well. The Managed Agents primitives are the most useful current example — outcomes/grader, orchestration, memory/dreaming, sessions/webhooks all map cleanly onto Loomworks elements (Shape, specialist composition, engagement Memory, engagement lifecycle). Track new primitives as they emerge from external work; absorb the ones that map cleanly; don't import implementations.
The two entries in this section are the substrate side and the capture-device side of the Operator's mobile experience of the Companion. They emerged from the conversation initiated by the question "Would it be possible to have the Companion present and listening on my mobile (iPhone or Android) similar to how Siri is always present on my iPhone? I would like to be able to say 'Hey Companion, I parked on level 10.'" The conversation surfaced two engagements rather than one, and produced a pair of investigations that should be read together: loomworks-quick-capture-engagement-investigation-v0_2.md and loomworks-mobile-presence-investigation-v0_1.md.
The pair is paced by three constraints worth flagging up front: (i) the substrate side is prerequisite to the capture-device side (mobile is the highest-value surface but cannot ship before /quick-capture exists); (ii) persona-emergence dependency (the voice register fires at much higher frequency than the conversational surface; persona instability is felt sharply at this volume); (iii) mobile-engineering-capacity is the larger pacing constraint (native iOS + native Android is a substantial build, larger than any single substrate phase Loomworks has shipped, and warrants engineering capacity beyond the current DUNIN7-M4 + CC cadence). All three are pacing-readiness concerns, not architecture concerns; the architecture is settled enough at investigation level for scoping to begin when capacity allows.
Trigger. Any conversation about dictation surfaces, fast-path Memory contribution, "Hey Companion, ..." utterance shapes, the parking / grocery-list / "I just parked" use case, append-only Memory contribution with terminal acknowledgment, single-valued vs. multi-valued slot semantics, Companion-noticed supersession, the held-layer-as-supersession-resolution-surface, or any conversation about when an utterance should bypass the full Phase 42 converse pipeline because it's structurally not a conversation. Also: any conversation about queries against quick-captured Memory ("Where did I park?"), or about disambiguation between same-day same-slot facts ("I parked at level 7" after earlier "I parked at level 10").
Substance. Quick-capture is one class of bidirectional Memory traffic on a fast path with three modes: write-clean, write-with-resolution, and read. Capture is dictation-class (capture, route, author held assertion, brief acknowledgment, stop). Routing is engagement-determined via the Companion's three-layer router (Operator-declared rules → engagement-context default → light heuristic). Writes that conflict with structurally similar prior held assertions surface either Companion-noticed supersession (clean cases; auto with naming acknowledgment) or one focused disambiguation question (ambiguous cases). Reads against quick-captured Memory are a sibling mode on the same surface.
The architectural question — intent-class extension on the existing classifier path vs. pre-classifier fast path vs. hybrid — is open. Most likely hybrid: fast path for dedicated capture surfaces (mobile shortcuts, watch complications, keyboard shortcuts), intent extension for chat-pathway invocation. Same router, two entry points.
The methodology-finding-grade observation: single-valued vs. multi-valued slots as an engagement-declared property; Companion-noticed supersession on the held layer as distinct from Operator-explicit retraction. Single-valued slots ("current parking location") supersede on update; multi-valued slots ("items on the grocery list") accumulate. The engagement declares which is which. The held layer is the cheap-supersession layer because supersession before commit doesn't require retraction ceremony. The asynchronous-commit window doubles as the supersession window. Phase 38's declare-and-register pattern is a natural extension surface for slot-semantics declaration.
The voice register expands from one template to four: clean-ack ("Got it. Level 10."), query-response ("Level 10 — at 9:13 this morning."), disambiguation-question ("Got it — earlier today you said level 10. Replace it?"), resolution-ack ("Done. Level 7 it is."). All short; all dictation-class; resistant to the conversational pipeline's tendency toward warmth and elaboration. Likely ships through a voice loader at loomworks/orchestration/quick_capture_voice.py analogous to the credit_voice loader from Phases 49 and 50.
The router is name-agnostic: wake-word recognition is upstream of the substrate; the router receives an utterance and a destination, not a wake-word-keyed dispatch. Companion-name authority lives in the companion_name column (Phase 41); every surface reads from there.
Current state. Not built. Investigation v0.2 is the architectural framing. A scoping note is the next deliverable, paired with the mobile-presence scoping (6.2). The CR follows after scoping.
Trajectory. v0.1 of the investigation framed quick-capture as a third class of turn in a methodology trinity (Companion-proposes/commits, Companion-converses, Companion-routes-and-records). v0.2 reverted that framing: quick-capture is one class of bidirectional Memory traffic with sub-modes, not a third write-class peer. The methodology distinctions live on the write-vs-read and clean-vs-conflicting axes within quick-capture, not at the class-of-turn level. The reversion happened because a three-utterance example ("I parked on level 10" / "where did I park" / "I parked at level 7") surfaced that reads (the second utterance) don't fit "routes-and-records" — they're a sibling mode on the same surface, not a separate class. The trinity framing was making a class distinction at too coarse a level; v0.2 lands it at the right level (sub-modes within quick-capture). Preservation of the v0.1 framing matters because someone reading "third class in a trinity" without the trajectory would not know to look for the sub-mode framing — they'd assume the original answer was the right one.
A second trajectory note: the held-vs-committed posture for alpha was framed in v0.1 as Option 2 (held + asynchronous batch commit), recommended on methodologically-conservative grounds. v0.2 sharpens — Option 2 is more than conservative; it's the architecturally-required layer for the temporal-coherence pattern. Companion-noticed supersession needs the held layer to operate cheaply; without it, every supersession would require explicit Operator-side retraction. The alpha posture has a methodologically-positive reason, not just a defensive one. This is worth preserving because future scoping might be tempted to skip the held layer for "performance reasons" or similar, and the methodology cost of doing so would be high.
Trigger. Any conversation about iPhone / Android Companion presence, "Hey Siri" / "Hey Google" routing to Loomworks, App Intents, App Actions, Siri Shortcuts, foreground wake-word detection, on-device wake-word libraries (Picovoice Porcupine, Snowboy), tap-to-speak surfaces (widgets, watch complications), the Operator Layer extending to mobile, federation between web/desktop and mobile surfaces, the mobile chat surface, push notifications for proactive Companion behavior, offline quick-capture queueing, or the parking-garage example use case (which is literally often spoken offline, in a parking garage, before the substrate is reachable).
Substance. Mobile presence is multi-surface, not single-surface. The literal "always listening like Siri" interpretation is closed for third parties on iOS (Apple reserves system-level wake-word for Siri) and effectively closed on Android (foreground services with persistent notifications are the closest available; battery and OEM-killer dynamics make them unreliable for always-on). The right framing is composition of surfaces, each appropriate for a different posture:
companion_name); gets Siri-class always-on for free. Closest to Siri-equivalent.companion_name literally ("Hey Freda"). On-device detector (Picovoice Porcupine recommended). Most flexible; bounded by foreground posture.companion_name. No wake word; tap is the invocation. The watch complication is the highest-value form factor for quick-capture — phone-in-pocket, wrist-accessible posture is the actual peak case for the parking-garage scenario.
The federation framing is methodology-finding-grade: mobile is an Operator Layer surface, not a forked substrate. Same companion_name, same engagements, same Memory, same converse pipeline, same approval cards. The web Operator Layer is "Operator Layer (web)"; mobile is "Operator Layer (mobile)." Same family, different form factor. The principle is naming-neutral and form-factor-neutral; the same composition would apply to a future TV surface, car surface, or kiosk surface.
Offline posture is a first-class concern, not a footnote. The Operator's exact opening example — "I parked on level 10" — is literally often spoken in a parking garage, where mobile data is unreliable. Local timestamping with replay-time idempotency is the cleanest answer: captures land in a local queue with their original timestamps; queue drains on connectivity return; voice acknowledgment speaks immediately on capture (the on-device voice template is loaded; ack isn't network-gated). Substrate idempotency on (utterance, time-window, person) tolerates offline-replay edge cases.
The recommended primary form is native (iOS Swift/SwiftUI, Android Kotlin/Jetpack Compose). PWA loses most of mobile-presence's value (App Intents, foreground wake-word, watch complication, widgets all require native). Cross-platform (React Native, Flutter, Kotlin Multiplatform) trades platform-native feel for code reuse; some integrations need native bridges anyway.
Current state. Not built. Investigation v0.1 is the architectural framing. A scoping note is the next deliverable, paired with quick-capture's scoping (6.1). The build follows after scoping and after the substrate-side /quick-capture endpoint exists. The build is paced by mobile-engineering-capacity (see 6.3) more than by methodology readiness.
Trajectory. Originally framed as "achieve Siri-equivalence." Set aside because the literal interpretation is closed for third parties on both platforms. Reframed as "compose a set of surfaces such that the Operator experiences the Companion as present and reachable, with as little friction as the platforms permit." The composition turns out to be richer than a single wake-word surface would have been — different surfaces serve different postures, and that's a feature. Worth preserving the trajectory because future sessions might revisit the question "why don't we just make the app always-listen like Siri does," and the answer is Apple and Google reserve that capability for themselves; the App Intents Siri-Shortcut pattern is the closest a third party gets, and it's actually good.
A second trajectory note: the watch complication observation. Initial framing treated the watch as a thin extension of the iPhone/Android app, mostly an afterthought. On reflection, the watch is the highest-value form factor for quick-capture — phone-in-pocket, wrist-accessible posture is exactly when "I parked on level 10" wants to be said. The watch surface eliminates the friction of getting the phone out, which is the highest friction of any surface in the composition. Worth preserving because scoping might otherwise treat the watch as "we'll do that later" when the actual usage pattern says it's the peak case.
Trigger. Any conversation about when to begin Loomworks mobile-app construction; about whether DUNIN7's current build cadence (one substrate phase at a time on DUNIN7-M4 + CC) is appropriate for a native iOS + native Android build; about specialist contractors for mobile work; about cross-platform frameworks (React Native, Flutter, Kotlin Multiplatform) as a way to compress effort; about the relationship between methodology readiness and engineering readiness; or about the pacing of mobile vs. desktop / substrate work generally.
Substance. Native iOS + native Android is a substantial build, plausibly larger than any single substrate phase Loomworks has shipped. The current build cadence is well-tuned for substrate work but is unlikely to be the right cadence for mobile. Three options surface:
The decision is organization-level, not methodology-level. The methodology is settled enough at investigation level for any of the three to work. What changes between them is timing, cost, and platform-native feel.
Current state. No decision; flagged for the next manifest pass and for whichever scoping pass elevates 6.1 / 6.2 from queued direction to active scope.
Trajectory. Originally not surfaced as a separate concern — the assumption was that mobile would proceed through DUNIN7-M4 + CC like substrate phases. The mobile-presence investigation surfaced the build-volume estimate explicitly: native iOS + native Android is comparable in effort to the Operator Layer's web frontend, which has been a multi-phase undertaking. Treating mobile like a single substrate phase would underestimate the effort by an order of magnitude. Worth preserving because future scoping needs to know that mobile is not a small build, even if the methodology investigations make the architecture look tractable. Architecture being tractable doesn't make execution small.
Trigger. Any conversation about the Operator not understanding what the Companion just said; about disambiguating Companion vocabulary in product context; about the comprehension residue that plain-terms-discipline cannot reduce to zero; about Operator-driven what did you mean by that? surfaces; about button-mode explain on the OL converse view; about audible explain through a voice-modality surface; about voice-modality substrate prerequisites for an audible explain (speech-to-text, push-to-talk, wake-word, microphone access, optional TTS); about the relationship between explain affordances and quick-capture (output low-friction vs input low-friction) or mobile presence (shared voice-modality substrate); or about Phase 32 marketing-engagement calibration evidence informing which explain-affordance candidate ships.
Substance. The explain affordance is the first concrete instance of the discipline-plus-recovery principle named at Phase 56 close (manifest v0.41 §2 as v0.21 candidate). The principle: plain-terms-discipline reduces the incidence of vocabulary-comprehension gaps, but does not reach zero — the irreducible residue (Operator encountering a word, phrase, or framing they don't quite grasp in product context) needs a recovery affordance. The explain affordance is the surface where the Operator says what did you mean by that? and the Companion replies with a bounded, on-discipline clarification.
Two trigger modes are anticipated and scoped in loomworks-explain-affordance-investigation-v0_1.md:
Voice composition for the affordance is likely hybrid: LLM-composed by default; pre-authored for the most-encountered explanation triggers (a small library of bounded explain templates); voice-templated scaffolding to keep LLM composition on-discipline. Pre-authoring overhead is moderate; full LLM-composition risks vocabulary drift back toward methodology-noun language unless scaffolded. The voice principles document (Phase 56) anchors the discipline; the explain affordance's voice templates inherit it.
Three candidate phase shapes are scoped:
Current state. Investigation v0.1 (project knowledge) is the design-space framing. Selection deferred to post-Phase-32 calibration evidence — the marketing engagement creation surfaces real-use comprehension-gap data; Operator's actual experience with the now-voice-tuned surface (Phase 56's discipline applied) informs which candidate fits. The three persona transcripts at tests/fixtures/voice-calibration/ may surface candidate comprehension-gap questions when calibration is exercised, but those are forward-looking persona authorship, not real-Operator evidence. Phase 32's lived-Operator-evidence is the load-bearing input to candidate selection.
Trajectory. Surfaced during the Phase 56 scoping arc through the Operator's explain-affordance observation at v0.2 → v0.3: plain-terms-discipline reduces comprehension gaps but doesn't eliminate them; the residue needs a recovery surface. The principle discipline-plus-recovery was named at v0.3 of the scoping note; the affordance was scoped as forward-looking companion artifact (loomworks-explain-affordance-investigation-v0_1.md); Phase 56 named the principle but did not build the affordance. Generalizable lens preserved: any UX discipline reducing an incidence rate needs a recovery affordance for the irreducible residue — explain affordance is one first instance; security defaults / override paths, structured fields / free-text escape, canonical workflows / bypass affordances, calibration-by-persona / Operator-correction loop are sibling instances anticipated. Worth preserving the discovery-arc detail because future scoping might miss the recovery-surface framing if only the explain affordance landed as a feature without its principle context.
The adjacency to §6.1 quick-capture and §6.2 mobile presence is substrate-shaped: audible-mode explain shares speech-to-text + audio capture + activation gating with both. Voice-modality substrate is the shared prerequisite. The three threads may merge into a single mobile-and-voice arc, or stay parallel with shared substrate; the choice is downstream-scoping. The adjacency to §2.2 Phase 32 marketing engagement is calibration-shaped: Phase 32 is the calibration evidence input to the candidate-selection decision.
The two entries in this section emerged from the deployment-strategy work that paralleled Phase 47 credit-substrate scoping. Together they describe the deployment topology that lets Loomworks ship as a fleet of instances, and the methodology framing (Loom + FORAY + OVA composition) that turns per-instance regulatory jurisdiction into a first-class product feature rather than a custom build for each customer. Captured here so the topology and the methodology survive together — neither is useful without the other.
Trigger. Any conversation about Loomworks deployment topology; about hosting jurisdictions or regulatory residency; about white-label and managed-hosting product tiers; about the Authority instance and how grant issuance crosses the fleet; about cross-instance traffic and resilience to instance outages; about how a partner runs their own Loomworks deployment under their own brand; about Hetzner / Railway / AWS / Cloudflare Pages or other hosting choices for production instances; about the public marketing website and how it relates to the Authority; or about fleet management as a Companion task.
Substance. Each Loomworks deployment is a DevOps engagement on DUNIN7's own Loomworks (the control plane). Loomworks manages its own distribution through its own pipeline — fleet management is not a separate tool, it's engagements on Loomworks managing other Loomworks deployments. The pattern carries five load-bearing properties that hang together:
destination_instance recorded. The marketing website is a deployment artifact in its own right, not a feature of any instance.
Current state. Substrate built and tagged through Phase 49. The credit schema is ready (phase-47-credit-substrate-foundation, phase-48-credit-completion-and-operator-signin). Phase 50 brings the public credit-request form and the conversion-credit asset_id override — completing the Authority-side surfaces the website needs to talk to. Fleet deployment itself is post-Phase-50 work: standing up Instance A on Hetzner CPX22, then Instance B on Railway, then Instance C on Hetzner Frankfurt for GDPR, plus the marketing website on Cloudflare Pages. Minimum viable test (website + A + B + C, skipping D) costs roughly $77/month plus Anthropic credits — small enough to prove the pattern before AWS-class spend. Source documents: loomworks-deployment-strategy-v0_2.md, loomworks-hosting-cost-analysis-v0_1.md, loomworks-white-label-multilanguage-analysis-v0_1.md.
Trajectory. v0.1 of the deployment strategy framed credit data as a separate database on each instance and centralized the credit store. v0.2 corrected on five points after credit-scoping v0.7 surfaced the underlying architecture: credit data co-locates in the engine DB under the credit schema (trigger atomicity and transactional signup require this); two-engagement governance with Credit Management as Authority and Accounting as state-keeper (replacing the single "Credit Management" framing); email registry on Instance A only (replacing distributed registries with their abuse-boundary holes); grant flow replacing invitation-code flow (the website is the entry point; codes aren't the abstraction); and the marketing website added as a first-class deployment artifact (the form needs somewhere to live). Worth preserving because the v0.1 framing would have produced a fleet that looked superficially similar but failed at exactly the points where the corrections matter — abuse, atomicity, and the form's home.
Trigger. Any conversation about regulatory jurisdiction as a product feature; about GDPR or EU data residency; about Schrems II or "prove data never left X soil"; about per-instance regulatory framework or retention policy configuration; about how Loomworks handles data sovereignty for regulated customers; about why an Operator might choose Hetzner Frankfurt over Railway US; or about the role each protocol (Loom, FORAY, OVA) plays in compliance posture.
Substance. Jurisdiction is a first-class deployment parameter, and the three protocols compose to make it so:
The composition is what makes jurisdiction selectable. Operators choose hosting based on regulatory need (their domain requires GDPR-bound residency) or privacy preference (they prefer EU jurisdiction even when not strictly required). DUNIN7 doesn't custom-build jurisdiction support per customer — the protocols already compose to give it.
Current state. Conceptually intact because all three protocols already exist: FORAY is live, OVA seam shipped in Phase 45 (per-instance authorization broadened by Phase 49's bimodal dispatch), Loom remembers per-engagement. The per-instance jurisdiction config is implementation work not yet done — Loom-side rule storage, FORAY-side instance-tagged attestations, OVA-side jurisdiction-scoped credentials. Instance C (Hetzner Frankfurt) is the planned EU/GDPR instance per the deployment strategy; the protocol-triangle implementation lands when that instance is stood up.
Trajectory. Original framing (memory-edit era) treated FORAY as carrying the entire compliance story — "FORAY proves it." The conversation sharpened to the triangle once the question "how does an EU operator know their data isn't readable by a US instance?" surfaced — FORAY proves what did happen, but it doesn't prevent unauthorized reads in the first place. Naming the triangle distributes the load: Loom holds the rules, FORAY proves observance after the fact, OVA enforces ahead of the fact. Worth preserving because future implementation might be tempted to lean on FORAY alone (the audit-trail framing is more familiar to compliance-minded customers), and missing the OVA leg would leave the system reactively compliant rather than proactively secure.
Two entries covering how Loomworks engagements pull current state from external services. The architectural move is to build one general-purpose specialist rather than N service-specific adapters; the public-apis catalog is the reference universe of services that specialist can be configured against.
Trigger. Any conversation about Loomworks accessing external APIs; about per-service adapter sprawl; about pulling current state into engagement working state from external sources (weather, FX, holidays, geo, market data, news, image services, etc.); about how the protocol triangle wraps external data; about the seam-and-stub pattern; about whether to ship N specialists or one generic adapter; about MCP versus REST integration patterns; or about the github.com/public-apis catalog and its relationship to Loomworks.
Substance. Build one general-purpose external API specialist that handles all public APIs through a uniform FORAY-attested, OVA-authorized interface, rather than building N service-specific specialists. The specialist takes a declarative API description (URL, method, authentication pattern, parameters, expected response shape) — held as Memory in the engagement that uses it — and produces calls wrapped with full protocol-triangle discipline:
The architectural payoff is that constraint-creep is bounded. Adding the 200th external service is the same shape as adding the second; the gateway scales linearly while specialist count stays at one. The Specialist SDK consumption pattern (Population 1 / 2 / 3) gets a load-bearing first instance — the gateway is itself a Population-1 DUNIN7-built specialist that handles a class.
The pattern has tiers, each progressively more capable but each independently shippable:
Tier 1 covers most cases. Tiers 2-4 are progressive enhancements driven by what real engagements need.
Current state. Not built. Architecturally compatible with existing pieces — Phase 34 shipped external-service polling for specialists, Phase 38 shipped declare-and-register grammar, OVA credential storage exists, FORAY attestation surface is live. The trigger to build is the second engagement that requires live external data on the hot path: Credit Management didn't need it (its operational data is engine-internal), but FarmGuard (weather, sensor data) and ExpenseDesk (FX rates, vendor lookup) both will, and Goosey image generation is a render-side analogue of the same pattern. When two of those land in close succession, the gateway specialist becomes the right shared substrate to build first rather than building per-engagement.
Trajectory. Originally framed as "ship 10–15 first-party specialist adapters for high-leverage services" — weather, geo, FX, holidays, identity verification, etc. Reframed by the Operator on 2026-05-09 to "build one general-purpose API gateway with FORAY/OVA wrapping; let the catalog of API definitions live as engagement Memory." The reframing is load-bearing because it converts a build-direction (write more specialists per service) into a build-once-then-configure pattern (write the gateway, configure per-engagement). It also surfaces a sharper observation: external API specifications are themselves a class of supplied domain knowledge — the public-apis catalog is structured external knowledge that becomes more valuable to Loomworks when held as Memory than when retrieved ad-hoc. This composes with the supplied-domain thesis from the methodology engagement: the Operator (or DUNIN7 as a default seed) supplies the catalog of "what external services exist and how to call them"; the gateway acts on it. The reframing also addresses the constraint-creep concern raised in the earlier MCP discussion — instead of N specialists or N MCP servers proliferating, one configurable gateway scales.
Trigger. Any conversation about which external APIs Loomworks should support; about the universe of free/public APIs available to draw from; about github.com/public-apis as a resource; about discovery of external services for new engagements; about populating the gateway specialist's known endpoints; or about external information seams in general.
Substance. The public-apis repository (github.com/public-apis/public-apis) is a community-curated catalog of free public APIs across roughly 50 categories — weather, finance and FX, geocoding and geo data, holidays, government data, news, sports, identity verification, image services, vehicles, animals, anime, blockchain, and more. Each entry follows a standardized format: name, description, authentication requirement (none / apiKey / OAuth), HTTPS support, CORS support, optional Postman collection link. The catalog is actively maintained, sponsored by APILayer, and contains roughly 1,500+ entries.
For Loomworks, the catalog is the reference universe for the general-purpose API gateway specialist (8.1). Three ways it composes:
Current state. Not ingested. The catalog is a resource to draw on; ingestion is gated on the gateway specialist (8.1) being built. The catalog should be treated as a living external resource — community-maintained, will continue to evolve — not as a fixed snapshot. Ingestion patterns should accommodate periodic refresh.
Trajectory. Originally surfaced as "this might be useful" by the Operator in a chat session. Sharpened in the same session into the gateway specialist pattern (8.1) once the recognition landed that one wrapper handles the class. The catalog without the gateway is just a list; the gateway without the catalog still works (engagements can declare any endpoint); the two compose into a coherent external-information-seam architecture in which the catalog supplies the universe and the gateway supplies the discipline.
One entry in three subsections, capturing the Operator's recognition that the Companion should maintain standing awareness of the Operator's current state and relevant environment — meaningfully more powerful in context than Siri-class voice assistants.
The architectural recognition is that what looks like "the Companion answers a question" decomposes into a Memory-lookup component plus an engine-clock-or-external-seam component, and that this decomposition generalizes to a whole class of ambient-context capabilities. The Companion's standing posture is to maintain a current-state model of the Operator's situation and the relevant environment, and to draw on it (and offer from it) without being asked to fetch each piece individually.
Trigger. Any conversation about the Companion knowing what time it is, where the Operator is, what's on their calendar, what the weather is, what's happening relevant to them today; about Siri-comparison or any "this should be more powerful than Siri" framing; about why the Operator should not have to re-explain context in each interaction; about proactive Companion behavior anchored in current state ("you should leave in 8 minutes for that meeting"); about the difference between cold-start question-answering and standing-context question-answering; or about composing personal Memory, engine state, and external seams into a coherent moment-to-moment picture of the Operator's situation.
Substance. The Companion's standing posture should include continuous awareness of the Operator's current state and the environmental factors relevant to their work and life. Three strands compose:
This standing-context capability is what distinguishes the Companion from cold-start voice assistants. Siri answers the question literally asked; the Companion described here understands the question in context because the context is already loaded. "Should I head out?" is answerable without specifying for what, because the Companion has ambient awareness of what's coming up. "Does this work for everyone?" is answerable in the context of who "everyone" is, what their time zones are, and what their calendars say. The Companion can also be proactive: surfacing what the Operator hasn't yet asked but would benefit from knowing, anchored in standing awareness rather than triggered by an explicit question.
Current state. Pieces are shipped or filed:
What's not yet filed as a coherent capability is the composing layer — the standing posture itself. The pieces exist; the discipline of "the Companion maintains an ambient-context model and draws on it without being prompted to fetch each piece" is the gap. The composing layer is methodology-finding-grade work: it's a behavior pattern that ties together capabilities the substrate already supports, rather than new substrate.
The build trigger is when ambient-context behavior becomes load-bearing for an engagement — most likely the mobile-presence engagement (Section 6.2), where ambient awareness is the value proposition. Watch complications and Lock Screen surfaces showing "Companion knows it's 9:13am, you have a 9:30 meeting, traffic is light, leave in 8 minutes" are exactly this capability operationalized.
Trajectory. Originally surfaced when the Operator asked about time-of-day awareness in the context of "what time is it." The narrow question (engine clock + Operator time-zone Memory = local time) is trivial once the time-zone assertion is in personal Memory. The recognition that landed was broader: this trivial-seeming pattern is an instance of a general capability, and that general capability is what makes the Companion meaningfully more useful than Siri-class assistants. The reframe converts "Companion knows what time it is" (a feature) into "Companion has ambient-context standing posture" (a capability shape that subsumes time, weather, calendar, location, schedule, and world-relevance under one discipline). Worth preserving because the ambient-context framing changes how downstream features get built — they get built as additions to the standing model, not as one-off feature flags.
Trigger. Any conversation about how the Companion answers ambient questions; about composing personal Memory with engine clock or external seams; about generalizing trivial questions into a discipline; about why "what time is it" is the same shape as "should I bring an umbrella" or "is my colleague awake."
Substance. Ambient-context questions decompose into two or three components:
This pattern generalizes to a class of capabilities: time-of-day, weather, calendar context, traffic, holidays, daylight, world-events-relevant-to-the-Operator. All decompose the same way. All benefit from the same Memory discipline. All compose with the API gateway specialist (8.1) for the universal-component side and with personal Memory (Phase 41) for the specific-component side.
The methodology recognition is that this is the supplied-domain thesis applied to ambient context. Universal facts about the world (current UTC, current weather in Miami, current traffic on I-95) are findable by anyone. They become useful to the Companion when they're composed with what the Operator has supplied about themselves — where they are, what they care about, what's relevant to them. Same shape as deeper domain knowledge: the universal is available; the specific has to be supplied; the value is in the composition.
Current state. Pattern is named here for the first time. Each instance of it that gets built (time, weather, calendar) should follow the same structural shape so the discipline compounds rather than fragmenting into ad-hoc per-feature code. The first instance (time) is essentially shippable today given Phase 41 personal Memory and engine clock; subsequent instances depend on Section 8.1's API gateway specialist landing.
Trajectory. No prior framing to preserve — the decomposition pattern is new with this entry. Worth recording for v0.21 methodology consolidation as a candidate methodology principle: ambient-context capabilities decompose into universal (engine or seam) plus specific (Memory) plus bridging (Companion reasoning), and benefit from being built to that shape rather than as one-off features.
Trigger. Any conversation about the Companion knowing which context to surface; about proactive ambient-context offers; about why standing awareness is more powerful than answering-when-asked; about how the Companion decides when traffic information matters versus when it doesn't.
Substance. Maintaining ambient context is necessary but not sufficient. The Companion also needs to know which subset of ambient context is relevant to a given moment or question. This is the relevance bridge: the disciplined judgment about what to surface, what to compose into an answer, and what to leave silent.
Three patterns:
The relevance bridge is the discipline that prevents ambient awareness from becoming noise. Siri's failure mode (and most voice-assistant failure modes) is that they answer literally, even when the literal answer isn't what was wanted. The Companion's relevance bridge is the antidote: ambient context informs the answer, but the answer is shaped by what was asked, by what the Operator cares about, and by what's currently load-bearing in their work.
Current state. Not built as a discipline. Pieces of relevance reasoning happen ad-hoc in Phase 42 intent classification and Phase 44 proactive behavior. Naming it as a discipline lets future builds follow the pattern rather than reinvent per-feature relevance logic.
Trajectory. No prior framing. Worth filing because the relevance bridge is the difference between a Companion that's useful and a Companion that's annoying. Both have the same ambient context; only one knows when to deploy it.
The architectural construct that subsumes ambient context (Section 9), proactive cross-engagement awareness, the Operator's standing relationship with the Companion, and several other behaviors that are Operator-bound rather than engagement-bound.
Why this section exists. The Operator asked, in conversation, whether "keep me in your thoughts and remember stuff for me; alert me to other engagements' activity when appropriate" was itself an engagement. The unpacking surfaced that it isn't — engagements are bounded, four-room, domain-holding things; what the Operator described is continuous, cross-engagement, Operator-bound. The thing without a name is the standing Companion, and naming it as a first-class architectural construct is the move this section makes. The naming is methodology-finding-grade and load-bearing for v0.21 consolidation; this section is the queued-directions filing of it pending that consolidation.
Trigger. Any conversation about the Companion's behavior across engagements rather than within one; about what the Operator means when they say "keep me in mind"; about the difference between Companion-as-chatbot and Companion-as-attendant; about why the personal engagement isn't sufficient to capture the Companion's continuous role; about cross-engagement alerting; about the executive-assistant framing. Also: any question of the form "is X an engagement?" where X is a behavior pattern, a posture, or a continuous relationship rather than a bounded domain — the answer template lives here.
Substance. The Companion has two operating modes:
These aren't two Companions. They're the same Companion in two postures, switching based on what the Operator is doing and what the moment requires. The standing Companion is what makes Loomworks Companion meaningfully more than a chatbot inside an engagement — it's the continuous relationship that engagement-bound mode then specializes into when the Operator enters a specific engagement.
A useful analogy: in a company, there are projects (bounded, with deliverables, with teams) and there are executive assistants (continuous, attending to the principal, holding context across all projects, surfacing what's relevant when it's relevant, governed by the principal's standing preferences). Projects are engagements. The standing Companion is the executive assistant. The analogy isn't perfect — the Companion is not a separate person, it's a posture of the same Companion — but it captures the relationship cleanly: continuous attendance, principal-derived authority, judgment about when to surface what.
The standing Companion has these load-bearing properties:
Current state. Pieces are shipped or filed:
What's not yet built is the composing layer — the standing Companion as a named, disciplined construct with its own working state, its own authority model, its own composition rules with engaged mode. The composing layer is methodology-finding-grade and substrate-shaped: 10.2 (standing Memory as its own scope) is a substrate move; 10.3 (authority and scope) and 10.4 (standing/engaged composition) are behavioral disciplines that compose over the substrate.
Trajectory. Originally, cross-engagement Companion behavior was framed informally as "what the Companion does between engagements" or "personal Companion behavior" — neither name was load-bearing. The Operator's question "is this an engagement?" surfaced the deeper recognition: the behaviors being asked about (keep-in-mind, remember-for-me, alert-across-engagements) don't fit the engagement shape. They're a different category. Naming the standing Companion as a first-class construct, distinct from engagements and distinct from the personal engagement, is the architectural move that makes those behaviors filable, designable, and buildable. Worth preserving because future builds otherwise risk being modeled as either "another engagement" (wrong shape) or "a feature inside the personal engagement" (also wrong shape — confuses Operator-declared content with Companion-tracked working state). The standing Companion is its own thing.
Trigger. Any conversation about where the standing Companion's working knowledge lives; about whether personal-engagement Memory is the right home for cross-engagement attention state; about what the Companion tracks about the Operator versus what the Operator declares about themselves; about new Memory scopes; about the substrate work the standing Companion requires.
Substance. Standing Memory is its own Memory scope, distinct from personal-engagement Memory, sitting in the Operator's Memory access set alongside personal Memory and the Operator's engagement Memories.
The distinction the substrate needs to carry:
These are different categories of held information with different governance shapes. Conflating them — putting the standing Companion's working state into personal-engagement Memory — would muddy two distinctions that should stay clean: declared-vs-tracked, and durable-vs-current.
Standing Memory composes naturally with the existing N-space Memory pattern. The Operator's access set becomes:
Standing Memory has its own backing decisions — likely assertion-backed for some of its content (durable preferences the Operator has set), database-backed for the higher-velocity working state (current calendar, current location, current pending items). The resident-engagement investigation's Memory-backings axis (v0.2) applies; standing Memory uses the same calibration.
Current state. Not built. Substrate work — likely a Phase, possibly load-bearing for the standing-Companion build. The work involves: declaring standing Memory as a Memory scope; defining its assertion and database-backed sub-shapes; integrating it into the Operator's Memory access set; building the read and write APIs the standing Companion needs; the governance discipline (some standing Memory writes are Companion-initiated and Operator-acknowledged rather than Operator-initiated).
Trajectory. Originally considered (in the same chat session that produced this section) the simpler option of putting standing Companion working state into personal-engagement Memory. Set aside in favor of standing Memory as its own scope because (a) it preserves the cleaner separation of declared-vs-tracked content, (b) governance shapes differ and shouldn't be forced through one channel, (c) personal-engagement Memory is content-oriented (the Operator's own assertions about themselves) while standing Memory is state-oriented (the Companion's working model of the Operator's current situation), (d) future composition with organization or team Memory cleanly slots beside standing Memory in the access set. The Operator's call to take the cleaner-but-substrate-heavier option is recorded here because it has implementation consequences — the standing-Companion build is bigger than it would be if everything lived in personal Memory.
Trigger. Any conversation about what authorizes the standing Companion to read across engagements; about whether the Companion can act on its own initiative; about how the Operator controls when the Companion interrupts; about do-not-disturb patterns; about the threshold of utility; about why the standing Companion can't accumulate authorization beyond the Operator's; about the difference between reactive and proactive surfacing.
Substance. The standing Companion's authority model has two parts.
Authorization derives from the Operator, not independently. The standing Companion operates with the Operator's credentials and access set. OVA's per-Operator credentials are the mechanism. The standing Companion can read whatever the Operator can read; it cannot read what the Operator cannot read. It cannot accumulate authorization the Operator hasn't granted. This is structurally important: it means the standing Companion is exactly as bounded as the Operator is, no more, no less. The only thing the standing Companion adds is attention — it watches what the Operator could watch, and surfaces what the Operator would care about.
Proactive scope is Operator-declared, not Companion-determined. The standing Companion's right to interrupt or surface unprompted comes from explicit Operator declarations held in standing Memory. The default posture is silence. Examples:
These declarations form the scope layer of the standing Companion's proactivity. The Operator can add, modify, or retract them; they're held in standing Memory; they're queryable each time the standing Companion considers surfacing.
The judgment layer over scope is the relevance bridge (Section 9.3). Scope says "I'm allowed to surface this category of thing under these conditions." Judgment says "given that I'm allowed, is this specific instance more valuable to surface than the cost of interrupting?" Both are required. Scope without judgment produces noise (alerting on every authorized event, regardless of whether the Operator currently cares). Judgment without scope produces overreach (the Companion surfacing things the Operator never authorized it to attend to).
Current state. Not built as a discipline. Pieces of the authority side exist (OVA per-Operator credentials, Phase 49 bimodal dispatch). Proactive-scope declarations don't have a Memory home yet (they belong in standing Memory per 10.2, which isn't built). Authority is the easier piece because it falls out of OVA naturally; scope-declaration substrate is the harder piece and pairs with 10.2's substrate work.
Trajectory. No prior framing for the scope/judgment distinction; it lands here. Worth preserving because future implementations might collapse the two layers (treating proactive surfacing as a single "decide whether to interrupt" gate). The two-layer pattern — Operator-declared scope plus Companion-judged relevance — keeps the Operator in authority over the what while letting the Companion exercise judgment over the when and whether. This composes with the manifest's Operator-authority principle: the machine surfaces and signals; the Operator approves the rules under which surfacing happens.
Trigger. Any conversation about how the Companion behaves when the Operator transitions between engagements; about pre-loading context when the Operator enters an engagement; about how engagement events propagate to the standing Companion's awareness; about mode handoff during a session; about whether standing Companion interjections disrupt engaged-Companion working state.
Substance. Three composition patterns govern how the standing Companion and engaged Companion(s) work together.
Standing-to-engaged context bridge. When the Operator enters an engagement, the standing Companion can pre-load context that the engaged Companion will benefit from. "Marvin's coming to FarmGuard now; he was in ExpenseDesk an hour ago worrying about cash flow; the soil sensor reading from this morning is unusual." The engaged Companion picks up with awareness of where the Operator is mentally, not just where they are functionally. This is a read from standing Memory plus a snapshot to the engaged Companion's working context.
Engaged-to-standing observation upload. When something happens in an engagement that the standing Companion should know about, it propagates upward. "FarmGuard just produced a render that needs Operator approval" → standing Companion now tracks pending approvals across engagements, and the next time the Operator surfaces, the standing Companion can mention it. This is an event from the engagement (via Phase 44's SSE substrate) being absorbed into standing Memory's working state.
Mode handoff. The Operator transitions between modes continuously during a session — "I'm working on FarmGuard… wait, what time is it… okay back to FarmGuard." The standing Companion's interjection ("It's 4:15pm; you have a 5pm call") happens without losing the engaged Companion's working state. Mode handoff is short, transparent, and resumes cleanly. The mechanism is shared session context that both modes read from and write to, with engaged-mode writes treated as the engagement's own work and standing-mode writes treated as cross-engagement observation.
The three patterns compose through the Phase 44 SSE substrate plus standing Memory (10.2). Engagement events flow up to standing Memory via SSE; standing Memory state flows down to engaged Companion sessions via context bridge at engagement entry; mid-session mode handoff is mediated by shared session context.
Current state. Not built as a discipline. Phase 44's SSE substrate provides the wire layer; standing Memory (10.2) provides the durable working state; the composition patterns are the missing behavioral layer. Building this is the integration work that turns the standing Companion from a queued direction into a shipped capability.
Trajectory. No prior framing. Worth filing because the three patterns are easy to confuse with each other if not named separately — context bridge is anticipatory (loading context for the Operator's near-future activity), observation upload is reactive (absorbing what just happened in an engagement), mode handoff is interruptive (the standing Companion stepping in mid-session). Each has its own discipline, its own latency profile, its own failure modes. Conflating them produces sloppy implementations.
The standing Companion subsumes or composes with several queued directions that were previously filed independently. Naming the standing Companion as the architectural construct lets these compose cleanly rather than overlap awkwardly:
This composition surfaces a methodology recognition worth absorbing in v0.21: the standing Companion is the connective tissue across engagements; engagements are bounded systems; together they form the Operator's full working environment. The architecture has both layers; conflating them — treating the standing Companion as another engagement, or treating engagement behavior as standing-Companion work — produces wrong-shaped builds.
Build trigger for the standing Companion overall. The first non-chat surface that needs continuous standing attention. Mobile presence (Section 6.2) and quick-capture (Section 6.1) are both candidates; whichever lands first triggers the standing-Companion substrate and discipline as its prerequisite. Until then, the standing Companion's behaviors run informally through the engaged Companion's session-bound posture (which is functional but doesn't generalize to the surfaces those engagements need).
The DUNIN7-facing engagement whose subject is the operation of Loomworks itself across the fleet. Observer surfaces UX friction, token-use inefficiencies, methodology drift, cross-Operator patterns, capacity signals, and Companion-behavior calibration data — so that the DUNIN7 team can make Loomworks better as a product. It is content-blind by construction: it observes the shape of activity (frequencies, latencies, sequences, mode transitions, error rates) but never the content within that activity (engagement domains, contribution bodies, render text, conversation transcripts).
Observer is the first instance of a new architectural category — meta-engagements, whose subject is the operation of other engagements. It is filed here pending fleet deployment; its substrate prerequisite (event emission with content/shape redaction in the fleet topology) is a current architectural decision that has to be made before the fleet ships, because retrofitting clean content/shape separation into a system that's already emitting events is much harder than building it in.
Trigger. Any conversation about observing Loomworks usage across the fleet; about surfacing patterns or friction points across Operators; about token-use optimization at the fleet level; about cross-Operator product signal; about Loomworks management facilities; about "watching how it gets used." Also: any conversation about the relationship between an engagement and other engagements as its subject (the meta-engagement category Observer instantiates).
Substance. Observer is a meta-engagement: an engagement whose domain is the operation of other engagements. It is structurally distinct from both classes named in the resident-engagement investigation:
The category — meta-engagement, observing other engagements' operation — is worth naming as a new class because Observer might not be the only one. Conceivable future meta-engagements include a Compliance Observer (jurisdiction-specific regulatory observation), a Security Observer (anomaly detection in access patterns), a Cost Observer (deeper financial-modeling-side analysis distinct from Observer's product-side token observation). These would all be meta-engagements: shape-only, DUNIN7-or-tenant-facing, observing rather than acting.
Observer holds in its Memory the shape of fleet activity — typed event records carrying timing, identity (or anonymous cohort identifier; see 11.3), sequence, and outcome, but never the payload of the underlying activity. Its renders are analytical views — dashboards of friction points, token-use heatmaps, methodology-drift surfaces, cohort-pattern reports — produced for DUNIN7 consumption.
The value Observer produces breaks into several distinct streams that share the same substrate but answer different questions:
These are not eight separate capabilities to build. They are eight views over the same substrate. The substrate (event stream + shape Memory) is built once; the views are layered on top incrementally as DUNIN7 needs them.
Current state. Not built. The substrate prerequisite (event emission with content/shape redaction at the instance boundary) is a current decision — it must be specified as part of the fleet's deployment architecture before instances start emitting events, because the redaction has to happen at emission, not at ingestion. The Observer engagement itself can wait until there's a fleet to observe.
Trajectory. Originally framed by the Operator with the load-bearing constraint already articulated: "It would not observe what the Engagements are that Operators are creating, simply the interface and methods of Loomworks as they are utilized." This framing landed the content/shape distinction at the very first articulation, which is rare and worth preserving — most observation-system designs have to discover this constraint through privacy incidents. The unpacking sharpened the framing in three places: (a) the constraint must be structural rather than discretionary (Observer can't be trusted to look away; the architecture must prevent looking); (b) the category Observer instantiates is new and deserves its own name (meta-engagement); (c) Observer is not a single capability but a substrate plus a view layer, and the views can be many. Worth filing because future implementations might be tempted to either over-collect (capture content and trust Observer to ignore it — wrong shape) or over-restrict (treat all observation as suspect — leaves real product value on the table). The middle path is structural content/shape separation with a substrate that earns trust mechanically.
Trigger. Any conversation about Observer's privacy boundary; about what Observer can and cannot see; about whether content-blind observation is real or a promise; about event-emission design at instance boundaries; about how the architecture earns Operator trust mechanically rather than rhetorically.
Substance. The privacy boundary between Observer and the rest of Loomworks is content versus shape:
Observer reads shape. Observer never reads content. This is enforced structurally, at the event-emission layer:
This structural design means Observer's content-blindness is not a behavior of Observer — it is a property of the channel between instances and Observer. Even if Observer code wanted to read content, no content would be reaching it. The boundary is mechanical, not behavioral. This is the critical difference between "we promise not to look at your data" (which is a behavioral commitment and can be broken) and "the data never reaches us" (which is an architectural property and cannot be broken without changing the architecture).
The emission service composes naturally with the multi-instance fleet architecture (Section 7.1) and the jurisdiction-governance posture (Section 7.2):
Current state. Not built. The substrate decision — that event emission with content/shape redaction is a fleet-level architectural feature — is the load-bearing call to make now. The actual emission service ships when the fleet ships; Observer engages with it when Observer ships post-fleet. But the commitment to emission-with-redaction has to be made in the fleet's deployment architecture, not retrofitted later. Retrofitting introduces both technical debt and trust debt; building it in is straightforward.
Trajectory. The Operator articulated the content/shape distinction at the very first framing of Observer ("not observe what the Engagements are... simply the interface and methods"). The architectural reframe was: this needs to be enforced structurally rather than left to Observer's discretion. The reframe matters because discretion-based privacy fails (someone eventually peeks; or an incident reveals that "we don't look at X" had quietly become "we do look at X under condition Y"). Structural privacy doesn't fail that way — it can be audited mechanically, and the audit is the design. Worth preserving because future implementations might prefer the easier-to-build discretion-based version; the cost of doing so shows up later, usually catastrophically.
Trigger. Any conversation about whether Observer can identify specific Operators; about Operator consent for observation; about how DUNIN7 reaches out to Operators based on observed friction; about anonymized cohort patterns versus Operator-specific patterns; about layered observation governance.
Substance. Observer maintains two distinct view scopes, each with its own governance:
The two-view architecture has several consequences worth naming:
Current state. Not built. The two-view distinction is the architectural commitment; the implementation is part of the Observer engagement and the emission service. Consent infrastructure (Operator-side opt-in declarations) is a small substrate addition that pairs with the standing Memory work in Section 10.2.
Trajectory. The Operator chose "both with explicit consent for the identifiable layer" over "anonymized only" or "identifiable by default." The reasoning — cleaner-but-substrate-heavier — preserves the high-privacy default while enabling identifiable observation for the cases where Operator-specific help is genuinely useful. This is a real product capability and worth the substrate cost. Worth preserving because the simpler "anonymized only" option was set aside; future implementations could regress to it if the consent infrastructure proves complicated, and the trajectory note flags that the cleaner choice was made deliberately.
Trigger. Any conversation about phasing the Observer build; about which Observer capabilities ship first; about distinguishing substrate work from analytical-view work; about why the emission service can't wait until Observer engages.
Substance. Observer breaks into two architectural layers:
The substrate layer is load-bearing for everything Observer might do. The view layer is incremental — start with a couple of high-value views, add more as needed.
The substrate layer's emission-service component has a current architectural prerequisite call-out: it must be specified as part of the fleet's deployment architecture (Section 7.1) before the fleet ships, because every instance must emit events from day one in the shape-only schema. Retrofitting redaction into already-emitting instances is hard; building it in from the start is straightforward and is the basis for the structural privacy guarantee in 11.2.
The view layer can wait. There's nothing to observe pre-fleet — a single-instance Loomworks doesn't produce cross-fleet signal. Once the fleet has a small number of instances (3+), the substrate starts producing real data; once it has 10+, the views start producing real signal. Observer's first views likely sit in the product-improvement category (UX friction, abandonment patterns) because those are highest-leverage for early product iteration; token-cost views become more valuable as fleet scale grows.
A reasonable phasing:
Current state. Pre-fleet. The substrate prerequisite is the actionable filing; the engagement build itself is queued for post-fleet.
Trajectory. The two-layer split (substrate vs views) emerged from the unpacking — the Operator's question implied a single "Observer agent," but the architecture is cleaner when separated into the substrate (event stream + shape Memory) and the views (many small analytical surfaces over the substrate). Worth preserving because the view layer's incremental shape makes Observer's build cost much lower than "build Observer" would imply — each view is small, each view is independently shippable, the substrate carries the architectural weight.
Trigger. Any conversation about whether Observer is similar to other named constructs; about whether the standing Companion does what Observer does; about whether FORAY makes Observer redundant; about whether the Operator Layer dashboard is Observer-for-Operators; about whether Observer is surveillance.
Substance. Observer is distinct from several other constructs in the architecture, and the distinctions are worth naming explicitly to prevent conflation:
Observer is not the standing Companion (Section 10). This is the most important distinction because the two are shaped similarly. Both maintain continuous, cross-engagement awareness. Both run as observation layers rather than within bounded engagements. Both have rich relationships with the Phase 44 SSE substrate. But:
The right intuition: the standing Companion is the Operator's attendant; Observer is the fleet's instrument. Both watch continuously; they watch different things, for different audiences, with different authority.
Observer is not FORAY. FORAY is the per-action attestation substrate for compliance and traceability within engagements, on behalf of the Operator. Observer is a cross-engagement, shape-only signal stream for DUNIN7. They have different audiences (Operator/regulator vs DUNIN7 team), different scopes (within-engagement vs cross-engagement), different content access (FORAY has access to action content for the engagement it logs; Observer never has content access). FORAY logs Observer's emission events as a meta-attestation that the emission policy was honored (mentioned in 11.2), but the two systems are otherwise structurally separate.
Observer is not the Operator Layer dashboard. The Operator Layer (Phase 46+) is the Operator-facing interface to their own engagements, their own state, their own Companion. Observer is DUNIN7-facing. Operators don't see Observer's outputs; DUNIN7 sees Observer's outputs.
Observer is not surveillance. Surveillance, by usage, implies covert and content-rich observation. Observer is transparent and content-blind. Operators know it exists (it's part of the platform terms); Operators control the identifiable layer through consent; Observer never has content access. The architectural shape is closer to telemetry-with-privacy than to surveillance.
Observer is the first meta-engagement. It instantiates a new category — engagements whose subject is the operation of other engagements. Future meta-engagements (Compliance Observer, Security Observer, Cost Observer mentioned in 11.1) would follow the same structural pattern: shape-only event stream from instances, dedicated Memory in a DUNIN7-or-tenant-facing engagement, view layer producing audience-appropriate outputs. The meta-engagement category may deserve its own section in methodology v0.21 once it has more than one inhabitant.
Current state. Naming is the work this subsection does. No substrate is implied here beyond what's already in 11.2 and 11.4.
Trajectory. The standing Companion contrast was the Operator's explicit request — to name what Observer is by reference to what it isn't, so that the cross-engagement-observation shape doesn't get conflated with the Operator-attendant shape. The two constructs ended up in the same v0.7/v0.8 versions of this document, which is unusual but appropriate — they're architecturally adjacent enough that filing them together prevents future confusion. Worth preserving because if Observer had been filed alone, the temptation to model it through the standing-Companion lens (or vice versa) would have been strong. Naming the contrast at filing time makes the distinction durable.
This section is a discoverability pointer rather than a substantive filing. Two companion documents carry the content:
loomworks-structural-defensibility-investigation-v0_1.md — methodology investigation. Internal architectural recognition. Names structural defensibility as a methodology principle that operates now (rather than future work), traces where it already operates in the architecture (held-then-commit, approval-card pattern, OVA per-Operator credentials, FORAY append-only attestation, Section 11's content-vs-shape boundary, Section 7.2's jurisdiction-governance triangle), and articulates the discipline for future builds.loomworks-structural-defensibility-positioning-v0_1.md — external positioning document. Audience-facing version of the same argument. For use in investor conversations, partner discussions, regulatory communications, talks, and articles. Foregrounds the render-boundary frame as the simpler external story, with the protocol-triangle frame as the deeper architectural reality available to anyone who wants to look closer.Why this is filed here. Structural defensibility is methodology-finding-grade — it's a methodology principle that operates now rather than future work, which is why the primary filing is a methodology investigation. The queued-directions entry exists for discoverability: future readers searching this file for "harm prevention," "AI safety," "structural defensibility," "render boundary," "regulatory positioning," or "compliance" find this cross-reference and follow it to the substantive documents.
The principle in one paragraph. Most AI products defend against harm by filtering at the model — trying to make the model refuse to produce harmful content. Filtering is brittle: it fails when adversarial inputs find new edges, when models leak, when the line between harmful and not moves, when filters become so aggressive they impair legitimate work. Loomworks's defensibility runs through a different vector: structural defensibility makes certain harms architecturally impossible by virtue of how the architecture works. Rules are declared as Memory artifacts (inspectable, governable, composable). Enforcement happens upstream of implementation at OVA (the authorization gate prevents what isn't permitted from reaching the implementation layer). Attestation is mechanical and complete via FORAY (the audit trail is built into every decision rather than being optional logging). Harms the rules prohibit are architecturally impossible to commit, not detected and refused after generation. Harms the rules don't yet prohibit are immediately auditable, so the rules can be updated and future occurrences become impossible.
The render-boundary frame versus the protocol-triangle frame. The simpler external story — "renders are where things happen, and renders are governed" — is correct for the external-delivery case (engagements that produce documents, deployments, contracts, or other artifacts that ship outside Loomworks). The investigation document examines three places where the render-boundary frame is incomplete: resident engagements (where renders are internal information delivery, not external action), operational renders (which legitimately ship without per-action approval, as in Credit Management's automated reconciliation), and the production-vs-policy distinction (render specialists are implementation; they can't carry policy responsibility on their own). The complete defensibility argument runs through the protocol triangle operating across all four rooms, not just at rendering. Both frames are carried in the two companion documents — render-boundary as the communicable external story, protocol-triangle as the deeper architectural reality.
Current state. The principle operates now. The investigation traces six instantiations already in the architecture (5.1 held-then-commit, 5.2 approval-card pattern, 5.3 OVA per-Operator credentials, 5.4 FORAY append-only attestation, 5.5 Section 11's content-vs-shape boundary at instance emission, 5.6 Section 7.2's jurisdiction-governance triangle). What's missing is naming the principle explicitly so future capability work can attach to a consistent discipline.
Methodology v0.21 absorption. The investigation's §9.1 lists what v0.21 should absorb from this filing: structural defensibility as the methodology principle, the protocol triangle's role beyond jurisdiction governance, the render-boundary frame as a correct partial observation with named gaps, and detection-as-fallback rather than primary defense as a discipline call.
Trajectory. The recognition that became these documents moved through three turns: (1) Operator surfaced the AI-harm framing and proposed render-boundary defensibility; (2) unpacking sharpened that the render-boundary frame is correct but incomplete, with the protocol-triangle frame as the complete argument; (3) three Operator decisions selected the filing shape (investigation plus queued direction; both internal and external documents; both frames carried with render-boundary as simpler story and protocol-triangle as deeper reality). The architecture had been instantiating the principle in multiple places; the recognition was that the principle deserves naming so future builds attach to it rather than reinvent the discipline.
A few things worth being explicit about, so this file's scope is clear:
current-status-manifest-vN_M.md), not this file's. This file holds queued futures; the manifest holds active present.what-dunin7-is-building-vN_M.md's job.This file is for: queued directions that will be reached for someday and shouldn't be lost in the meantime; deferred work whose preconditions haven't been met; and explicit trajectory preservation for cases (like 4.3, 5.1/5.2, 6.1/6.2, 7.1/7.2, 8.1, 9.1/9.2, 10.1/10.2/10.3, 11.1/11.2/11.3/11.5, and 12) where the path that got us here matters as much as the destination.
v0.1 (2026-05-04). Initial consolidation. Sections 1–4. Memory archive consolidation supersedes prior memory edits #1, #18, #19, #20, #21, #22, #23 (and absorbs the obsolete #16).
v0.2 (2026-05-07). Adds Section 5 (Agent capability development):
v0.3 (2026-05-09). Adds Section 6 (Mobile presence and quick-capture engagement pair):
companion_name), tap-to-speak surfaces (Lock Screen widget, home-screen widget, watch complication), non-voice (share sheet, keyboard shortcut, typed quick-capture), conversational chat. Methodology-finding-grade observation: mobile is an Operator Layer surface, not a forked substrate — federation through shared substrate APIs; per-surface UX optimization; Companion-name authority unified. Two trajectory notes preserved: the "Siri-equivalence" → "compose surfaces" reframing, and the watch-complication-as-highest-value-form-factor observation.loomworks-quick-capture-engagement-investigation-v0_2.md and loomworks-mobile-presence-investigation-v0_1.md.v0.4 (2026-05-09). Adds Section 7 (Multi-instance fleet and jurisdiction governance) absorbing the substance of two memory edits (multi-instance fleet via DevOps engagements; protocol triangle for jurisdiction governance) into a discoverable section paired with their source documents. Two entries:
loomworks-deployment-strategy-v0_2.md, loomworks-hosting-cost-analysis-v0_1.md, loomworks-white-label-multilanguage-analysis-v0_1.md.v0.5 (2026-05-09). Adds Section 8 (External information seams) capturing two entries from a chat session in which the github.com/public-apis catalog was flagged as a future-useful resource and the Operator's follow-up reframe sharpened it into a load-bearing architectural move. Two entries:
v0.6 (2026-05-10). Adds Section 9 (Companion ambient context) capturing the Operator's recognition that the Companion should maintain standing awareness of the Operator's current state and relevant environment — meaningfully more powerful than Siri-class voice assistants. One entry across three subsections:
v0.7 (2026-05-10). Adds Section 10 (The standing Companion) capturing the architectural construct that subsumes Section 9 and several other cross-engagement behaviors. Triggered by the Operator's question "is 'keep me in your thoughts and remember stuff for me; alert me to other Engagement's activity when appropriate' an Engagement?" The unpacking surfaced that what the Operator described isn't an engagement — it's the standing Companion, the Operator-bound mode of the Companion that runs continuously across all engagements. Five subsections:
v0.8 (2026-05-10). Adds Section 11 (Observer — cross-fleet usage observation engagement) capturing the Operator's recognition that Loomworks itself needs an observation layer to surface UX friction, token-use inefficiencies, methodology drift, and cross-Operator patterns. The Operator articulated the load-bearing privacy constraint at first framing: observation must be content-blind (substrate and methods, not engagement domains). The unpacking surfaced that the constraint must be enforced structurally rather than discretionally, and that Observer instantiates a new architectural category — meta-engagements, whose subject is the operation of other engagements. Five subsections:
v0.9 (2026-05-10). Adds Section 12 (Structural defensibility — cross-reference) as a discoverability pointer to two companion documents. The companion documents — loomworks-structural-defensibility-investigation-v0_1.md (methodology investigation, internal architectural recognition) and loomworks-structural-defensibility-positioning-v0_1.md (external positioning, audience-facing) — carry the substantive content; this section exists so future readers searching for "harm prevention," "AI safety," "render boundary," "regulatory positioning," or related terms find the cross-reference and follow it. Triggered by the Operator's recognition that the "illegal use" framing permeating AI discourse should be examined against Loomworks's architecture. The unpacking surfaced that Loomworks's defensibility is structural (rules-in-Memory plus upstream OVA enforcement plus FORAY attestation) rather than filtering-based (model-layer detection of harmful content) — a methodology principle that operates now rather than future work. The investigation document traces six instantiations already in the architecture (held-then-commit, approval-card pattern, OVA per-Operator credentials, FORAY append-only attestation, Section 11's content-vs-shape boundary, Section 7.2's jurisdiction-governance triangle); the positioning document carries the audience-facing version with the render-boundary frame as the simpler external story and the protocol-triangle frame as the deeper architectural reality. Three Operator decisions captured: investigation-plus-queued-direction filing shape; both internal and external audience documents; both render-boundary and protocol-triangle frames carried. Discoverability keywords extended (structural defensibility, structural vs filtering, illegal use, AI harm framing, render boundary, protocol triangle for harm prevention, rules in Memory, upstream enforcement, mechanical attestation, jailbreak resistance, considered work versus consequential commitment, architecturally impossible harms, detection as fallback, regulatory positioning, compliance investigation substrate). Provenance note updated. Trajectory-preservation cross-reference updated to include Section 12.
v0.10 (2026-05-11). Absorbs Phase 55 close (Engagement Creation Assistance — Conversational Surface). The engagement creation arc's product loop is now closed end-to-end via Phase 53 (substrate primitive) + Phase 54 (terminal commit symmetry) + Phase 55 (upstream conversational surface). This is a status-update + structural-extension bump rather than a new-section bump — Section 1's structure extends from 2 sub-entries to 4 sub-entries; Section 2's §2.2 advances from deferred to newly first-class actionable; no new top-level section is added. Changes:
/operator/create-engagement (Operator Layer; 12th prerendered route). Substrate: POST /me/engagements/create-from-conversation endpoint; EngagementCreatedFromAssistance Memory event class (FORAY-anchored at "standard" priority); three new IntentLabel literals; conversation turns stored in Phase 42's relational table per the V7 reshape's inheritance of Phase 42's cost decision. Two terminal-turn output paths: write-up-as-Discovery-record (consumes Phase 53's skill via Phase 16 upload pipeline) and commit-as-brief (uses _allocate_candidate_engagement helper plus draft_seed / induct_seed). Trajectory note extended with the methodology trace from Phase 55 V7: v0.1 → v0.2 reshape on storage-mechanism (Memory-event-for-turns → relational-for-turns, inheriting Phase 42's cost decision); preserved as the surfacing event for the now-named principle inherit prior-phase cost decisions (manifest v0.40 §2); Operator's two-question probe ("which scales?" / "how about cost?") carries to v0.21 as Operator-probe-as-correction-mechanism candidate; higher-level Option A held — third instance of substrate-evidence-can-re-rationalize-selection./engagements/{eid}/seed/extract plus Phase 55's Discovery-record output path (Companion-authored Markdown uploaded through Phase 16; same extraction skill). induct_seed production callers: 5 at Phase 55 close. Trajectory note extends with the bounded-contract-not-no-LLM crystallization (manifest v0.38 §2) holding under second-caller pressure.draft_engagement into engagement-allocation and Seed-drafting halves; add a raw-Markdown variant of extract_discovery_to_seed_skill). Both non-urgent; both would reduce the inline-replication count in the engagement-creation-arc orchestration layer. The halt-surface itself — first active firing of the CR-execution boundary of friction-discipline-pattern-family in production — is the load-bearing trajectory artifact, named in manifest v0.40 §2 as the first-firing event.ConverseRequest.intent_hint now derives from classifier.IntentLabel; parallel-enumeration cascade risk eliminated. No further v0.10 action — the candidate is delivered.EngagementCreatedFromAssistance, /me/engagements/create-from-conversation, /operator/create-engagement, mode banner, engagement creation arc product loop closed, multi-path unification verdict, Phase 31 deprecation candidate, Phase 53 deprecation candidate, halt-surface refactor residue, split-draft_engagement, raw-Markdown extract variant, Phase 32 first-class actionable, inherit prior-phase cost decisions, Operator-probe-as-correction-mechanism, build-time enumeration aperture, build-close hygiene branch deletion, tag style annotated).v0.11 (2026-05-12). Absorbs Phase 56 close (Engagement Creation Surface — Voice Work). Phase 56 voice-tuned the conversational engagement creation surface Phase 55 shipped. This is a status-update + structural-extension bump (Section 1's §1.1 status extended in place; Section 6 grows from 3 sub-entries to 4 sub-entries; Section 2's §2.2 status extended in place); no new top-level section is added. Changes:
load_per_field_components loader + dispatcher splice at prompt.py:817 plus matcher token-set extension at router.py plus persona-transcript calibration discipline at tests/fixtures/voice-calibration/ plus OL banner string revision at ChatView.tsx:254. Voice principles document at docs/voice-principles-v0_1.md (engine repo; 146 lines) anchors the discipline and names the discipline-plus-recovery principle whose first recovery affordance is §6.4. Trajectory note extended with the methodology trace from the Phase 56 scoping arc: v0.1 dialog-example reshape (vocabulary leak); v0.2 Step 0 reshape (coverage expansion — work category shifted revisional → additive while higher-level selection held — fourth instance of substrate-evidence-can-re-rationalize-selection); v0.3 Operator-observation extension (comprehension-residue gap and discipline-plus-recovery recovery surface). Three new candidates for v0.21 surfaced and live in manifest v0.41 §2: gap-diagnosis-precedes-gap-implementation; dialog-example-as-scoping-instrument sharpening; discipline-plus-recovery. Two named principles promoted at v0.41 absorption from Phase 56 close: branch-and-tag-name-collision refspec convention; Step 0 branch lifecycle.loomworks-explain-affordance-investigation-v0_1.md into queued directions. The first concrete instance of the discipline-plus-recovery principle (manifest v0.41 §2 candidate). Two trigger modes scoped (button; audible). Three candidate phase shapes (button-first / wait-for-voice-modality / audible-first-via-lightweight-substrate). Voice composition likely hybrid (LLM-composed by default; pre-authored for most-encountered triggers; voice-templated scaffolding). Substrate adjacency to §6.1 quick-capture and §6.2 mobile presence via voice-modality substrate overlap (audible mode). Calibration adjacency to §2.2 Phase 32 marketing engagement. Selection deferred to post-Phase-32 calibration evidence. Filed in Section 6 (not Section 1) because substrate adjacency outweighs engagement-creation-arc adjacency.discipline-plus-recovery; gap-diagnosis-precedes-gap-implementation; dialog-example-as-scoping-instrument sharpening). One minor candidate (instruction-refinement-during-absorption extending recursive-verification-discipline). The queued directions document holds queued future directions; the manifest holds named principles. The distinction continues to be preserved.discipline-plus-recovery principle's first instance); manifest-vs-queued-directions distinction continues to be preserved (Phase 56's promotions stay in manifest v0.41 §2, not surfaced here as queued).DUNIN7 — Done In Seven LLC — Miami, Florida Loomworks — Queued Future Directions and Deferred Work — v0.11 — 2026-05-12