Loomworks — role-vocabulary reconciliation scoping note — v0.1

Document: loomworks-role-vocabulary-reconciliation-scoping-note-v0_1 Version: 0.1 Date: 2026-06-05 Role: Scoping (produces a scoping note — not a CR, not seed text, not build artifacts) Operator: Marvin Percival — DUNIN7 (Done In Seven LLC, Miami, Florida) Canonical home: loomworks-record (technical scoping document — Markdown primary; HTML companion optional) Status: Blocks seed v0.11. Holds the C5 CR behind it.

Plain-language summary

This note exists because the seed v0.11 amendment hit friction and halted. v0.11 was meant to add a domain write-access axis and the role that admits contributions into a shared domain. Pulling the canonical role definitions before drafting revealed that Loomworks carries two parallel, unreconciled role taxonomies, and the word "Contributor" means two opposite things depending on which one you read. A seed amendment about who may contribute to a domain cannot be written on a word whose meaning is internally contradictory.

The decision needed: which role vocabulary governs the seed, and how do the two taxonomies relate. Once that is settled, seed v0.11 is mechanical.

This note does not pick the answer. It lays out the two taxonomies, the six mismatches, the three distinct functions that were being conflated under one word ("Steward"), and a recommended resolution for the Operator to accept or correct. It also records the corrections this discovery forces on the C5 scoping note — as before/after statements, not silent edits.

In scope: surfacing the two-taxonomy fork; the six vocabulary mismatches; the three distinct admit/propose/review functions; a recommended resolution; the corrections to the C5 scoping note.

Out of scope: writing seed v0.11 text (waits on this decision); reconciling the philosophy doc and methodology documents themselves (a larger downstream act this note may trigger); building anything.

1. Why this halt happened (the trajectory)

The sequence, preserved so a Discovery record can reconstruct it:

C5 scoping (this session, earlier) produced the domain reference model and a contribution-authority finding: Contributor proposes into a domain; Domain Steward elevates from a review queue; elevation is the derivation trigger. Flagged as requiring seed v0.11.
We moved to draft seed v0.11. Per discipline, CC re-pulled the seed's current Memory and Authorisation sections rather than drafting from memory.
The grep surfaced that "Steward" is not in the seed body — only a C5-deferred placeholder in the drafter's notes — and that the seed already carries a three-role framework ("Operator, Reviewer, Contributor") in which "Steward" does not appear.
A prior position was formed and then corrected: proposed — "the Domain Steward is the seed's existing Reviewer role exercised at domain scope" (would add zero new roles). To test it, CC pulled the canonical role definitions from all sources.
The canonical pull disconfirmed that proposal and surfaced a deeper problem: two taxonomies, an inverted word, and three distinct functions being conflated. The amendment halted here.

The halt is correct. The friction is structural (a vocabulary fork), not a wording choice, and absorbing it inside the v0.11 amendment would smooth a real Operator decision instead of surfacing it.

2. The canonical sources and where they live

| Source | Location | Framing | Names the roles | |---|---|---|---| | Philosophy & architecture doc v0.1 | loomworks-engine:docs/discovery-records/loomworks-philosophy-and-architecture-v0_1.md (§5 The three roles; §6 Engagement lifecycle) | medium / product | Operator, Reviewer, Contributor | | Methodology v0.20 | loomworks-engine:docs/methodology/what-dunin7-is-building-v0_20.md (§Contribution trust; §Identity; §Domains, engagements, and roles) | substrate / methodology | participant, contributor, operator, domain-expert designation, trusted core / trusted contributor | | Knowledge-elevation investigation v0.1 | loomworks-record:investigations/loomworks-knowledge-elevation-pathway-investigation-v0_1.md (§5, §6.4) | investigation (open) | domain steward, founding governor | | Memory-space investigation v0.1 | loomworks-record:investigations/loomworks-memory-space-extensibility-investigation-v0_1.md (§5.5; line 106) | investigation (open) | org/team/role stewards; proposer / authorizer / admitter |

The seed cites the philosophy doc. The seed's Authorisation section uses the methodology's base-Contributor sense. So the seed itself already mixes the two framings.

3. The two taxonomies, side by side

Philosophy doc — a promotion ladder (product framing)

Operator — the inventor whose work the engagement is; authority within their engagement is absolute. Invites and promotes the others. Scope: one engagement.
Reviewer — an external domain expert invited by the Operator to contribute substantive input to one engagement at a specific stage (Stage 2). Reviews/reacts; rated privately by the Operator. Scope: one engagement.
Contributor — a Reviewer the Operator has promoted (Stage 3) into internal collaboration; can propose direction, not just react. Senior to Reviewer. Scope: one engagement.

