DUNIN7 · LOOMWORKS · RECORD
record.dunin7.com
Status Current
Path discovery/loomworks-discovery-note-domain-reference-model-v0_1.html

Loomworks · Discovery note · C5 input

Loomworks — Discovery note: the domain reference model

Version 0.12026-06-05DUNIN7 · Done In Seven LLC

Status. Discovery note. Captures the reasoning from the seed v0.10 amendment session about how an engagement relates to the scopes above it. Input to C5 (the Domain layer) scoping; not a scoping note, not a CR. Records positive and negative paths so the trajectory is reconstructable.

Plain-language summary

While amending the seed to widen Memory to N-scope (v0.10), a worked example — a denim-jeans engagement drawing on a denim-heritage domain and a cotton-production domain — surfaced four design questions that the seed itself does not answer but that C5 must. This note records what was decided in principle and why, so C5 starts from settled reasoning rather than re-deriving it.

The four findings, in brief: 1. Two relationships, not one. An engagement relates to scopes above it by membership (single chain) and by reference (many, orthogonal). These are different mechanisms. (This one landed in seed v0.10.) 2. References are non-transitive, and that is what makes the diamond safe. A Shaping composes the engagement's declared references; it does not silently walk references-of-references. Combined with dedup-by-identity, this makes a diamond-shaped reach graph safe without special handling. 3. Two access modes: open ("all") by default, restricted (ACL via OVA) by exception. (This one landed in seed v0.10.) 4. The Companion surfaces domains for consideration. The Operator does not curate a domain catalog; the Companion proposes relevant domains during engagement discussion, and the Operator approves the reach. A direction for C5 / engagement-creation, permitted by the existing Companion-as-Operator-system-interface commitment.


The worked example this came from

An engagement for the manufacture and marketing of a current denim jeans brand. It accumulates its own Memory — manufacturing detail, marketing, brand specifics. Above it sit two domains holding knowledge no single engagement owns: a denim domain (denim's history, including the Levi's origin story — anecdotal, narrative material) and a cotton domain (the cotton-growing economy, yarn and thread production).

A particular Shaping — say a brand story presenting the jeans and how they are made — reaches into both domains and composes relevant material from each alongside the engagement's own content. A different Shaping — a wholesale buyer's spec sheet — reaches the same domains but selects almost nothing anecdotal. Same Memory, same Manifestations, different reach, different selection.

This is the confirmed path: composition across scopes happens in Shaping, from several single-scope Manifestations. Manifestation never merges scopes. (Seed v0.10, confirmed by the Operator.)


Finding 1 — two relationships: membership and reference

The example exposed a false framing in the seed draft. The draft said an engagement "belongs to an organization, which may belong to a domain, and so on up the chain" — a single-parent chain. But the denim and cotton domains are not a chain over the engagement, and they are not above each other. Cotton is not denim's parent; they are peers.

The correction: there are two distinct relationships.

  • Membershipwho the engagement belongs to. Normally a single chain: an engagement belongs to one organization, which belongs to one parent. Singular in the common case. (Exception: the shared-subject pattern, where an engagement is jointly operated by two organizations — multi-parent membership. Rare, real, must be expressible.)
  • Referencewhat bodies of knowledge the engagement draws on. Normally many: a set of peer domains, each reached for its own kind of knowledge, none above the other.

The denim-jeans engagement: membership → its brand organization (one). Reference → denim domain + cotton domain (several, orthogonal).

Why this matters for C5. A tree (single-parent) literally cannot represent "references denim AND cotton as peers." Reference must be a fan-out. But membership need not pay graph costs in the common case — it is a chain. The model is therefore two axes: a membership relationship (a chain, mostly) and a reference set (a typed fan-out). Collapsing them into one "fan-out" loses that membership is usually singular; collapsing them into one "tree" makes orthogonal references inexpressible.

