Version. 0.1
Date. 2026-05-09
Author. Marvin Percival (DUNIN7 Operator) with Claude.ai
Status. Draft material for integration into what-dunin7-is-building-v0_20.md to produce v0.21. Not a finished v0.21 — written without v0.20 in front of Claude. Each item below carries (a) draft prose ready to slot into the methodology document, (b) a suggested integration anchor naming the v0.18-era section heading the material likely belongs near, and (c) trajectory notes where the prior position is load-bearing.
Provenance. Manifest v0.35 §1's consolidation backlog: pre-existing v0.20-era unconsolidated concepts (parameterized Shapes, composite specialists, consumer-as-contributor, feedback engagement, image generation as render specialist, the Operator Layer); Phase 47 credit-infrastructure principles; Phase 48 substrate-vs-Companion-intelligence seam; the five-piece Discovery arc filed 2026-05-08; Phase 49's six methodology findings.
Open a fresh Claude.ai session with what-dunin7-is-building-v0_20.md uploaded to project knowledge alongside this draft. Walk Claude through each section below in the order presented. For each item: read the integration anchor, locate the corresponding section in v0.20, decide whether the draft material slots in cleanly or needs reshaping. Land the integrated v0.21 from that session. The manifest v0.35 §1 line "the methodology document does not yet reflect any of this" becomes "v0.21 absorbs this; manifest v0.36 records the absorption."
The draft is sized to be paste-ready: each subsection is roughly the length of an existing methodology section's worth of prose, in the methodology's plain-terms-discipline voice (methodology nouns, not technical-object vocabulary). Where my draft might overlap with content already in v0.20 (since I haven't read v0.20), §7 flags the open questions.
These are concepts already named as pending in v0.20 but not yet absorbed.
Integration anchor. Likely near "Shaping" (v0.18 line 93).
Draft prose. A Shape declares the structure a Render will conform to. Some Shapes are sufficiently general that a single Shape declaration can serve many Renders, each parameterized differently against the same structural template. A weekly digest Shape, for instance, might be parameterized by the week range and the audience; a curriculum Shape might be parameterized by the unit and the prior knowledge assumed. The Shape is the structural commitment; the parameters are the per-Render variation that the structure tolerates.
Parameterization is a Shape-level property, declared at the Shape's creation. Not every Shape is parameterized — many Shapes are specific to one Render and don't need it. The methodology surfaces parameterization as an option Shapes opt into rather than a requirement Shapes must address. The Operator's guidance shapes whether a given Shape declaration carries parameters: if the Render type recurs across instances that share structure but differ in scope or audience, parameters are appropriate; if the Render type is specific, parameters add complexity without value.
The boundary between "different parameterization of the same Shape" and "different Shapes" is a methodology call the Operator makes during specification. A Shape that needs to vary too much across instances has stretched past parameterization and wants to split into Shapes. A Shape that varies only in trivial ways across instances probably doesn't need parameters at all. The middle range — meaningful but bounded variation — is where parameterization earns its place.
Integration anchor. Likely near "Render" (v0.18 line 127), or in a new subsection on specialist patterns.
Draft prose. A specialist is the actor that produces a Render against a Shape. The simplest case is a single specialist consuming a Shape and producing the corresponding Render. The composite case is a specialist whose work is itself the orchestration of sub-specialists, each producing some part of the Render or some intermediate result the lead specialist consumes.
Composite specialists are appropriate when the Render's structure is naturally a composition of pieces, each piece is itself bounded enough to be a specialist's work, and the composition logic is meaningful (not just concatenation). A research-report specialist might orchestrate a fact-checking sub-specialist, a data-visualization sub-specialist, and a narrative-thread sub-specialist, with the lead specialist responsible for integration. The engagement's Memory is the shared substrate: each sub-specialist reads the assertions relevant to its piece, contributes its part, and the lead composes.
The composite pattern is not free. Coordinating sub-specialists is itself work — one more place where structure can drift, one more place where corrections need to land. The methodology stance is that composite specialists exist where they earn their place: where the composition is real, where the sub-specialists are genuinely separable, and where the per-Render orchestration is bounded enough not to recreate the unbounded-agent problem the specialist pattern was meant to avoid.
Integration anchor. Likely "Domains, engagements, and roles" (v0.18 line 201).
Draft prose. The roles Operator and Contributor describe what someone does within an engagement. They are not exclusive. A person who reads a Render — who consumes the engagement's output — can also be the source of new assertions that flow back into Memory. A reader of a research report might surface a correction; a viewer of a curriculum might provide feedback that becomes an assertion the curriculum's next iteration draws on; a customer reading a product brief might respond with a question that reveals a gap.
Consumer-as-contributor is the recognition that the engagement's surfaces — its Renders — are also potential entry points for Memory. The methodology doesn't require this; not every engagement wants its consumers contributing back. But for engagements where the consumer's perspective is itself valuable (education, research that benefits from peer feedback, product work where customer signal is data), the role isn't one-way.
Operationally, consumer-as-contributor needs surface support: a way for the consumer to make a contribution that lands as a held assertion, awaiting Operator commit through the standard pipeline. The contribution doesn't bypass the Operator's authority — it surfaces alongside other held assertions, and the Operator decides whether to commit, edit, or set aside. The consumer's act of contributing is a request for Memory inclusion, not an automatic addition.
Integration anchor. Likely "Domains, engagements, and roles" (v0.18 line 201) or after "Promotion" (line 291).
Draft prose. Some engagements are not about producing Renders for an external audience but about gathering Memory from one. A feedback engagement is structurally inverted from a delivery engagement: its outputs are observations, summaries, and signal extractions, but its primary value is the structured intake of perspectives from contributors who would not be the natural authors of an engagement of their own.
The pattern is familiar in research, customer development, and program evaluation: the practitioner sets the questions; the contributors offer their perspectives; the resulting body of contributions becomes the substrate the practitioner reasons over. In Loomworks terms, the feedback engagement's seed declares the questions and the audience; assertions flow in from contributors as their perspectives; Manifestations and Shapes draw out the patterns; Renders communicate findings back, possibly to the same contributors, possibly to a separate audience.
The methodology distinction worth naming: a feedback engagement is not a special engagement type — it's an engagement whose seed orients toward intake rather than output. The four rooms still apply; the pipeline is the same; what differs is the directionality of the central knowledge flow. Naming the pattern matters because it gives Operators a recognizable shape to reach for when their work is fundamentally listening rather than producing.
Integration anchor. "Render" (v0.18 line 127), with cross-reference to "REFERENCE MATERIAL" if the section names supported render types.
Draft prose. Renders produce content in whatever shape the engagement requires. Text is the most common shape, but the methodology has never restricted Renders to text. Renders may be images, audio, structured data, video, or composites. The render specialist pattern handles each: a specialist declares which Render type it produces, and the engagement's specification grammar declares which types it consumes.
Image generation belongs to this pattern. An image-producing render specialist consumes an image-Shape (which declares the image's structural commitments — character, scene, style, dimensions, palette) and produces the rendered image. The specialist may invoke an external service, may produce the image locally, may compose existing assets, may iterate against operator feedback — the methodology doesn't constrain the production mechanism, only the boundary at which the specialist meets the engagement.
What changes with image generation, relative to text, is that the production mechanism is asynchronous and external for most current image services. The substrate already supports this through the polling pattern: a specialist returns a handle when the work is in flight; the substrate polls the handle until completion; the Render lands when the production finishes. The asynchrony is not an exception to the render pattern; it's the same pattern with a longer time horizon between Shape-declaration and Render-completion.
Integration anchor. Likely "The environment" (v0.18 line 143), with cross-reference to roles.
Draft prose. The Operator's surface is not a single screen. It is a layered environment whose different surfaces serve different postures of operator work. The work of producing a Render in a Shaping room is not the same work as governing membership in an engagement, and is not the same work as approving a contribution that landed while the Operator was elsewhere. Each posture wants its own affordances, its own visual register, and its own depth of engagement.
The Operator Layer is the methodology name for this layered environment. It includes the dashboard (where engagements are visible and the Operator chooses where to spend attention), the four rooms (Memory, Manifestation, Shaping, Render — each with its own posture), the Companion (the conversational entry point that routes the Operator's intentions and surfaces approvals), and the settings surfaces (where the Operator's preferences and account state are governed). Each surface is a window onto the same substrate; what differs is what's foregrounded and what's tucked.
The methodology principle is that the Operator does not work in one mode. The Layer's job is to compose surfaces such that the Operator can move between postures without context loss — a contribution surfaced in conversation can be approved without leaving the conversation; a Render produced asynchronously surfaces as a notification that opens to the Render itself; a member's invitation acceptance lands as both a Memory entry and a dashboard signal. The composition is what makes the Operator role tractable across many engagements at once.
The Layer is also the federation point. The same Operator Layer principles compose across web, mobile, and any future surface — each form factor optimizes its own affordances while sharing identity, engagement set, and Companion presence with the others. Mobile is not a forked environment; it's the Operator Layer at a different form factor.
These are methodology-level principles that emerged from Phase 47 (Credit Substrate Foundation, tagged 2026-05-07). The credit system is built; the principles it surfaced are methodology-shape and want to live in the methodology document.
Integration anchor. "The environment" (v0.18 line 143) or "Domains, engagements, and roles" (line 201).
Draft prose. The engagement is the methodology's unit of bounded knowledge work, but it is also the methodology's unit of integration with everything outside the engagement. Any system that needs to participate in Loomworks — a credit ledger, an external API, a fleet management plane, a feedback intake, a marketing content pipeline — can be modeled as an engagement. Once modeled as such, it inherits the methodology's affordances: a Companion the Operator converses with, a four-room pipeline through which contributions flow, FORAY-attested actions, OVA-scoped access, and the operator-as-final-authority discipline.
This is the engagement-as-universal-adapter principle. It is not that every external system should be an engagement — many don't merit it. It is that the engagement abstraction is the right shape for any system that wants the methodology's governance properties applied to it. The cost of modeling an external system as an engagement is the cost of writing its seed and integrating its data into Memory; the benefit is everything Loomworks already does.
Two kinds of engagement emerge from this framing. Operational engagements hold knowledge that is the engagement's own — research notes, curriculum materials, customer conversations, agricultural observations. The substrate doesn't depend on this knowledge for its own operation; the engagement is the consumer. Infrastructure engagements hold knowledge that the substrate itself reads on the hot path — credit balances, account lifecycle state, fleet membership. The substrate co-locates this knowledge under a separate database schema for the engagement, but the engagement is still governed through the pipeline. The credit system was the first infrastructure engagement; the methodology principle is that any future case where the substrate needs governed access to its own operational data takes the same shape.
Integration anchor. "Domains, engagements, and roles" (v0.18 line 201).
Draft prose. Some governance problems split naturally into two engagements rather than collapsing into one. The Authority is the engagement that sets policy and issues decisions — its work is shaping rules, evaluating eligibility, and producing decisions that change other engagements' state. The State-keeper is the engagement that maintains state and reconciles — its work is recording what happened, exposing balances or status, and reconciling with reality after the fact.
The credit system is the canonical instance. The Credit Management Engagement is the Authority: it owns the policies that govern grant eligibility, it issues grants, it operates the email registry that prevents abuse. The Accounting Engagement is the State-keeper: it maintains balances per person, it reconciles balances with the underlying flow log, it surfaces account state to the Companion. The two engagements are governed through the same pipeline but their concerns don't overlap.
The methodology principle is that two-engagement governance becomes appropriate when the policy-shaping work and the state-maintenance work would otherwise compete for the same engagement's attention. Single-engagement governance works when policy and state are inseparable in practice. Two-engagement governance works when policy needs to evolve at one cadence (deliberate, explicit) while state needs to update at another (continuous, automatic). Forcing them into a single engagement makes one of them second-class; splitting them makes both first-class without doubling the methodology surface.
Integration anchor. "Promotion" (v0.18 line 291) or after a credit-system reference if v0.20 has one.
Draft prose. When an engagement needs to extend access or value to people who are not yet members, the simple shape is a freeform code: the Operator generates a code, the recipient redeems it. This works for unbounded distribution and casual access. But it does not work when the access carries identity (this code is for this email), when abuse boundaries matter (this code may be redeemed once), when audit trails are required (we need to know who issued this and to whom), or when the code's parameters need to ride along with it.
Grant-based delivery is the methodology shape that handles these cases. A grant is an issuance event: the Authority records who is eligible, what they receive, and the conditions under which they may claim. The recipient receives a notification (typically email) carrying a claim link. The claim event reconciles the issuance with the recipient's identity and the destination context. The audit trail flows continuously from issuance through claim through use.
The grant pattern subsumes the freeform-code pattern: a freeform code is a degenerate grant with no identity binding and no expiration. The methodology's stance is to default to grants when the access carries any of identity, scarcity, or audit requirements, and to reach for freeform codes only when none of those apply. The credit system uses grants because eligibility is identity-bound and abuse boundaries matter.
Integration anchor. "Domains, engagements, and roles" (v0.18 line 201).
Draft prose. A person's relationship with the environment is not binary. A person is not simply "a member" or "not a member"; they progress through states each of which has its own affordances and its own constraints. Trial, active, suspended, departed — each names a relationship the person has with the environment, and each licenses different surfaces, different kinds of contribution, different exposure to the Companion's attention.
Modeling the account lifecycle as a state machine — explicit states, explicit transitions, explicit conditions for transitioning — gives the methodology a place to put the per-state rules without scattering them across surfaces. The Memory room is open to active members and trial members but not to suspended members. The Companion engages active and trial members differently. Departed members keep their Memory contributions visible (they're attestations that occurred) but no longer accumulate new contributions.
The state machine is the Operator's tool for thinking about the population of an engagement, not just individuals. "How many people are in trial state and approaching their decision point" is a question the state machine makes answerable. "What changes when someone transitions from trial to active" is a question whose answer is itself a methodology artifact: the transition has a shape, that shape is reusable, and the Authority engagement can encode it once. The lifecycle is a structural property of the engagement, not a per-person quirk.
Integration anchor. Possibly a new subsection in "The environment" (v0.18 line 143) or "Domains, engagements, and roles" (line 201). May also belong in a new section on build-side methodology principles.
Draft prose. Some engagement work is substrate work: reading state, recording transactions, enforcing structural constraints, computing balances. Some is Companion work: judging what to surface, voicing the right register, reasoning about what the Operator most likely wants next. These two kinds of work happen in the same engagement but they are not the same kind of work, and conflating them produces brittle results.
The seam between substrate work and Companion work is methodologically load-bearing. The substrate is deterministic, audited, and fast: it can be relied on to produce the same answer for the same input every time, it leaves a trail, and it is not subject to model variation. The Companion is interpretive, contextual, and adaptive: it draws on the engagement's Memory to make judgments about voicing, about salience, about which state matters right now. Both are necessary. The seam is the place where the substrate's deterministic answer becomes available to the Companion's interpretive reasoning, and where the Companion's interpretive output becomes available to the substrate's structural enforcement.
The build-side instance was Phase 48: the credit substrate completed, exposing balances and lifecycle state through deterministic substrate routes; Phase 49 then layered Companion intelligence over that substrate, voicing exhaustion warnings, tier-drops, and choice presentations. The Companion does not compute balances — it reads them from the substrate. The substrate does not voice — it exposes the data the Companion voices about. Each side's discipline is distinct; the seam is where they meet.
The methodology principle is that any future engagement combining substrate work and Companion work should declare its seam explicitly. Where does deterministic state live; where does interpretive voicing live; how does each side discover what the other has produced? Naming the seam prevents the slow drift in which the substrate accumulates interpretive logic (which becomes brittle and audit-hostile) or the Companion accumulates state-management responsibility (which becomes inconsistent and slow).
These are the five investigations filed in a coordinated arc that Phase 49 read as input. Each is foundational methodology material; the manifest names them as awaiting consolidation.
Integration anchor. "Domains, engagements, and roles" (v0.18 line 201).
Draft prose. Most engagements are delivery-class: they take in contributions, produce Renders, and the Renders are consumed by an audience external to the engagement. The directionality is one-way: knowledge flows in, structured output flows out. Closed-loop engagements have a different shape. Their Renders are not external products — they are inputs to action that changes the engagement's own state. The reconciliation evaluator within the Accounting Engagement is the canonical instance: its Render is a corrective action that, when committed, changes the very balances the engagement maintains.
The closed-loop pattern applies anywhere an engagement observes its own state, identifies a gap or correction, and acts to close it. A QA engagement that observes its own outputs, identifies a defect, and proposes a fix that flows back into the engagement's specification is closed-loop. A monitoring engagement that observes a system's behavior, identifies a drift, and proposes a corrective action against the system is closed-loop. Many infrastructure engagements are closed-loop by nature.
The methodology distinction worth naming: closed-loop engagements need stricter audit-trail discipline than delivery engagements. When the engagement consumes its own Renders, the standard pipeline must still record the consumption — the act of Rendering and the act of Acting must both leave audit-trail evidence. Otherwise readers a year later see only the action and cannot reconstruct the chain that justified it. Phase 49 demonstrated the discipline: the reconciliation flow emits ShapeEvent and RenderEvent inline alongside the corrective FORAY flow row, so the full DST → ShapeEvent → DRT → RenderEvent → action chain is queryable per correction. Closed-loop engagements that bypass standard pipeline routes (because the action is direct-to-substrate) must emit equivalent pipeline-instance events to preserve audit-trail integrity.
Integration anchor. "Memory" (v0.18 line 41) or new subsection on memory dynamics.
Draft prose. Memory accumulates from many sources. An assertion enters Memory through Operator commit, through contributor submission and Operator approval, through automated extraction from an upload. Most assertions stay where they land — they are observations, facts, perspectives, evidence. Some assertions, on reflection, become more than observations: they become statements of how the engagement should be shaped going forward. They become specification.
The elevation pathway is the methodology recognition that Memory contributions can promote into specification. An observation that recurs becomes a pattern; a pattern that holds becomes a rule; a rule that the engagement adopts becomes part of its declared specification. The pathway is not automatic — it passes through the Operator's judgment, the same way every other commitment does. But the pathway exists, and naming it lets Operators reach for it when they recognize that an observation in Memory has earned promotion.
Operationally, elevation looks like the Operator (often through their Companion) selecting a Memory contribution and declaring its structural significance — turning an observation into a DeclaredShapeType the engagement now produces against, or into a constraint the engagement now respects, or into a rule that governs future intake. The elevation is a Memory event in its own right (the assertion declaring the elevation is itself a contribution); the resulting specification element is a downstream consequence.
The methodology principle is that the engagement's specification grammar evolves through Memory contributions, not at seed-creation time only. The seed sets the engagement's initial shape; subsequent elevations extend the shape. This applies whether the elevation is Operator-driven (the typical case) or substrate-driven (the Phase 49 case where the substrate appended DST/DRT events for closed-loop reconciliation).
Integration anchor. "Memory" (v0.18 line 41) or "Rich memory and the boundary" (line 449).
Draft prose. An engagement's Memory is not a single homogeneous space. Contributions live in different relations to the engagement's primary work: some are foreground, currently active in the engagement's pipeline; some are background, available for retrieval but not in active circulation; some are personal to the contributor, scoped narrowly. The methodology recognizes this through the N-space framing: Memory composes from multiple spaces with different visibility, retention, and access properties, while presenting as a single substrate to the engagement's work.
The personal engagement (auto-created, invisible, Memory-only) is one space. The engagement's primary Memory is another. Cross-engagement aggregation, where a Companion reads across the engagements a person is part of, is a third — not a new space exactly, but a way of querying across multiple engagement-Memory spaces simultaneously. Future spaces (federated knowledge from external sources, time-boxed Memory that retires after a window, Memory tagged for export to other engagements) are extensions of the same pattern.
What makes the pattern coherent is that all spaces share the same assertion structure, the same authority model (Operator final, Contributor mediated), and the same audit posture (FORAY-attested through the pipeline). What differs is the visibility scope — who can see and contribute, what queries surface what, when retention rules apply. Naming the pattern as N-space rather than pretending Memory is monolithic gives the methodology a clean way to talk about extensions without each new space being a special case.
Integration anchor. A new subsection on protocol integration, likely after "The environment" (v0.18 line 143) or in REFERENCE MATERIAL (line 467).
Draft prose. The three protocols on which Loomworks rests — Loom (engagement memory), FORAY (transaction grammar), OVA (agent identity and authorization) — are adjacent rather than nested. Each does its own work; together they compose to give Loomworks its governance properties. The composition is load-bearing: removing any one of them leaves a gap the others cannot close.
Loom remembers. Its job is the durable record of what the engagement holds — assertions, events, relationships, state. The methodology's plain-terms vocabulary lives in Loom's structures. Without Loom there is no substrate to reason over.
FORAY proves. Its job is the attestation of transactions: every state-changing action carries a FORAY flow row that records what happened, who did it, when, and against what authorization. FORAY is the audit substrate; it does not enforce or interpret, it records. Without FORAY there is no proof of what occurred.
OVA scopes. Its job is the credentials that gate access — what an actor may read, what they may write, what they may authorize. OVA enforces ahead of the fact; FORAY records after. Without OVA there is no defense against unauthorized access; there is only post-hoc detection.
OVA load-following names the pattern by which OVA's enforcement adapts to the engagement's current authorization needs without requiring the engagement to manage credentials directly. The credentials follow the load — when an actor takes on a new role within an engagement (becomes an Operator, gains contributor access, claims domain expertise), OVA emits the credentials that role requires; when the role retires, the credentials retire. The engagement specifies the role-to-permission mapping; OVA executes the credential lifecycle.
The integration with FORAY is operational: every OVA credential issuance is itself a FORAY-attested event, so the audit trail records not just what was accessed but under what credential the access was authorized. The triangle composes: Loom holds the rules per instance, OVA enforces against those rules, FORAY records both the enforcement and the access.
Integration anchor. A new subsection on build-side methodology, possibly between "The environment" and "The rhythms of the loop."
Draft prose. Some methodology pieces are too large to ship in a single phase but too important to defer indefinitely. The seam-and-stub progression is the discipline that handles these: ship the seam now (the place in the substrate where the future capability will attach), with a stub (a minimal implementation that exercises the seam's contract without yet doing the full work the future capability will do). The seam is real; the stub is provisional; the progression replaces the stub with the full implementation when the time comes.
The pattern's value is twofold. First, building production-shaped use ahead of full deployment surfaces the seam's design problems early — the stub forces the engagement to actually use the seam, which reveals shape mismatches that pure design never would. Second, the seam-and-stub posture commits to the future capability without forcing it to ship complete. The engagement can rely on the seam being there; the future capability has a known integration path.
Phase 45's OVA seam (full OVA spec hardens before deployment, but the seam ships now) is the first instance. Phase 49's cross-engagement Memory read seam (alpha authorizer, OVA-stub-style) is the second. Both build production-shaped use of capabilities whose full implementation lives in a future phase. The discipline is reusable: any methodology capability that wants to ship over multiple phases can use the seam-and-stub progression to commit incrementally without false starts.
The methodology principle is that the seam is the load-bearing piece, not the stub. The stub is provisional; the seam is the contract. Once the seam is shipped, the engagement has paid the integration cost and the stub-to-full transition becomes a localized swap. Pre-stub, every change in the future capability's design risks ripple effects throughout the engagement; post-seam, the future capability's internal evolution is bounded by the seam's contract.
Six findings recorded in Phase 49 implementation notes v0.2 §6. Findings 5 and 6 are the highest-priority for Phase 50 absorption per the manifest.
Integration anchor. A new subsection somewhere in "The environment" (v0.18 line 143), or near a section on Companion-Operator interaction if v0.20 has one.
Draft prose. Loomworks's invariant is that the AI is invisible — the Operator does not see model names, model tier disclosure, or any artifact that would distinguish "talking to one AI" from "talking to another." The Companion is the entity the Operator engages with; what implements the Companion is not part of the Operator's surface.
The credit system breaks this invariant deliberately and bounded. The Operator's credits map to specific underlying models (haiku-class, sonnet-class, opus-class), and the Operator must be able to reason about consumption against substrate-physical reality — the bank balance, the model availability, the cost of the next interaction. Hiding the model identity from the Operator would leave them unable to make informed choices. So the credit system surfaces tier names and asset identifiers in voice templates whose subject is consumption: tier-drop warnings, near-exhaustion notices, exhaustion-choice presentations.
The methodology principle is to name the exception, scope it to its physical-correspondence condition, and require future credit-adjacent surfaces to follow the same explicit pattern. The category itself — legitimate exception to AI-invisibility, bounded by substrate-physical-reality — becomes a named class. Better than letting the principle silently erode through unannounced exceptions.
The principle matters for what comes next. Phase 50 introduces the Companion-as-Authority pattern (the Companion proposing grants for Operator commit), which will be tempted to surface model-identity language in similar ways. The carve-out's discipline applies: where the surface communicates about consumption against substrate-physical reality, model identity may surface; everywhere else, the AI remains invisible.
Integration anchor. "Memory" (v0.18 line 41), or new subsection paired with §4.2 (the elevation pathway).
Draft prose. An engagement's specification grammar — the set of Shape and Render types it produces and consumes — is not fixed at seed creation. It evolves. The elevation pathway (§4.2) names the methodology principle by which Memory contributions can promote into specification; the substrate's first execution of this principle was Phase 49's ensure_reconciliation_specialists_declared function, which appends DeclaredShapeType and DeclaredRenderType events to the engagement's Memory at runtime.
The methodology surfacing is that "seed-resident" framings — the assumption that an engagement's declared types are fixed at seed time and never change — are misleading once the engagement is operating. Declared types are MemoryObjects appended via the standard event log; the seed's job is to declare the engagement's initial grammar; subsequent declarations extend it. This is true for substrate-driven extension (Phase 49's case, where reconciliation needs declared types the seed didn't anticipate) and for Operator-driven extension (the typical elevation-pathway case).
The principle's consequence for future work is that any phase or scoping that names "seed bumps" for grammar evolution should re-check whether the work is actually post-bootstrap event appending. Often it is, and the seed is the wrong place to put the change.
Integration anchor. Pairs with §4.1 (closed-loop engagement architecture). The methodology principle lives in §4.1; the build-record observation that Phase 49 was the first closed-loop build belongs in v0.21's reference material.
Draft prose (build-record reference material). Phase 49 (Companion Intelligence) was the first build-record instance of the closed-loop application class within Loomworks. The Accounting Engagement's reconciliation evaluator emits ReconciliationProposal events; the Phase 49 reconciliation proposal applier writes corrective FORAY flow rows. The Render — the proposal — is consumed by the engagement itself; the action — the corrective flow row — changes the engagement's own state.
The discipline §4.1 names — inline emission of ShapeEvent and RenderEvent alongside any direct-to-substrate action that bypasses standard pipeline routes — was first exercised in this phase. The full audit trail (DST → ShapeEvent → DRT → RenderEvent → flow-row) is queryable per correction. Phase 50's item 2 (Companion-as-Authority) is the inverse case: the Companion proposes and the Operator commits, with the audit trail flowing through standard Phase 45 routes. The audit-trail integrity discipline carries over even though the route is standard.
Integration anchor. New subsection on extension patterns, possibly near "Comprehensive manifestations and structural templates" (v0.18 line 265).
Draft prose. The methodology's extensibility consistently takes a single shape: declare what the engagement handles, register the actor that handles it, let the engine match at runtime. Engagement specification grammar (DST/DRT events declaring what shapes and renders the engagement supports; specialists registered for those types; the engine dispatching at runtime) is one realization. Upload-pathway transformation skills (declaring an upload type the engagement accepts; registering a transformation skill for that type; the engine matching at upload time) is another. Phase 10/11's binding-table schema (Anthropic-keyed declarations for skill availability) is a third. Phase 49's cross-engagement Memory read seam is a fourth.
The methodology principle worth naming is that these are not four distinct extension patterns — they are four surfacings of the same declare-and-register shape. Naming the pattern as a single methodology shape avoids re-inventing it case by case. Future cases where the engagement (or the platform) needs to extend its handled type-set after bootstrap take this shape: declare the new type; register the actor that handles it; the engine matches. The shape is reusable across content types, action types, integration types, and authorization types.
The pattern's reach matters for upcoming work. The upload facility extension queued in loomworks-queued-directions-and-deferred-work-v0_4.md §4 is a declare-and-register case waiting to happen — declare an upload type, register a transformation skill, dispatch at upload time. Recognizing this as the same pattern as engagement specification grammar lets the upload facility extension reuse the existing infrastructure rather than building new.
Integration anchor. "Domains, engagements, and roles" (v0.18 line 201) — extending the Companion-Operator relationship.
Draft prose. The Companion's relationship to Operator authority can take two shapes. In the Companion-mediated mode, the Companion acts on the Operator's behalf — proposes contributions, drafts approvals, prepares actions for Operator commit. The Operator's authority flows through the Companion as a delegation; the Companion is the actor in the audit trail, but the action's authorization derives from the Operator's standing instructions and the Operator's commit. Phase 45's approval-card pattern is the canonical instance.
In the Operator-direct mode, the Operator is the actor with no Companion delegation in between. Self-suspending an account, declining a proposal, claiming a grant — these are actions the Operator takes directly, and the audit trail records the Operator as actor. No delegation gate applies because no delegation occurred.
Both modes are first-class. Neither is "the way the Companion works" exclusively. The methodology principle is that any future action type's dispatcher picks a side per the action's own authorization model: Companion-mediated when the Companion is acting on the Operator's behalf with the Operator's commit closing the loop, Operator-direct when the Operator is the agent of the action and the Companion has no role in authorization.
The principle matters for Phase 50's item 2 (Companion-as-Authority for grant decisions), which inherits the Companion-mediated default. It also matters for any future case where a designer is tempted to "always go through the Companion." Some actions don't fit Companion-mediated cleanly — the Companion is not always between the Operator and their own state.
Integration anchor. Possibly a new section on build-side methodology, alongside §3 (the substrate-vs-Companion-intelligence seam) and §4.5 (seam-and-stub progression). The methodology has under-named build-discipline material; this is a candidate for a dedicated section.
Draft prose. During a phase's build, friction surfaces. Sometimes the friction is small enough to absorb without ceremony — a name divergence between CR sketch and live model, an in-flight clarification of a parameter shape. Sometimes the friction is large enough to halt the build and re-open the CR — an architectural disagreement, a substrate contract that needs rework, a methodology principle that the in-progress design is violating. These are the two well-named paths: naming-only resolution at one end, halt-and-amend at the other.
A third path exists between them: friction that exceeds naming-only scope but does not breach halt-thresholds individually, even though the resolutions accumulate to architectural significance. The substrate-friction-discipline-pattern surfaces such friction during the build through an Operator-elective amendment scoping document. Three properties make the pattern distinct from halt-amend: (i) the build does not halt — substrate work continues with in-flight resolutions in place; (ii) the Operator decides architecturally, with options and halt-threshold review for each; (iii) a sub-step lands the absorbed amendments before continuing.
Phase 49's Step 4 → Step 4 amendment scoping → CR v0.3 → Step 4b sequence is the canonical instance. The pattern's value is that resolutions accumulating to architectural significance get the architectural review they merit, without forcing a full halt-amend cycle for each individually-non-threshold-breaching item. Phase 50 inherits this discipline as the canonical reusable shape — if prerequisite inspection surfaces architectural friction, the Operator-elective amendment scoping path is now the established discipline.
The methodology principle worth naming is that the three paths form a deliberate discipline, not an ad hoc collection. Each path matches a different scale of friction; the pattern's value is the matching, not any individual path. Phases that use only halt-amend treat all friction as architectural; phases that use only naming-only treat all friction as cosmetic; the three-path discipline preserves both ends without conflating them.
The next session should absorb the items above into v0.20 in this order, both because of how they build on each other and because of which inheritances Phase 50 needs:
Order 1–2 is the minimum absorption required for Phase 50 to inherit the methodology cleanly. Orders 3–8 can land in v0.21 or split across v0.21 and v0.22 depending on how long the consolidation pass runs.
Items where my draft might overlap with content already in v0.20 or where the integration may need re-shaping:
Items the manifest names but that are not in this draft:
loomworks-queued-directions-and-deferred-work-v0_4.md. That file is for futures the methodology has not committed to. It does not consolidate into the methodology document; it stays as a separate working file.DUNIN7 — Done In Seven LLC — Miami, Florida Methodology v0.21 consolidation draft material — v0.1 — 2026-05-09