Progression: Reviewer → Contributor → (Operator owns). Roles describe relationship to a specific work, not career status.

Methodology v0.20 — a nesting (substrate framing)

participant — anyone who interacts, including read-only consumers. Scope: environment. Bottom of the nest.
contributor — a participant who writes into memory. Base write role. Scope: per-engagement designation.
operator — a contributor in a lead role; responsibility and continuity for an engagement. Top of the nest.
domain-expert — a designation (a recognized-expertise badge), distinct from governance or participation; does not by itself grant write or govern authority.
trusted core / trusted contributor — within a domain's trust graph, the vetted contributors who write directly and admit or reject newcomers' queued writes. Domain-level governance, "adopts whatever fits."

Nesting: every operator is a contributor; every contributor is a participant.

The collision in one line

Philosophy "Contributor" = senior (promoted Reviewer). Methodology "Contributor" = base (any participant who writes). Same word, inverted seniority. This is the disqualifying mismatch for a seed amendment about contribution.

4. The six mismatches (CC-surfaced, not reconciled here)

"Contributor" means two opposite things — senior (philosophy) vs base (methodology + seed Authorisation). Highest-risk collision. The seed already carries both senses inconsistently.
Two different three-role taxonomies — Operator/Reviewer/Contributor (ladder) vs participant/contributor/operator (nest) + domain-expert designation. "Reviewer" and "participant" each exist in only one.
"Reviewer" is canonical in the philosophy doc but absent from the methodology and the seed body — though the seed's longer-horizon section cites it.
"Steward" is undefined in the canonical role docs — a proposed, "genuinely open" role in two investigations; a deferred placeholder in the seed. No settled definition to collide with, but none to rely on either.
"Domain expert" is overloaded — a methodology designation (a badge) vs the philosophy doc's descriptive use ("an external domain expert invited as a Reviewer").
The write-admission function has three different names — "trusted contributor" (methodology), "admitter" (memory-space lift model), "authorizer" (the human-approval step in the lift). None called "Reviewer" or "Steward."

5. The three distinct functions we were conflating

The C5 scoping note used "Domain Steward" for what turns out to be three separate functions in canonical/investigation text. Naming them apart is the core clarification:

| Function | Canonical name | What it does | Source | Status | |---|---|---|---|---| | Admits a queued contribution into composable domain Memory | trusted contributor (of the trusted core) | promotes or rejects newcomers' queued writes; writes directly | methodology v0.20 §Contribution trust | canonical, settled | | Proposes a cross-Operator promotion across many engagements | domain steward | a designated domain expert who watches for promotion candidates across member engagements and proposes elevation | knowledge-elevation investigation §5/§6.4 | proposed, "genuinely open" | | Reviews/contributes input to one engagement, invited and rated | Reviewer | invited outside expert; substantive input at a stage; rated privately by the Operator | philosophy doc §5/§6 | canonical (product framing) |

The admitter is the trusted contributor — not the Steward, not the Reviewer. The C5 scoping note's "Domain Steward elevates from the queue" was the trusted contributor function under the wrong name. The "Steward" is a different role (cross-Operator proposer) that the C5 open question §4.1 was actually about. We collapsed admitter and proposer into one word; the sources keep them apart.

6. Corrections this forces on the C5 scoping note (before/after, preserved not smoothed)

The C5 scoping note (loomworks-c5-scoping-note-domain-reference-model-v0_1, on origin/main at fe2bd86) stands, with these corrections recorded:

Before: "Domain Steward elevates a proposed contribution from the queue into composable Memory." After: the admitting role is the methodology's trusted contributor (member of the domain's trusted core). "Domain Steward" is a different role — the cross-Operator promotion proposer (knowledge-elevation investigation) — which belongs to open question §4.1, not to the admit gate.
Before (this session, set aside): "the Domain Steward is the seed's Reviewer exercised at domain scope." After: disconfirmed by source. Reviewer is an invited, rated outside expert at engagement scope; the sources do not connect it to the trust-graph admitter, and on their face the functions differ.
Confirmed (no change): the seam-vs-policy split. Methodology v0.20 states trust-graph governance is domain-level, not infrastructure ("adopts whatever fits"). C5 scopes the seam (a gate exists, a queue exists, a trusted core admits); per-domain promotion policy stays open. This part of the C5 note holds.
Confirmed (no change): the trigger resolution. The admitter's act (a trusted contributor promoting a queued write) is what changes domain Memory and warrants re-derivation. The trigger logic is sound; only the role's name was wrong.

The C5 note does not need a new version yet — these corrections live here and fold into the C5 CR when it is drafted. If the Operator prefers, a C5 note v0.2 can absorb them; recommendation is to let the CR carry them, since the CR is where they take effect.