Use cases tested (each demanded fan-out references; membership stayed a chain except the shared-subject case): - Law firm litigation matter: belongs to firm (chain); references case-law domain + jurisdiction (floor) + industry domain. - Clinical trial: belongs to sponsor (chain); references disease-area + regulatory jurisdiction(s) + protocol-design + statistics. Two-jurisdiction trials reference two flooring scopes that may conflict. - Agricultural engagement: belongs to operating org (chain); references crop agronomy + regional climate + local regulation + commodity market. - Single-domain internal training course: belongs to org (chain); references only the org's own brand. Chain alone suffices — fan-out must not be mandatory. - Cross-organization shared subject: multi-parent membership — the case that breaks pure single-chain membership. - Second product line (denim jackets) reaching the same denim + cotton domains: the payoff case — shared domains compound; authored once, reached by many engagements.


Finding 2 — references are typed, and non-transitive

References are not uniform. At least three flavors, which Shaping must compose differently: - Additive / anecdotal (denim heritage) — pure color, freely composable, "pull if relevant." - Hierarchical floor (jurisdiction rules) — must apply, cannot be overridden by engagement convenience, and same-type floors can conflict (two jurisdictions) requiring resolution by specificity-or-strictness. - Contextual (regional climate) — weights/shapes output without hard-constraining.

An untyped reference graph is the expensive case; a typed reference set is tractable, because each edge declares how it composes. C5's composition rules attach to the type.

The diamond hazard, and the rule that dissolves it. The Operator drew two routes to cotton:

Brand Jeans ──> Denim ──> Cotton      (cotton reached via denim)
Brand Jeans ──────────────> Cotton    (cotton reached directly)

This is the classic diamond. Its hazards: double-pull (same assertion composed twice), provenance ambiguity (why is cotton here — direct sourcing, or denim's mention?), and conflict-resolution ambiguity (which path's precedence applies to a cotton floor?).

The resolving rule: reference edges are non-transitive. A Shaping composes the engagement's own declared references. It does not automatically walk references-of-references. So: - If the brand wants cotton directly (its own sourcing, sustainability claims) → declare Brand Jeans ──refs──> Cotton. Explicit, attributed to a direct brand decision. - If cotton matters only because denim's heritage story invokes it → do not declare it; it arrives inside denim's material, as denim's assertion, attributed to denim. - If both → one direct edge (brand→cotton) plus cotton-inside-denim. Dedup-by-identity composes any shared assertion once; the two reasons are both preserved because one is a brand-level reference and the other is denim-level content. Provenance stays clean.

Note the false arrow in the Operator's diagram: Denim ──> Cotton is not membership (denim does not belong to cotton). It is denim's own reference to cotton (denim knowledge invokes cotton). Once membership and reference are separated (Finding 1), the diamond is well-defined and safe.

Opt-in depth, never automatic. There is a real case where a Shaping wants denim's references as first-class (the heritage story wants deep cotton context, not just denim's mention). This must be an explicit Operator/Shaping choice — "also reach denim's references" — never an automatic transitive walk. Opt-in preserves operator-authority over what gets reached. Default reach depth is 1.


Finding 3 — two access modes (landed in seed v0.10)

A scope's Memory is reachable in one of two modes: - Open ("all") — the default. Reachable by any engagement, any Operator. Default because a knowledge commons compounds when knowledge is open. - Restricted — an access-control list established through OVA. From that point OVA governs reach; only the permitted may reach the scope.

Open-by-default, closed-by-exception. A scope is open until an ACL is established on it. Establishing an ACL is the deliberate, recorded act that restricts. This is the right posture for a knowledge commons (denim/cotton domains open so engagements compound) and it makes restriction an explicit decision, not a default someone forgot to change.

The OVA-stub period, stated honestly. Today OVA does not enforce, so every scope is effectively open. This is not the same as "all" being a placeholder. "All" is a permanent, first-class mode. The access mode is seam-declared now, so that when OVA enforces, scopes carrying an ACL become restricted and the rest stay open. The Operator was explicit: the model must support both restricted (ACL via OVA) and open ("all"); they are distinct commitments. Open is open by design.

