Loomworks — Engagement Domain Composition Investigation — v0.1

Version. 0.1 Date. 2026-05-11 Status. Methodology investigation. Names N-domain composition as the load-bearing pattern at engagement creation and engagement render: every engagement draws on domain from however many Memory scopes are relevant for that engagement, in that jurisdiction, for that Operator, at that moment. The architecture is neutral about the count; the composition is the load-bearing operation. Internal/architectural audience. Author. Claude.ai (investigation layer). Operator: Marvin Percival. Provenance. The conversation followed the Terms of Use Engagement investigation v0.1 and the Operator's recognition that engagement-as-universal-adapter absorbs the entire category of static-but-evolving web content (marketing pages, FAQs, policy pages, documentation, blog posts, status pages). When initially proposing how to file this broader recognition, Claude offered three options shaped around naming a new methodology sub-class ("page engagement," "document engagement," "content engagement"). The Operator pushed back with "domain knowledge manages the uniformity" — surfacing that the architecture doesn't need a new sub-class because the existing engagement-as-universal-adapter principle plus supplied domain handles the uniformity across content types. On the follow-up turn, the Operator further sharpened the framing with "two domains are at play — the type of Engagement being created and the Rules for our organization (branding, style etc)." Claude initially treated this as a two-domain framing; the Operator corrected this to N-domain ("we are really saying 2+"), preventing the wrong number from being frozen into the methodology. The corrected framing — N-domain composition — is what this investigation names. Two Operator decisions captured: "domain composition" naming (aligning with supplied-domain thesis); both this investigation and a Terms of Use Engagement v0.2 absorbing the recognition. Informed by. Supplied-domain thesis from the methodology engagement and the deck work (AI is an expert at everything; until you show it your domain). Memory-space-extensibility investigation v0.1 (N-space Memory: personal, engagement, organization, team, role, domain). Terms of Use Engagement investigation v0.1 (worked instance of engagement-as-universal-adapter applied to a legal document; treated engagement Memory as monolithic — the gap this investigation fills). Structural defensibility investigation v0.1 (rules-in-Memory; the which Memory question this investigation answers). Resident-engagement investigation v0.2 (resident vs delivery engagements; Memory backings). Queued directions v0.10 — Section 7 (multi-instance fleet; jurisdiction Memory); Section 10 (standing Companion; cross-engagement awareness); Section 11 (Observer; DUNIN7-scope vs Operator-scope distinctions). Manifest v0.36 (engagement-as-universal-adapter; Operator-authority principle).

1. The framing question and where it sharpened

The conversation surfaced the recognition that engagement-as-universal-adapter absorbs far more than the methodology had explicitly worked through — not just enterprise engagements like FarmGuard and Credit Management, not just legal documents like the Terms of Use, but also marketing pages, FAQs, pricing pages, documentation, blog posts, press releases, and other static-but-evolving content categories. The Operator's framing for what this implies:

> Engagements are able to be very focussed on a single page, evolving over time, non disruptive and very fast and low cost to maintain and deploy. It reduces web pages to be more similar to document creation in any other area of business, with narrow focus and detail.

Claude initially proposed filing this as a new methodology sub-class ("page engagement," "document engagement," "content engagement"). The Operator pushed back with "domain knowledge manages the uniformity" — surfacing that what unifies engagements across these categories isn't a methodology sub-class but the domain knowledge supplied to each engagement.

This was correct, and Claude absorbed it. But the next turn revealed that Claude had still under-stated the recognition. Claude wrote: "Two domains are at play — the type of Engagement being created and the Rules for our organization (branding, style etc)." The Operator corrected: "If we are saying 'The two-domains framing is the load-bearing recognition' then we are really saying 2+."

The correction matters because two is the simplest case, not the canonical case. Framing the methodology around two domains would freeze the wrong count into the architecture and invite future builds to handle exactly two scopes — then encounter the third (a campaign that spans multiple engagements; a regulatory framework overlaying an organization domain; a partner brand coexisting with the platform brand in a co-produced artifact) and either retrofit awkwardly or treat the third as a special case.

The correct framing — what this investigation names — is N-domain composition. The architecture is neutral about the count; engagements compose domain from however many Memory scopes are relevant for the specific case at hand.

2. What lands

