Version. 0.8
Date. 2026-05-10
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) is the first status-update bump rather than a new-section bump — updates §1.1 (Engagement creation assistance pattern) and §1.2 (Discovery-to-seed skill) to reflect Phase 53 close. §1.2 shifts from "not built" to built and shipped at Phase 53 (tag phase-53-discovery-to-seed-skill at engine 702bd34; CR-2026-068 v0.1; substrate primitive landed without amendment); §1.1 shifts from "future direction" to first-class queued at the top of the engagement creation arc — the downstream substrate now exists and is hungry for upstream input; the upstream product surface (Companion-assisted Discovery during engagement onboarding) is what's missing. Both trajectory entries gain a new note preserving the pre-Phase-53 framing alongside the post-Phase-53 framing per Discovery-record posture. Status-update bumps will recur as more queued items ship; v0.8 establishes the convention.
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, Phase 53, engagement creation arc, Discovery-to-seed skill built, discovery_to_seed_extracted, ExtractionSkill Protocol, ExtractionSkillRegistry, bounded contract not no LLM, bounded-contract crystallization, single-shot LLM bounded contract, structured output extraction, gap markers, hallucination resistance, R-A5 R-A6 R-A7 R-A8 R-A9 R-A10 R-A11 targeting, R-A10 endpoint-derived, Phase 16 additive MIME extension, text/markdown upload, Discovery document as Memory artifact, seed_extraction router, /seed/extract endpoint, engagement-scoped URL family universality, induct_seed third caller, Phase 25 canonical path, P53-D12 FORAY anchor priority, scoping contradiction at CR drafting, friction-discipline-pattern-family, Phase 31 induct-seed gap, Phase 31 Phase 53 sibling paths, lens-bounded scoping evidence cascade, status-update bump.
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. First-class queued at the top of the engagement creation arc as of Phase 53 close (2026-05-10). The substrate downstream of §1.1 now exists — Phase 53 landed the Discovery-to-seed skill (§1.2 below), which is hungry for Discovery documents as input. What's still missing is the upstream product feature that produces Discovery records through Companion-assisted conversation. The pattern is still being practiced in chat-based Discovery sessions but is not captured as a product feature; capture-the-process work continues as continuing parallel work, not phase work. Phase 54 candidate per Phase 53 CR §18.1 item 1 — most likely shape for Phase 54 if the Operator commits to engagement creation as the focal arc. Phase 53 CR §18.1 also names item 3 (Operator Layer surface for Discovery → seed → induction) as a downstream candidate that depends on §1.1's design landing first.
Trajectory. Originally framed as "Claude does this for Marvin in chats" — a manual operator-side activity. Reframed 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 changes what's worth capturing during Discovery sessions: not just the output (the Discovery document), but the process (the sequence of questions and elicitations). Phase 53 close (2026-05-10) marks a second framing shift, preserved alongside the first per Discovery-record posture. Pre-Phase-53: §1.1 was a future direction with no built downstream — the assistance pattern would produce Discovery records eventually consumed by an unbuilt Discovery-to-seed skill. Post-Phase-53: the Discovery-to-seed skill is built, the downstream is hungry for input, and §1.1's status changes from "future direction" to "first-class queued with built substrate downstream waiting." The substantive content of §1.1 is unchanged; what shifted is the queue position and the urgency framing — §1.1 is now the immediate next step in the arc, not a parallel future track.
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 registered against ExtractionSkillRegistry) that creates a candidate seed conforming to R-A5 through R-A11 from a Discovery document landed in Memory via Phase 16's upload pipeline. The skill takes the Discovery record as input and produces a draft seed with the six R-A targeted fields filled in (R-A5–R-A9 + R-A11; R-A10 is endpoint-derived per Phase 25 §S2). The candidate seed then enters the seed-induction loop normally via the Phase 25 induct_seed canonical path, where any gaps or ambiguities surface as findings the Operator addresses.
Current state. Built and shipped at Phase 53 close (2026-05-10). Tag phase-53-discovery-to-seed-skill at engine 702bd34 (annotated 94b23e1); CR-2026-068 v0.1; zero amendments; 27 new tests passed. Four substantive surfaces shipped: Phase 16 _ACCEPTED extended with text/markdown (additive single-line change; 18 → 19 MIME types); Discovery-to-seed skill module at loomworks/skills/discovery_to_seed.py (ExtractionSkill-Protocol-conformant per Phase 16 V1 evidence; single-shot bounded LLM call with structured-output instructions; explicit gap markers; _client_factory test seam); discovery_to_seed_extracted Memory event mirroring Phase 25's seed-family (typed MemoryObject subclass; _ANCHOR_PRIORITY entry at events.py:117 per P53-D12 — full _foray namespace injection; OBJECT_TYPE_REGISTRY entry deferred per Phase 50/52 precedent); POST /engagements/{eid}/seed/extract endpoint at dedicated loomworks/api/routers/seed_extraction.py (engagement-scoped per V10's universal /seed family pattern; 11/11 /seed routes engagement-scoped at Phase 53 close; orchestrates file load → skill invocation → R-A10 fill at hand-off → Memory event write with FORAY hooks → induct_seed per Phase 25 canonical path — becomes the third production caller). Migration-free. Prompt template module at loomworks/prompts/discovery_to_seed_extraction.py mirrors Phase 31's creation_conversation.py shape (PROMPT_VERSION = "1.0", EXTRACTION_MODEL = "claude-sonnet-4-6", EXTRACTION_PROMPT with explicit gap markers, __all__ exports).
Phase 53 opens the engagement creation arc with this substrate primitive in place. §1.1 (Engagement creation assistance pattern) is the upstream product surface still missing — the Companion-assisted Discovery that produces the Discovery records §1.2's skill consumes. Phase 54+ candidates per Phase 53 CR §18.1 also include: Discovery-trajectory shape specialist + Discovery-record render specialist (Phase 9 / Phase 10 unbuilt specialists for consistent Discovery-record formatting); Operator Layer surface for Discovery → seed → induction; Phase 31 induct-seed gap clarification (Phase 31 produces string briefs and does not call induct_seed; Phase 53 does; whether deliberate design or incompleteness is a Phase 54+ Operator question); Phase 31 / Phase 53 unification or deprecation; Phase 53 OBJECT_TYPE_REGISTRY entry for discovery_to_seed_extracted (deferred per Phase 50/52 precedent); structured Memory-shape Discovery input (P53-D2 path (b) — Phase 53 reads free-form Markdown only); live-LLM end-to-end integration test cadence (Phase 53 ships with mocked LLM only); Phase 32 marketing engagement as the eventual application of the arc.
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 scoping (2026-05-09) and build (2026-05-10) added a methodological refinement preserved alongside the original framing per Discovery-record posture: bounded-contract-not-no-LLM crystallization. The original "bounded skill" framing implied no-LLM; the live design required real interpretation work to map heterogeneous Discovery shapes onto R-A5–R-A11 (V8 evidence: 6+ distinct organizing schemes across ~12 project-knowledge Discovery records — purely-declarative extraction would over-fit to one scheme). P53-D1 settled the contradiction: the discipline that survives is bounded contract, not no LLM. Single-shot LLM call wrapped by strict input/output contract; no conversation; no multi-turn; no retry-on-clarification; explicit gap markers preferred over fabrication. The skill framing held; what got refined is what "bounded" means — bounded by contract, not bounded by absence of LLM. Promoted to a named principle in manifest v0.38 Section 2 ("Bounded-contract-not-no-LLM crystallization"). A second trajectory note from Phase 53 close: scoping note v0.2 contained an internal mechanical contradiction between its §3.5 schema framing ("_foray namespace + content_hash per V9 canonical pattern") and its §6 V7 row ("Defer OBJECT_TYPE_REGISTRY + _ANCHOR_PRIORITY per Phase 50/52") — mechanically irreconcilable because per V9 evidence _foray is injected only when _ANCHOR_PRIORITY carries the event kind. The CR drafter halted, surfaced both options with V9-mechanics evidence and Phase 25 vs Phase 50/52 precedent framing, and the Operator settled Option A (mirror Phase 25's seed-family — add to _ANCHOR_PRIORITY at priority "standard"). Settlement landed as P53-D12. Recorded here because the contradiction-at-CR-drafting boundary is a discipline pattern (named in manifest v0.38 Section 2 as "P53-D12 settlement-of-scoping-contradiction-at-CR-drafting") that future CR drafting can call back to. Prior position was the dual framing in scoping v0.2 itself; the correction names which side won and why.
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. Deferred until Marvin asks to revisit. The loomworks-marketing-creation-flow-content-v0_3.md and related drafts hold the working material from earlier sessions.
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.
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).
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, and 10.1/10.2/10.3) 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). First status-update bump rather than a new-section bump. Updates §1.1 (Engagement creation assistance pattern) and §1.2 (Discovery-to-seed skill) to reflect Phase 53 close. Triggered by the Phase 53 substrate-primitive landing (tag phase-53-discovery-to-seed-skill at engine 702bd34; CR-2026-068 v0.1; zero amendments; 27 new tests passed) opening the engagement creation arc. Three changes:
ExtractionSkillRegistry per Phase 16 V1 evidence rather than the more generic "extraction skills, materializer registry, etc." framing of v0.7. The Current state paragraph enumerates the four substantive surfaces shipped (Phase 16 _ACCEPTED extension; skill module; discovery_to_seed_extracted Memory event with _ANCHOR_PRIORITY entry per P53-D12; /seed/extract endpoint at dedicated router) and points forward to the Phase 54+ candidates from Phase 53 CR §18.1 (Discovery-trajectory + Discovery-record specialists; Operator Layer surface; Phase 31 induct-seed gap clarification; Phase 31 / Phase 53 unification or deprecation; OBJECT_TYPE_REGISTRY entry; structured Memory-shape Discovery input; live-LLM e2e cadence; Phase 32 eventual application)._foray namespace injection per V9 mechanics; CR drafter halted and surfaced; Operator settled Option A — mirror Phase 25's seed-family by adding to _ANCHOR_PRIORITY at priority "standard"). Both notes preserve the prior framing alongside the post-Phase-53 framing rather than silently rewriting.This is the first bump that updates existing entries without adding a new section. The convention is now established: status-update bumps are valid v0.x increments; the changelog entry names the bump shape explicitly. Future status-update bumps will follow this template — header version + provenance update, in-place edits to the affected entries with trajectory notes preserving prior framing per Discovery-record posture, discoverability keyword extension for any new vocabulary, and a changelog entry framing the bump as status-update rather than new-section.
DUNIN7 — Done In Seven LLC — Miami, Florida Loomworks — Queued Future Directions and Deferred Work — v0.8 — 2026-05-10