Operator's phrasing of the rule: all by default; if OVA is present (an ACL exists on the scope), OVA is now in control.


Finding 4 — the Companion surfaces domains for consideration

The fan-out reference model creates a burden: someone has to know which domains exist and curate the engagement's reach set. That someone must not be the Operator studying a scope taxonomy — the seed's voice principle forbids requiring the Operator to understand technical structure.

The flow. As the Operator discusses the engagement with the Companion (manufacturing, marketing, the brand story), the Companion notices the subject touches denim and cotton and surfaces those domains: "There's a denim domain with heritage knowledge, and a cotton domain covering sourcing and production — want this engagement to draw on either?" The Operator says yes/no/which. The reach set is built from the Operator's intent, in plain conversation.

Why this fits. The manifest records Companion-as-Operator-system-interface as a settled principle (Phase 60): the Companion is the primary surface for Operator-system interaction, not just chat. Domain reach is exactly that. So the seed does not need to grow to permit this — the existing commitment already covers it. This is a direction for C5 / engagement-creation, recorded here, not seed text.

Three disciplines it must honor: 1. Surface and signal; the Operator approves. The Companion proposes a reach; it must not establish one automatically. Auto-wiring a reach the Companion inferred is an automatic state transition on an artifact the Operator has authority over — the category error the seed names. Companion suggests → Operator confirms → reach edge created with the Operator recorded as the actor. (This also keeps every reference edge traceable to an Operator decision, which is what made the diamond safe in Finding 2.) 2. The suggestion is not the reach. Surfacing "denim domain exists and seems relevant" is a proposal, not composition. It does not pull denim's content. Composition still happens later, in Shaping, from declared edges. Do not let surfacing collapse the Memory → Manifestation → Shaping ordering. 3. Honest about access (Finding 3). The Companion surfaces open ("all") scopes freely and restricted scopes only to Operators whose OVA check passes. It must not surface a restricted scope to an Operator who cannot reach it as if it were available ("only show what is available"). Until OVA enforces, this is permissive, but the seam is there.

A quieter benefit. The Companion surfacing "denim domain (already used by N engagements)" is how domains get discovered and reused — the compounding thesis operating at engagement creation. The Companion becomes the matchmaker between an engagement and the existing body of domain knowledge. Strong product idea; downstream of getting the reach model right.


What landed in seed v0.10 vs what is C5's

In seed v0.10 (because leaving it out invited the false-hierarchy reading): - Two relationships: membership (chain) and reference (many, orthogonal). Memory section. - Two access modes: open by default, restricted via OVA. Memory section + constraints.

Left to C5 scoping (specification-level; this note is the Discovery-record input): - The typing of references (additive / floor / contextual) and the composition rules per type. - The non-transitive rule and its opt-in-depth exception. - Conflict resolution across same-type scopes (two jurisdictions). - Dedup-by-identity at composition. - Multi-parent membership for the shared-subject exception. - The Companion-surfaces-domains flow and its three disciplines. - When/who/freshness of upper-scope Manifestations (the open question from the seed session: a domain scope may have no single Operator to trigger its derivation — unresolved, named for C5).


Provenance

This note records reasoning from the seed v0.10 amendment session (2026-06-05), Operator Marvin Percival. The worked denim/cotton example, the diamond diagram, the "all by default; if OVA present, OVA controls" access rule, and the Companion-surfacing-domains direction are the Operator's; the structuring into findings and the non-transitive-diamond rule are the session's synthesis. Seed v0.10 is the artifact this note accompanies.


DUNIN7 — Done In Seven LLC — Miami, Florida Loomworks — Discovery note: the domain reference model (C5 input) — v0.1 — 2026-06-05

DUNIN7 — Done In Seven LLC — Miami, Florida
Loomworks — Discovery note: the domain reference model (C5 input) — v0.1 — 2026-06-05