Five claims this investigation will defend:

Engagements compose domain from N Memory scopes, not from one monolithic engagement Memory. The engagement's own Memory holds engagement-specific content; the engagement composes with other scopes (personal, organization, jurisdiction, team/role, campaign, partner, audience) at decision points and render points. Composition is the load-bearing operation.

N is determined per-engagement-per-moment, not by methodology decree. The architecture doesn't fix the count of scopes any engagement can or must compose from. Some engagements compose from two scopes (rare-but-real); some from five or more. The relevant scopes for a given operation are determined by which Operator is acting, in which engagement, in which jurisdiction, at which moment.

The composition pattern is structurally consistent across diverse engagement shapes. A pricing page engagement composes its page-specific domain with organization brand domain and possibly jurisdiction Memory. A Terms of Use Engagement composes its rule-specific domain with organization-commitment domain and jurisdiction regulatory floor. A pricing-page engagement and a Terms of Use Engagement look nothing alike at the artifact layer, but the composition pattern at the architectural layer is the same.

Naming a fixed sub-class for each kind of artifact is the wrong move. "Page engagement," "document engagement," "content engagement" — all multiply concepts unnecessarily. Engagement-as-universal-adapter plus N-domain composition handles the diversity without introducing methodology sub-classes. The architecture stays parsimonious.

N-domain composition is consistent with everything else the architecture has been doing. It composes with N-space Memory (which named the access pattern); it extends to the use pattern (how scopes are consulted at decision and render time). It composes with engagement-as-universal-adapter (engagements stay neutral; supplied domain determines the specific shape). It composes with the supplied-domain thesis (universal expertise plus specific supplied domain — the supply is N-scope, not single-source).

3. The N-domain composition pattern

3.1 What composes, structurally

At every consequential moment in an engagement's operation — content authoring, Companion-mediated query, Memory contribution, render production, OVA authorization, FORAY attestation, approval-card review — the architecture composes domain from the relevant Memory scopes. The composition is what makes the operation produce its specific result; without composition, the operation would either be undefined (no domain) or wrongly scoped (only one domain when multiple apply).

The Memory scopes commonly in play, none of which is canonical and any of which may or may not apply to a specific operation:

Personal scope. The Operator's own preferences, history, conventions, voice. Held in personal Memory under Phase 41's personal-engagement substrate.
Engagement scope. What this specific engagement is about, what it contains, what it has decided, how it evolves. Held in the engagement's own Memory.
Organization scope. The organization's brand, voice, regulatory posture, formal-document conventions, commitments, audience-relationship norms. Held in organization Memory (filed as a Memory scope in the memory-space-extensibility investigation; not yet built as substrate but architecturally present in the methodology).
Jurisdiction scope. The legal and regulatory floor that applies to this instance, per the multi-instance fleet topology (Section 7 in queued directions). Held in jurisdiction Memory at the instance level.
Team or role scope. If the organization has team-level or role-level conventions that differ from organization-wide (engineering's documentation style, legal's drafting conventions, marketing's voice register), they live in team Memory or role Memory, drawn into engagements operated by members of those teams or roles.
Campaign or initiative scope. If a coordinated initiative spans multiple engagements with a unified posture (a product launch with pricing page, FAQ, press release, blog announcement, all coordinated), the campaign domain may live in its own Memory scope that the participant engagements compose with.
Partner or co-producer scope. If an artifact is jointly produced with another organization (a co-branded report, a partner case study, a joint regulatory submission), both organizations' domains may need to compose, with the partnership relationship itself holding the rules about how conflicts resolve.
Audience scope. If a particular audience segment has its own conventions (institutional investors vs retail; clinicians vs patients; experts vs newcomers; jurisdictional regulators vs general public), audience domain may live in its own scope that engagements addressing that audience compose with.

These are the scopes currently visible. More may emerge as the architecture deploys and as new operator patterns appear. The methodology must be N-neutral.

3.2 How composition operates

Composition isn't always uniform. Different scopes contribute different kinds of domain to a given operation, and the composition pattern varies by operation type. Three composition patterns observable today:

Hierarchical floor composition. Some scopes establish floors that other scopes cannot violate. Jurisdiction Memory typically operates this way: the EU regulatory floor cannot be lowered by organization-scope commitment to faster data retention, even if the organization wanted to do so. Hierarchical composition is constraining — the lower scope's commitments must satisfy the higher scope's floor.
Orthogonal contribution composition. Some scopes contribute orthogonal aspects of a render or decision. Organization-scope domain may carry brand voice; engagement-scope domain carries specific content; jurisdiction-scope domain carries legal disclaimers. These compose by combining rather than constraining — each scope adds its piece without conflicting with the others, and the render integrates the pieces.
Override composition with attestation. In some cases, a more-specific scope can override a more-general scope's default, but the override is itself attested. An engagement may declare its own audience-specific voice that differs from organization-default voice; the override is permitted but visible. Override composition is case-by-case — the architecture surfaces the override; governance attests it; the diff is queryable.

These are not separate types of composition; they are facets of the composition pattern that show up differently depending on which scopes are interacting. The architecture's job is to compose; the discipline determines which facet applies at each composition point.

3.3 When composition happens

Composition isn't a one-time setup at engagement creation. It happens at multiple lifecycle points:

Engagement creation. When a new engagement is created, the engagement-creation flow surfaces which scopes the new engagement composes from by default. The Operator may not have to articulate organization-scope domain because it's already held; the Companion reads from it. The new engagement's own Memory bootstraps with reference to the composed scopes.
Content authoring. When the Operator works in the engagement, the Companion composes domain from all relevant scopes to assist authoring. Organization voice shapes how the Companion drafts; engagement context shapes what content matters; audience scope shapes how technical or accessible the language is.
Render production. When a render specialist produces an artifact, it composes domain from all relevant scopes to shape the artifact. The pricing page's brand voice comes from organization Memory; the pricing structure comes from engagement Memory; the regulatory disclaimers come from jurisdiction Memory; all compose into the final HTML.
OVA authorization. At every consequential step, OVA composes rules from all relevant scopes to decide permit-or-deny. Engagement-specific rules; organization-wide commitments; jurisdictional floors. The decision is attested with the rule versions in effect across the scopes consulted.
Companion proactive surfacing. When the standing Companion considers surfacing something proactively, the relevance bridge composes ambient context with engagement context with personal preferences. The same composition pattern; different operational context.

The composition pattern is consistent; the specifics of what gets composed depend on the moment.

4. Why this isn't a new architecture

A critical point worth naming: this investigation isn't introducing new substrate. The composition pattern already operates in Loomworks, implicitly, at every operation that draws on multiple Memory scopes. Memory-space-extensibility investigation v0.1 named N-space Memory as the access pattern; this investigation names the use pattern that the same N-space substrate already supports.

What's been missing is naming the composition explicitly so future builds can attend to it. Without the naming, three things happen by accident:

Engagement Memory becomes a catch-all. Developers (and methodology authors — Claude included, in the Terms of Use Engagement investigation v0.1) put everything in the engagement's own Memory, including content that properly belongs in organization or jurisdiction Memory. Result: the engagement's brand discipline gets re-encoded per engagement; the engagement's legal posture gets re-encoded; the architecture loses leverage.
Cross-engagement coherence is achieved by convention, not by structure. "Make sure to keep the brand voice consistent across pages" becomes an Operator's manual responsibility instead of a composition the Companion does automatically. The discipline doesn't scale.
White-label and managed-hosting tenancy retrofits awkwardly. If organization domain lives inside each engagement instead of in organization Memory, separating "DUNIN7's organization" from "tenant's organization" becomes per-engagement surgery instead of a Memory-scope substitution.

Naming the composition explicitly avoids all three failure modes by making it a first-class methodology pattern that future builds attend to.

5. Composition with the rest of the architecture

5.1 With N-space Memory

The memory-space-extensibility investigation v0.1 named access: which Memory scopes belong in an Operator's access set. This investigation extends to composition: how the scopes contribute domain to specific operations. The two operate together — access determines what's available; composition determines how it's used. An Operator with access to organization Memory has it composed into their engagements' operations; an Operator without that access doesn't.

This composition is bounded by access. The architecture doesn't compose from scopes the Operator can't access. This is what makes N-domain composition consistent with the protocol-triangle posture (Section 12 in queued directions; structural-defensibility investigation v0.1): authorization gates composition at the access layer; the operation can only draw from what authorization permits.

5.2 With the protocol triangle

Loom remembers; OVA authorizes; FORAY attests. The protocol triangle operates across composed scopes:

Loom holds rules across all relevant scopes. Engagement-specific rules, organization commitments, jurisdiction floor — each lives in its appropriate Memory scope. Loom's job is to make all of them queryable.
OVA composes when authorizing. When OVA decides permit-or-deny, it composes rules from all scopes that bear on the decision. The decision is governed by the composed rule set, not by any single scope alone.
FORAY attests with composed-context. The attestation captures the rule versions consulted across the scopes, not just one scope's rule version. Audit can show: at the time of operation O, engagement rule E1 was in effect (version V1); organization commitment C1 was in effect (version V2); jurisdiction floor J1 applied (version V3); the composed decision was D.

This is what makes compliance investigation mechanically complete: the FORAY trail shows the composed rule context, not a single rule. "Why was this permitted (or denied)" becomes a queryable composition across the relevant scopes.

5.3 With structural defensibility

The structural defensibility investigation said "rules are declared as Memory artifacts." It left the which Memory question implicit. The Terms of Use Engagement investigation v0.1 partially answered with "the rules live in the Terms of Use Engagement's Memory," but treated that Memory monolithically.

This investigation gives the complete answer: rules live across multiple Memory scopes; OVA composes them at decision time; FORAY attests with composed context. The Terms of Use Engagement holds engagement-specific rules; organization Memory holds organization-level commitments that apply across the organization's engagements; jurisdiction Memory holds the regulatory floor. The legal document the Operator reads is the composed render — it projects the engagement-specific content shaped by organization conventions within the jurisdiction's regulatory floor.

This composition is what makes the legal document and the enforcement substrate mechanically linked across all the scopes that govern the decision, not just within one engagement's boundary.

5.4 With engagement-as-universal-adapter

Engagement-as-universal-adapter said engagements are general; supplied domain determines what they specifically are. This investigation adds: the supplied domain is itself composed from N scopes. Engagement-as-universal-adapter remains the right framing; what's clearer now is that the "supplied" part isn't a single act of supply. It's composition from whatever scopes are relevant.

This composes with the supplied-domain thesis at the higher level too. The talk argues that AI becomes useful when domain is supplied. The architectural recognition is that the supply is N-scope: the Operator supplies their personal domain to the personal scope; the organization supplies its domain to the organization scope; the jurisdiction supplies its regulatory posture to the jurisdiction scope; the engagement accumulates its specific domain in the engagement scope. The Companion composes across all of these at the moment of operation.

5.5 With the standing Companion

The standing Companion (Section 10 in queued directions) operates with the Operator's full access set, composing across scopes at proactive moments. The relevance bridge (Section 9.3) is itself a composition operation — relevance is determined by which scopes' content bears on the current moment. The standing Companion is, in this framing, the operator-facing instance of N-domain composition for ambient and proactive operations.

5.6 With white-label and managed-hosting tenancy

This is the recognition with substantial commercial implications. The architecture supports white-label and managed-hosting tenancy structurally clean because organization domain lives in organization Memory, not inside each engagement. A managed-hosting tenant's instance composes:

The tenant's organization Memory (their brand, voice, commitments).
DUNIN7's platform-floor Memory (the structural commitments Loomworks itself makes — content-vs-shape boundary, FORAY attestation, protocol-triangle posture).
The tenant's jurisdiction Memory (per-instance regulatory floor).
The tenant's specific engagement Memories.

The tenant's renders look like the tenant's organization. The platform-floor commitments still apply, structurally — they're composed in at every render, attested by FORAY. The tenant gets their brand; Loomworks gets to honor its structural commitments; both compose without conflict because they sit in different scopes.

This is white-labeling that's actually clean. Most white-label platforms either (a) let the tenant override platform commitments (and lose structural defensibility) or (b) force platform commitments into the tenant's brand (and look like the platform poking through). Loomworks composes both correctly. This isn't new architecture — it's a recognition about what the existing architecture already supports once N-domain composition is named.

6. What this changes for engagement creation

The engagement-creation queued direction (Section 1.1 in queued directions; Discovery-to-seed flow) gains a clarification.

When an Operator wants to create a new engagement — a pricing page, a press release, a Terms of Use, a FAQ, a project tracker, an expense log — the engagement-creation flow doesn't ask the Operator to articulate everything from scratch. Some scopes are already held; the Companion reads from them.

What the engagement-creation flow does need to do is:

Identify which scopes the new engagement should compose with. Most engagements compose with personal + engagement + organization at minimum; many also compose with jurisdiction; some compose with team/role; some compose with campaign or audience. The flow surfaces the composition shape for the new engagement.
Help the Operator articulate the engagement-specific domain. What this specific engagement is about, what it contains, how it evolves. This is the new domain to supply; the other scopes are already held.
Surface the composed defaults. "Here's what the new engagement will draw from organization Memory; here's what it will draw from jurisdiction Memory. Anything you want to override at the engagement level?" The Operator can override if needed; the override is itself attested.
Bootstrap the engagement Memory with reference to composed scopes. The new engagement doesn't re-encode organization brand voice; it references organization Memory. The render composes at production time.

This is materially better engagement-creation experience than asking the Operator to re-state organization-level domain for each new engagement. It's also materially better long-term maintenance — when organization brand voice evolves, every engagement that composes with organization Memory reflects the evolution automatically.

7. Worked examples

7.1 Pricing page engagement

DUNIN7 creates a pricing page engagement. The composition:

Engagement scope — the page-specific content: tiers, pricing values, feature lists, what's included, what's not, FAQ-style clarifications, comparison to alternatives.
Organization scope — DUNIN7's brand voice (warm, considered, transparent), formatting conventions (typographic palette, color palette per the brand guide), commitment posture (no dark patterns; no hidden costs; explicit cancellation policy).
Jurisdiction scope — if a particular jurisdiction requires specific pricing disclosures (consumer protection regulations, tax-inclusive vs tax-exclusive display rules), the jurisdiction Memory contributes those at render.
Audience scope — if the pricing page targets a specific audience segment (small businesses vs enterprise), audience Memory shapes voice register, density of technical detail, and presence or absence of certain feature emphases.

The render composes all of these. The HTML page that ships to the marketing site looks like DUNIN7's brand (organization), explains the specific pricing (engagement), satisfies jurisdiction requirements, and addresses the right audience register. Operators don't have to re-state any of the organization, jurisdiction, or audience domain — those are already held.

7.2 Terms of Use Engagement (revisited from v0.1 with composition explicit)

The Terms of Use Engagement investigation v0.1 implicitly treated the engagement Memory as monolithic. The corrected composition:

Engagement scope — the specific rules that govern Loomworks operation: content-vs-shape boundary, FORAY attestation commitment, Operator authority over consequential operations, the four-room separation, specific Memory access rules, audit trail provisions.
Organization scope — DUNIN7's organization-level commitments that apply across all DUNIN7-operated engagements, not just the Terms of Use: regulatory posture, partnership disclosures, contact information, dispute resolution conventions, branding (visual/typographic for the rendered legal document).
Jurisdiction scope — the per-instance regulatory floor: GDPR provisions for EU instances, CCPA provisions for California, sector-specific regulations (financial, healthcare) where they apply.
(Potentially) audience scope — if the legal document has variants for institutional vs retail Operators, audience Memory shapes which variant renders.

The rendered legal document the Operator reads is the composed projection. The Terms of Use Engagement holds the engagement-specific rules; the other scopes contribute their portions; the render composes the final artifact. This is what makes the legal document and the enforcement substrate mechanically linked — OVA composes from the same scopes at authorization time.

7.3 Managed-hosting tenant scenario

A managed-hosting tenant — call them Tenant T — runs their own Loomworks instance. Their engagements compose:

Engagement scope — T's specific engagement content.
T's organization scope — T's brand, voice, commitments. T's organization Memory, not DUNIN7's.
DUNIN7 platform-floor scope — the structural commitments Loomworks makes about content-vs-shape, FORAY attestation, protocol-triangle posture, audit substrate. These don't come from T's organization; they come from the platform layer of the architecture, held in platform Memory.
T's jurisdiction scope — T's regulatory floor.

Every render in T's instance composes from these. T's pricing page looks like T's organization; T's Terms of Use composes T-specific rules with the platform-floor commitments; OVA enforces T's organization rules within the platform floor.

This is clean white-labeling. T's brand appears in their renders; the platform's structural commitments are honored at every operation; both compose without conflict because they sit in different scopes. The pattern works because composition is explicit and N-scope.

7.4 Co-produced artifact (partner scope)

A research engagement produces a joint white paper with a partner organization. The composition:

Engagement scope — the white paper's content.
DUNIN7 organization scope — DUNIN7's brand voice for the portions DUNIN7 owns.
Partner organization scope — the partner's brand voice for the portions the partner owns.
Partnership scope — the rules about how the two organization domains compose: which sections are jointly authored, which are author-attributed, how co-branding is rendered, dispute resolution if the two organizations want different things.

The render composes all of these. The white paper looks like a joint document — neither solely DUNIN7's nor solely the partner's. The partnership scope makes the composition rules explicit; the render specialist follows them.

This is a case where N is meaningfully greater than two-or-three. The architecture handles it because composition is N-neutral.

8. The methodology recognitions worth absorbing

Three for v0.21 consolidation.

8.1 N-domain composition as a load-bearing methodology principle

Name it explicitly. Engagements compose domain from N Memory scopes at decision and render points. The architecture is neutral about N. Composition is the load-bearing operation. The pattern is consistent across engagement shapes; the specifics of what gets composed depend on which scopes are in play for the operation at hand.

Once named, future capability work attends to composition automatically. Engagement creation surfaces the composition shape. Render specialists compose at production. OVA composes at authorization. FORAY attests with composed context. The discipline becomes a first-class methodology pattern.

8.2 The composition facets — hierarchical, orthogonal, override

Three composition facets are visible today:

Hierarchical floor composition — higher scopes establish floors that lower scopes cannot violate.
Orthogonal contribution composition — multiple scopes contribute orthogonal aspects that combine without conflict.
Override composition with attestation — more-specific scopes can override more-general defaults when needed, with the override attested and queryable.

These aren't separate composition types; they're facets of the same composition pattern that show up differently depending on the scopes interacting. Worth naming as a methodology distinction because the discipline for each is slightly different — hierarchical floor is enforced strictly; orthogonal is enforced by completeness; override is enforced by attestation and visibility.

8.3 Composition is what makes white-label and managed-hosting tenancy clean

The architecture's support for white-label and managed-hosting tenancy isn't a separate feature; it's a recognition about what N-domain composition already supports. Organization scope decoupled from engagement scope, with the platform-floor commitments in their own scope, lets tenants compose differently without the architecture having to maintain parallel codebases.

This has commercial consequence and should be foregrounded in any tenancy-related positioning work. The architecture got this right by structuring composition correctly, not by adding tenancy as a feature on top of an architecture that didn't anticipate it.

9. Trajectory worth preserving

The recognition moved through four turns:

Turn one. The Operator surfaced that engagement-as-universal-adapter absorbs static-but-evolving web content broadly. Claude proposed three filing options shaped around naming a new methodology sub-class (page engagement, document engagement, content engagement).
Turn two. The Operator pushed back: "domain knowledge manages the uniformity." Claude absorbed: no new sub-class needed; supplied domain handles the diversity.
Turn three. The Operator extended: "Two domains are at play — the type of Engagement being created and the Rules for our organization (branding, style etc)." Claude treated this as two-domain framing.
Turn four. The Operator corrected: "If we are saying 'The two-domains framing is the load-bearing recognition' then we are really saying 2+." The correction prevented the wrong number from being frozen into the methodology.

Each turn refined what the prior turn left underspecified. The pattern matters for trajectory preservation: the N-domain recognition didn't land in one move. The first move correctly identified that engagement-as-universal-adapter absorbs a broader category; the second correctly identified that domain knowledge handles the uniformity; the third correctly identified that multiple domains compose; the fourth correctly identified that the count is N, not a fixed number. Future readers reconstructing the path should see all four — and especially the corrections from "new sub-class" to "supplied domain" and from "two domains" to "N domains."

Both corrections share a discipline: don't commit the methodology to a specific count or category when the architecture is naturally neutral. Engagement-as-universal-adapter doesn't fix the count of engagement types; N-space Memory doesn't fix the count of Memory scopes; the protocol triangle doesn't fix the count of rules it enforces. N-domain composition continues this discipline. The methodology stays N-neutral; the supplied domain determines the specifics.

10. Filed for consideration

10.1 Methodology v0.21 absorption

The v0.21 consolidation should absorb the following from this investigation:

N-domain composition as the load-bearing pattern at engagement creation and engagement render. The architecture is N-neutral; composition is what makes operations produce their specific results.
Composition facets — hierarchical floor, orthogonal contribution, override with attestation. Three facets of the same pattern; different discipline for each.
N-domain composition's relationship to N-space Memory. Access pattern (memory-space-extensibility) plus use pattern (this investigation) compose into a complete picture of Memory across scopes.
N-domain composition's relationship to the protocol triangle. Loom holds across scopes; OVA composes at authorization; FORAY attests with composed context.
White-label and managed-hosting tenancy as a structural consequence. The architecture supports tenancy cleanly because composition is N-scope; this should be foregrounded in tenancy-related positioning.

10.2 Cross-references this investigation surfaces

Terms of Use Engagement investigation v0.1 — partial; treated engagement Memory monolithically. To be revised in v0.2 absorbing N-domain composition.
Memory-space-extensibility investigation v0.1 — names N-space Memory access; this investigation extends to N-domain composition at use time. The two investigations together complete the N-scope picture.
Structural defensibility investigation v0.1 — said "rules are declared as Memory artifacts" without specifying which Memory. This investigation supplies the answer: rules live across N scopes; OVA composes at authorization; FORAY attests with composed context.
Engagement creation queued direction (Section 1.1) — gains the clarification that engagement creation surfaces the composition shape rather than asking the Operator to re-articulate already-held organization or jurisdiction domain.

10.3 Build implications

Organization Memory as a Memory scope. Filed in memory-space-extensibility v0.1; not yet built as substrate. The N-domain composition pattern depends on it. Build trigger is when DUNIN7's organization commitments need to be drawn from in renders or OVA decisions — likely Phase 51 marketing-site work, or earlier if Terms of Use Engagement work proceeds first.
Jurisdiction Memory as a Memory scope. Filed in Section 7.2; not yet built. Pairs with organization Memory; both are substrate prerequisites for N-domain composition in production.
Render specialists that compose. Future render specialists should be designed to compose from multiple scopes at production time, not just from the engagement's own Memory. This is a discipline call for future build phases.
Engagement-creation flow surfaces composition. The Section 1.1 queued direction should be designed to ask "which scopes does this new engagement compose with" rather than treating each engagement as a Memory-island.

10.4 Open questions this investigation does not resolve

Conflict resolution across orthogonal scope contributions. When two scopes contribute orthogonal aspects that should compose cleanly but happen to conflict (organization brand says one thing about voice; audience scope says another), what's the resolution discipline? Filed open.
Memory composition latency for high-velocity operations. Composing across N scopes at every OVA check has performance implications. Caching, scope-pinning, or composition-result-memoization may be needed for hot-path operations. Filed for substrate work when measurable.
Composition visibility for Operators. Operators benefit from seeing what composes into a given render or decision. The UI/Companion-mediated surface for "show me the composition" is open. Composes with the Terms of Use Engagement's two-axis versioning UI question.
Adversarial composition. Could a malicious Operator (or a compromised engagement specialist) construct compositions that bypass intended constraints? Threat model is open. Composes with the adversarial-Operator open question from the structural-defensibility investigation.
N-domain composition with the standing Companion. The standing Companion operates across engagements; its operations compose from N scopes per moment. Worked through implicitly in Section 10 in queued directions; worth explicit treatment in v0.21.

10.5 What this investigation does not do

It does not specify the substrate for organization Memory or jurisdiction Memory. Those are substrate-build concerns.
It does not enumerate all possible scopes. The pattern is N-neutral; the scopes currently visible are common cases, not the complete list.
It does not resolve the open questions in §10.4. Those are filed openly, not papered over.
It does not replace the resident-engagement investigation, the memory-space-extensibility investigation, or the structural-defensibility investigation. It extends them by filling a gap each one left implicit.

DUNIN7 — Done In Seven LLC — Miami, Florida Loomworks — Engagement Domain Composition Investigation — v0.1 — 2026-05-11