7. The decision the Operator must make

Which role vocabulary governs the seed? Three coherent options:

Option A — Methodology vocabulary governs (recommended)

The seed adopts the methodology's substrate framing: participant / contributor / operator + domain-expert designation + trusted core / trusted contributor for domain write-admission. The philosophy doc's Reviewer/Contributor ladder is reframed as longer-horizon product machinery layered on top, not the seed's base vocabulary.

Why recommended: the methodology is where the substrate is actually defined; the seed's Memory section and Authorisation section already use the base-Contributor sense; the trust-graph admitter (the exact function v0.11 needs) is canonical only in the methodology, with a settled name. Choosing the methodology means v0.11 introduces zero net-new role words — it uses "trusted contributor / trusted core," which already exist.
Cost: the philosophy doc's senior-Contributor sense must be explicitly demoted/reframed in the seed, and the seed's longer-horizon citation of "Operator, Reviewer, Contributor" must be annotated as product-framing, distinct from the base roles. The philosophy doc itself is left as-is for now (its reconciliation is §8 downstream work).

Option B — Philosophy vocabulary governs

The seed adopts Operator / Reviewer / Contributor as the promotion ladder, and maps the trust-graph admitter onto "Contributor (senior)."

Cost: contradicts the seed's own Authorisation and Memory sections (which use base-Contributor); requires renaming "every person at signup" away from "Contributor"; the trust-graph admitter has no clean home in this ladder (Reviewer is the reviewed party, not the gatekeeper). Higher churn, more collisions. Not recommended.

Option C — Defer the whole taxonomy; v0.11 uses only the function names

The seed v0.11 adds the write axis and names the admitting function ("a contribution is admitted into a domain's composable Memory by a member of the domain's trusted core") without committing the seed to either full taxonomy. The taxonomy reconciliation is deferred.

Why tempting: unblocks v0.11 immediately with the least commitment; uses the one settled term ("trusted core") for the one function v0.11 needs.
Cost: leaves the "Contributor" inversion unresolved in the seed, which will resurface at the next role-touching amendment. Defers the fork rather than settling it.

Recommendation: Option A, with the Option C function-naming as the v0.11 mechanism. Adopt the methodology vocabulary as the seed's governing role framework, and have v0.11 use "trusted core / trusted contributor" for the admit gate (which Option A and C agree on). This settles the inversion and unblocks v0.11 with no net-new vocabulary. The philosophy doc's ladder is annotated as product-framing and left for the §8 reconciliation.

8. Downstream this may trigger (named, not undertaken)

Philosophy-doc / methodology reconciliation. The two documents carry incompatible "Contributor" senses. Whichever the seed adopts, the other document eventually needs an annotation or amendment so the program's canon is consistent. This is larger than v0.11 and is its own commission. v0.11 does not require it — Option A only needs the seed to choose; it can leave the philosophy doc standing with a noted divergence.
Manifest absorption. The manifest's §4.A "cross-Operator stewardship of promoted fragments" residue is now sharper: it is specifically the domain steward (proposer) function from §5, distinct from the trusted-contributor admitter. The manifest v0.49 pass should record that distinction.

9. Open questions (carried)

Cross-Operator domain-steward proposer (C5 §4.1) — now precisely located: this is the domain steward function of §5, "genuinely open" in the investigations. Who proposes a cross-Operator promotion in a domain spanning competitors. Carried, unresolved.
Reviewer's place in the seed — if Option A is chosen, is "Reviewer" retained as product-framing vocabulary or dropped from the seed entirely? For the seed-amendment session to decide.
Founding governor (knowledge-elevation §6.1) — "the first Operator to receive a promotion at a level becomes its founding governor." Relevant to who holds a new domain's trusted core at birth. Carried.

10. What this note recommends — decision summary

Choose the governing role vocabulary (§7): recommendation Option A (methodology vocabulary governs the seed) + Option C mechanism (v0.11 names the admit function using "trusted core / trusted contributor," net-new-vocabulary-free).
Accept the C5 scoping-note corrections (§6): admitter = trusted contributor, not Steward; Steward is the distinct cross-Operator proposer; Reviewer≈Steward disconfirmed. (Recommendation: let the C5 CR carry these; no C5 note v0.2 needed.)
Sequence after the decision: seed v0.11 amendment session (re-pull seed sections, draft with the chosen vocabulary) → C5 CR drafting (under amended seed) → execution.
Note the philosophy-doc reconciliation (§8) as triggered-but-separate; do not block v0.11 on it.

DUNIN7 — Done In Seven LLC — Miami, Florida Loomworks — role-vocabulary reconciliation scoping note — v0.1 — 2026-06-05