Version. 0.2
Date. 2026-05-11
Status. Methodology investigation. v0.2 absorbs the N-domain composition recognition filed in loomworks-engagement-domain-composition-investigation-v0_1.md. The v0.1 of this investigation treated the Terms of Use Engagement's Memory as monolithic — all rules held within the engagement's own scope. The corrected v0.2 framing makes explicit that the Terms of Use Engagement composes from N Memory scopes: engagement-specific rules in the engagement's Memory; organization-level commitments in organization Memory; jurisdiction-specific regulatory floor in jurisdiction Memory; potentially others (audience, partner, campaign) where they apply. The composition pattern is consistent with the rest of the architecture; what changes is that future implementation will explicitly compose across scopes rather than re-encode organization or jurisdiction domain within the Terms of Use Engagement.
Author. Claude.ai (investigation layer). Operator: Marvin Percival.
Provenance. v0.1 (2026-05-11) was triggered by the Operator's recognition that Loomworks's Terms of Use will need to explicitly explain where the platform sits with regard to structural defensibility. Initial framing was toward "Terms of Use as a Memory artifact"; the Operator reframed mid-draft to "Terms of Use as an engagement that renders Terms of Use as an HTML page" — converting a thin category framing into a worked instance of engagement-as-universal-adapter. v0.2 (2026-05-11) absorbs the N-domain composition recognition that emerged in subsequent turns of the conversation. The trajectory: Claude proposed page-engagement/document-engagement/content-engagement sub-classes; the Operator pushed back with "domain knowledge manages the uniformity"; Claude then framed this as two domains (engagement-type plus organization rules); the Operator corrected to N-domain ("we are really saying 2+"). The corrected framing — engagements compose domain from N Memory scopes, not from one monolithic engagement Memory — is filed in loomworks-engagement-domain-composition-investigation-v0_1.md. This v0.2 incorporates the corrected framing into the Terms of Use Engagement design: the engagement composes from engagement-scope, organization-scope, jurisdiction-scope, and potentially other scopes; the render specialists compose at production time; OVA composes at authorization time; FORAY attests with composed context. The composition pattern is what makes the legal document and the enforcement substrate mechanically linked across all the scopes that govern decisions, not just within one engagement's boundary.
Informed by. Structural defensibility investigation v0.1 (rules-in-Memory plus upstream enforcement plus mechanical attestation; the principle but not the specific Memory location). Resident-engagement investigation v0.2 (engagement classes — resident vs delivery; the Terms of Use is a delivery engagement with strong resident scaffolding). Queued directions v0.10 — Section 7.2 (jurisdiction governance triangle; per-instance regulatory posture); Section 8.1 (general-purpose external API gateway as another example of engagement-as-universal-adapter pattern); Section 11 (Observer; content-vs-shape boundary; the platform's commitments to Operators); Section 12 (structural defensibility cross-reference); Section 13 (this investigation's cross-reference entry). Methodology v0.20 (engagement-as-universal-adapter; four-room pipeline; Memory governance; render lifecycle). Phase 47 Credit Management Engagement (operational engagement; substrate co-located; instance of engagement-as-universal-adapter for an infrastructure case). Phase 38 declare-and-register grammar (rules as declared artifacts).
The Operator opened with the recognition that Loomworks's Terms of Use will need to explicitly explain where the platform sits with regard to the structural-defensibility discussion. The initial framing was Terms-of-Use-as-Memory-artifact: queryable through the Companion, versioned with attestation, contestable through normal Memory governance — a different kind of legal instrument than the standard SaaS Terms of Use.
This framing was correct but thin. It treated the Terms of Use as a category (Memory artifact) without naming the shape that category takes when it has to produce a legal document that ships outside Loomworks. The reframe — to engagement — fills that gap.
The Operator's reframe, captured in his own words:
> If the Terms of Use is an Engagement that renders the Terms of Use as an HTML page, then we get the benefit of both assertions and Rendered page.
This is the architectural move. The Terms of Use is an engagement. The rules live as assertions in the engagement's Memory. The render specialists produce the legal artifacts — HTML page, PDF, plain-text variant, per-jurisdiction variant — that ship outside Loomworks and serve as the legal instrument. Both shapes are first-class: the rules-in-Memory drive OVA enforcement and remain queryable/contestable inside Loomworks; the rendered artifacts serve the legal-document role outside Loomworks.
The recognition that landed: the Terms of Use is a worked instance of engagement-as-universal-adapter applied to a legal document. Not a new category, not a special case — an engagement, with all the discipline that implies, with the specific architectural shape that delivery engagements with strong resident scaffolding take.
Five claims this investigation will defend:
Working through the four rooms applied specifically to the Terms of Use case.
The Terms of Use Engagement's Memory holds engagement-specific rules as assertions. Other rules that the Terms of Use renders into legal form come from other Memory scopes that the engagement composes with — see §4 below for the full composition treatment. What lives in the engagement's own Memory:
Each engagement-scope rule is an assertion in the assertion-backed Memory of the engagement, with the full discipline of assertion governance:
Examples of what an engagement-scope assertion looks like:
What does not live in engagement-scope Memory — and instead composes from other scopes:
The Companion answering "what does the Terms of Use say about X" composes across the relevant scopes — engagement scope for Loomworks-specific commitments, organization scope for organization-level rules, jurisdiction scope for regulatory provisions — and produces an answer that reflects all of them. The composition is invisible to the Operator in the same way the composed render is invisible: they see the result, not the assembly process.
Manifestation in this engagement assembles the rules into the structure a legal document needs but stops short of producing the document itself. This includes:
Manifestation is the assembled-but-not-yet-rendered view of the rules. It's what you'd query if you wanted to ask "show me the full current rule set as it would appear in the legal document, organized but not yet styled." This is the query surface for Operator-facing "what are the current Terms of Use" questions — the Companion reads from Manifestation, not from raw Memory.
Shaping holds the shape that produces a legal document from the organized rules. This is a declared shape (Phase 38 declare-and-register pattern) specifying:
Shaping itself versions. When the legal-form conventions change (a new jurisdiction is added; a regulatory requirement mandates a new formatting standard; a Terms of Use restructure happens), the shape changes through normal Shaping governance. Shape changes are themselves attested.
Shaping is what render specialists consume to produce the legal artifacts. The shape is the contract between the rules-as-Memory and the legal artifact that ships.
Render specialists in this engagement produce the legal artifacts that ship outside Loomworks. Each render is a specific point-in-time projection of the rules (per Manifestation) into legal form (per Shaping):
Each rendered artifact carries a document version identifier — typically a hash of the underlying Manifestation plus the Shaping plus the render specialist's version. The identifier is FORAY-attested at production. The artifact is then made available through whatever distribution channel the legal document requires (the platform's marketing site, a versioned URL, a downloaded file).
Each artifact has legal force as of its render. A subsequent rule change in Memory doesn't change the previously-rendered artifact (which would be a problem for legal certainty); it produces a new render with a new document version, and the relationship between document versions is itself attested (this is document version 3, superseding document version 2 as of date X, with the following rule changes between them).
This is where the architecture creates bilateral terms materially.
Every fleet Operator (across all engagements they participate in) is also an Operator of the Terms of Use Engagement, but with a specific scope:
This is not a comment box. It is structural participation in the Terms of Use Engagement's Memory governance. Operators have standing — their contributions are attested artifacts, attributable to them, present in the engagement's Memory, queryable by the Companion, visible to DUNIN7's team.
The platform's response to Operator contributions is itself attested. When DUNIN7's governance team reviews objections, acts on them (amending a rule, declining to amend, providing clarification), the response is an event in the engagement's history. Operators can see the response trail for their contributions; the aggregate pattern of objections-and-responses is itself a Memory artifact.
This is what bilateral terms looks like architecturally. The platform writes the rules; the Operators have standing to engage with them; the engagement preserves the engagement.
The Terms of Use Engagement versions on two axes simultaneously, and the relationship between the axes is architecturally interesting.
Each individual rule (each assertion in the engagement's Memory) has its own version history through normal Memory governance:
The rule version is a property of the rule itself, independent of when any legal document is rendered. Two rules can have different version histories; rule R1 might be on its third version while rule R2 is on its first.
Rule versions are queryable through the Companion ("show me the history of the rule about X") and through Memory tooling. Rule supersession threading is the normal assertion-supersession pattern; nothing exotic.
Each rendered legal artifact is produced from a specific point-in-time Manifestation plus a specific point-in-time Shaping. The combination produces a document version — a coherent legal artifact that's a point-in-time projection of the rules.
Document versions are coarse-grained relative to rule versions. Rule changes accumulate in Memory; periodically (or on threshold), DUNIN7's governance team triggers a new document render, which carries a new document version. The document version is the unit of legal force — when an Operator accepts a document version, they're accepting the specific rule set in effect at that render.
The relationship between rule versions and document versions is many-to-one: a document version corresponds to the rule versions in effect at the moment of its Manifestation. The diff between two document versions can be expressed as the set of rule version changes between them.
The two axes are related but distinct, and the distinction is load-bearing:
The two-axis pattern generalizes beyond the Terms of Use. Any engagement whose renders are point-in-time projections of slower-moving rule sets — privacy policy, code of conduct, data processing addendum, partnership agreements, regulatory disclosures — follows the same two-axis pattern. This is methodology-finding-grade and worth absorbing in v0.21.
The Operator's acceptance is to a document version, not to the latest rule set. When the Operator accepts document version 3, they're accepting the specific rule set that was in effect at the rendering of document version 3. Subsequent rule changes accumulate in Memory but don't affect the Operator's accepted version until a new document version is rendered and the Operator either accepts it explicitly or operates under terms-acceptance discipline (which is itself a rule in the engagement's Memory governing how new versions take effect).
This is structurally important for several reasons:
This is materially better than standard SaaS Terms of Use, where the "accept latest version" pattern often binds Operators to changes they never saw, with no audit trail of what was in effect when.
The Terms of Use Engagement is a worked instance of N-domain composition (see loomworks-engagement-domain-composition-investigation-v0_1.md for the methodology principle). The Terms of Use composes from multiple Memory scopes; the rendered legal document is the composition's projection; OVA's authorization at every consequential step composes the same scopes; FORAY's attestation captures the composition's rule context.
For a DUNIN7-operated Terms of Use Engagement, the composition typically draws from:
The composition is N-neutral; if other scopes apply, they're composed in. The architecture doesn't fix the count.
When a render specialist produces the legal document, it composes across the relevant scopes:
The render specialist's job is to compose these into a coherent legal document — the structural commitments framed in DUNIN7's voice within the jurisdictional regulatory floor for the appropriate audience. The result is a single HTML page (or PDF, or plain-text variant) that reads as one coherent document but is mechanically composed across scopes.
The document version identifier (introduced in §4) captures the composed state: this is document version 3, produced at time T, from engagement scope at rule-set V1, organization scope at version V2, jurisdiction scope at version V3, audience-variant selection V4. The composition is attested in FORAY at production time. The rule-set state across all the scopes that contributed is recoverable from the document version identifier.
OVA enforces by composing rules from the same scopes:
When OVA decides permit-or-deny on a consequential operation, it composes the relevant rule states across all the scopes that bear on the decision. The decision is governed by the composed rule set, not by any single scope alone. The composition facets (hierarchical floor; orthogonal contribution; override with attestation — see the composition investigation §3.2) operate within this composition.
This is what makes the legal document and the enforcement substrate mechanically linked across all the scopes that govern the decision. The composed render and the composed enforcement draw from the same composition of scopes; the document the Operator reads is the rules the architecture is enforcing, in a different representation.
The multi-instance fleet topology (Section 7.1 in queued directions v0.10) gives each instance its own jurisdiction posture. The Terms of Use Engagement composes with the instance's jurisdiction Memory; different instances compose with different jurisdiction Memories; the rendered legal documents reflect the differences mechanically rather than by parallel drafting.
This is more architecturally clean than maintaining separate Terms of Use per jurisdiction. The engagement-scope rules (Loomworks structural commitments) are the same across jurisdictions; the organization-scope rules (DUNIN7's commitments) are the same; what varies is the jurisdiction-scope contribution. Composition handles the difference automatically; the Operator sees a Terms of Use that reflects their jurisdiction without DUNIN7 maintaining N parallel documents.
For a managed-hosting tenant (call them Tenant T) running their own Loomworks instance, the composition substitutes the organization scope:
T's Terms of Use renders as T's brand-shaped document, satisfying T's jurisdiction, with Loomworks platform commitments included structurally. The platform-floor scope is what makes this clean — Loomworks commitments are honored without DUNIN7's organization having to be in T's composition.
This is the white-label and managed-hosting case worked through cleanly. The composition pattern supports it without per-tenant codebase forks; the architecture composes differently based on which scopes are in play for the specific instance.
This is what makes the architecture's defensibility claim mechanically true rather than rhetorical. The relationship operates through composition — OVA composes rules from N scopes at decision time; FORAY attests with composed context. See §5.3 above for the composition treatment; this section adds depth on how OVA and FORAY specifically operate.
At every consequential step, OVA consults the rules. The rules are composed across N Memory scopes — the Terms of Use Engagement's own Memory plus organization Memory plus jurisdiction Memory plus any other scope in play. OVA reads from all the relevant scopes at decision time. The decision — permit, deny, conditionally permit — is governed by what the composed rule set says at that moment.
This means several things:
The rules-as-Memory aren't a separate description of the rules. They are the rules. And the composition makes them coherent across the scopes that govern the operation.
Every attested event in FORAY can be tied to the composed rule context in effect at the time. When OVA decided, it composed rules from N scopes; FORAY records the decision and the rule versions across all the scopes consulted. The audit trail is therefore complete in a way most platforms' audit trails are not — it shows the full composed rule context that governed the decision, not just one rule from one scope.
This has consequences for compliance investigation. "Did the platform comply with rule R at time T" becomes a queryable question with a real answer: "show me the FORAY trail of all operations affected by rule R between time T and time T+1; show the composed rule context in effect (R's scope rule version, plus interacting rules from other scopes); show the decisions and outcomes." No forensic reconstruction; mechanical query across composed context.
Worth noting that this composition-attested approach is materially stronger than what most platforms' audit trails can produce. Most platforms record "operation O happened at time T with parameters P." Loomworks records "operation O happened at time T with parameters P, under composed rule context [E1@V1, O1@V2, J1@V3, A1@V4], producing decision D, with outcome X." Investigation becomes a query against composed context rather than a reconstruction.
The strongest claim the architecture supports: the legal document the Operator reads is the composed rule set the architecture enforces, in a different representation. Not a description of the rules; the rules themselves, composed across N scopes, rendered into legal form.
This is what makes Loomworks's Terms of Use structurally honest in a way most platforms' Terms of Use cannot be. Most platforms have a legal document drafted by counsel; behavior is governed by code that may or may not faithfully implement what the document says. The gap between document and behavior is where most compliance failures live. Loomworks closes the gap by making them the same composed content. Engagement scope contributes the Loomworks-specific commitments; organization scope contributes the platform's voice and posture; jurisdiction scope contributes the regulatory floor; render specialist composes them into the legal document; OVA composes the same scopes at every consequential decision. The document and the behavior are mechanically linked across the composition.
This is what N-domain composition adds to the defensibility argument that v0.1 of this investigation didn't fully name: not just that the rules live in Memory, but that they live across multiple Memory scopes, composed at the moment of every consequential operation, attested by FORAY with composed context. The composition is what makes the architecture's defensibility genuinely structural rather than relying on any single scope's discipline alone.
A few worked examples.
Operator: "Can I export my engagement Memory to an external tool?"
Companion (consulting Terms of Use Engagement's Memory): "Under the current Terms of Use (document version 3, effective 2026-04-15), Operators retain ownership of content held in their engagements' Memory (rule 4.1) and may export it through the platform's export API (rule 7.3, subject to format limitations described in Manifestation §7). The export operation is OVA-authorized and FORAY-attested. The export does not include shape-only metadata that has been emitted to Observer (rule 12.2). Would you like me to walk through the export process?"
The Companion's answer is computed from real rules. The rules are queryable. The Operator gets a substantive answer, not "please consult the legal document."
DUNIN7's governance team is considering an amendment to rule 12.2 (Observer's content-shape boundary). Before contributing the amendment, the team checks which scope the rule lives in. Rule 12.2 is a Loomworks-specific structural commitment about how the platform operates — it lives in engagement scope (the Terms of Use Engagement's own Memory).
The amendment is contributed to engagement-scope Memory, goes through held-then-commit: held at time T, reviewed by governance team, committed at time T'. The amendment is attested.
The amendment doesn't immediately produce a new document version. It exists in engagement-scope Memory; governance team can see it; OVA's next composition picks it up automatically — at the next consequential operation, OVA composes the new rule 12.2 with the unchanged organization-scope and jurisdiction-scope rules, and the composed decision reflects the amendment.
At time T'', DUNIN7 decides the amendment warrants a new document version. A render is triggered; the render specialist composes the current state across engagement scope (now including the amended rule 12.2), organization scope (unchanged), and jurisdiction scope (unchanged); it produces document version 4 from the composition; the new render is attested with its document version identifier and the composition's rule-set state across all scopes.
Operators are notified of the new document version. Acceptance ceremony follows.
Worth noting: not every rule change requires a new document version. If the change is in jurisdiction-scope Memory (a regulatory update applies to the EU instance), the change propagates automatically to OVA's composition for operations in that instance; whether a new document version is rendered is a separate governance call. The architecture distinguishes rule change (immediate at OVA) from document version (rendered artifact). The composition makes both axes work independently while staying mechanically linked through FORAY attestation.
Operator: "I don't agree with rule 8.4 about retention."
Companion: "Understood. Would you like to register a formal objection to rule 8.4? Your objection will become a contribution to the Terms of Use Engagement's Memory, attributable to you, and visible to DUNIN7's governance team for review."
Operator: "Yes, register the objection."
Companion: [creates the contribution, held; surfaces it for Operator approval; commits]. "Your objection is registered with attestation [hash]. DUNIN7's governance team will see it in their review queue. You'll receive a response when they've considered it."
The objection becomes a Memory artifact in the engagement. DUNIN7's team sees it through their Operator Layer for the Terms of Use Engagement. The team's response — amendment, declination, clarification — is itself an attested event. The Operator can see the response trail.
This is structural participation. Not "we welcome feedback at support@..."; actual standing in the engagement's Memory governance.
Regulator: "Show me how the platform handled data export requests from EU-resident Operators in Q1 2026 with respect to GDPR Article 20 portability."
The architecture's answer: "Here is the FORAY trail of export operations originating from EU-jurisdiction instances in Q1 2026. Here is the composed rule context in effect for each operation — engagement-scope rule 7.3 (data portability commitment) at its version, organization-scope rule O5 (DUNIN7's customer-data policy) at its version, jurisdiction-scope rule J12 (GDPR Article 20 implementation) at its version. Here are the OVA decisions and their outcomes under the composed context. Here is the document version of the Terms of Use in effect at each operation. Here are any objections contributed by Operators about the composed rule set in this period. Here is the platform's response trail."
Mechanical. Auditable. Composed across scopes. The substrate produces the compliance answer rather than requiring reconstruction.
Tenant T operates a managed-hosting Loomworks instance. T wants to publish a Terms of Use for their own Operators. T creates a Terms of Use Engagement in their instance.
The engagement composes:
The render specialist composes these into T's Terms of Use. T's document looks like T's brand, satisfies T's jurisdiction, addresses T's Operators, and structurally honors Loomworks platform commitments (which Operators on T's instance see attributed to "the Loomworks platform" or whatever framing T's organization scope establishes for that relationship).
DUNIN7 didn't have to write T's Terms of Use. T didn't have to re-implement Loomworks platform commitments. The composition handled the separation. T's brand and Loomworks' commitments coexist in the same rendered document because they sit in different scopes.
Three recognitions for v0.21 consolidation.
The Terms of Use Engagement validates the engagement-as-universal-adapter principle by demonstrating its reach. Engagement-as-universal-adapter wasn't obviously going to absorb legal documents when it was first articulated for things like Credit Management. The fact that it does — cleanly, with all the discipline that implies — is methodology-finding-grade. The pattern extends further than the initial articulation suggested.
This generalizes: the engagement-as-universal-adapter principle should be tested against more candidate domains, not just affirmed for the obvious ones. The Terms of Use is one test; legal documents in general (privacy policy, code of conduct, partnership agreements, regulatory disclosures) are others. The pattern works wherever the substrate is rules or claims that get rendered into specific artifacts at specific moments.
The rule-version-plus-document-version pattern is not specific to Terms of Use. It generalizes to any engagement whose renders are point-in-time projections of slower-moving rule sets. The relationship between the axes — rule changes accumulate in Memory; document changes capture rule-set states; FORAY attests both — is the general pattern.
Worth absorbing as a methodology principle: for engagements whose renders carry legal or commitment force, design two-axis versioning into the engagement's architecture from the start. The pattern doesn't have to be invented for each such engagement; the discipline is reusable.
Most SaaS Terms of Use are unilateral. The platform writes them; the user accepts; engagement ends. Loomworks's architecture creates a different shape — Operators have read-scope on rules plus contribution-scope for objections, both materially expressed in the engagement's Memory governance. This is bilateral terms expressed structurally, not asserted in marketing copy.
The methodology recognition: when the architecture allows it, give Operators structural participation in the platform's commitment artifacts rather than treating commitments as unilateral. This composes with the Operator-authority principle in the manifest and with the structural-defensibility principle from the prior investigation. It's not a feature; it's a posture about what kind of platform Loomworks is.
The Terms of Use Engagement is the canonical worked example of N-domain composition (filed in loomworks-engagement-domain-composition-investigation-v0_1.md). The legal document composes from engagement scope, organization scope, jurisdiction scope, and potentially audience or partner scopes. OVA composes the same scopes at every authorization decision. FORAY attests with composed context. The legal document and the enforcement substrate are mechanically linked across the composition.
This worked instance validates N-domain composition by demonstrating that it absorbs cases (legal documents) where the composition is genuinely load-bearing — not optional, not nice-to-have, but the only architectural shape that lets the rendered document and the enforcement substrate stay coherent across the scopes that govern decisions. Methodology v0.21 absorption should foreground the Terms of Use Engagement as the canonical example for both the engagement-as-universal-adapter principle and the N-domain composition principle, as a paired pair of worked instances.
The recognition moved through four distinct turns across two document versions:
Each turn refined what the prior turn left underspecified. The pattern matters for trajectory preservation: the Terms of Use Engagement framing didn't land in one move, and the N-domain composition recognition that v0.2 absorbs didn't land in one move either. Future readers reconstructing the path should see all four turns — and especially the two corrections from Claude's drafting (from "Memory artifact" to "engagement," and from "two domains" to "N domains"). Both corrections share a discipline: don't commit the methodology to a fixed count or category when the architecture is naturally neutral. The methodology stays neutral about counts; the supplied domain (composed across N scopes) determines the specifics.
The v0.21 consolidation should absorb the following from this investigation:
loomworks-engagement-domain-composition-investigation-v0_1.md). The two recognitions — engagement-as-universal-adapter and N-domain composition — pair naturally; the Terms of Use Engagement validates both.The Terms of Use Engagement is buildable against existing substrate. What's missing is:
The natural build trigger is when DUNIN7 needs a real Terms of Use document for public-facing use. This is gated on marketing-site work or similar Phase 51+ landmarks. The cross-reference in Section 13 of queued directions v0.10 surfaces this.
A short cross-reference in queued directions surfaces this investigation for discoverability. Future readers searching for "Terms of Use," "legal document," "rules in Memory," "compliance," "regulatory artifact," or "bilateral terms" find the cross-reference and follow it here.
DUNIN7 — Done In Seven LLC — Miami, Florida Loomworks — Terms of Use Engagement Investigation — v0.2 — 2026-05-11