Version. 0.12 Date. 2026-06-07 Status. Twelfth version. Adds the two-tier sign-up posture to the authentication framework: sign-up stays open to any person — automatic commons membership is preserved — but the un-invited path carries a volume limit, and an authorized lift raises that limit. This is the same open-by-default-with-authorized-lift principle the seed already commits to for Memory reach (open by default, restricted by exception via OVA) and Memory contribution (a trusted core writes directly, outside contributions are held until admitted), now applied at a third layer: entry into the system itself. The mechanism of the lift — its numbers, where the throttle lives, and whether the lift reuses the engagement-join invitation or is a distinct account-creation invitation — is specification-level and deferred. Carries forward v0.11's contribution (write) access axis and v0.10's widening of Memory to N-scope. Names the prior v0.11 unconditional-sign-up position alongside the new one per Discovery-record discipline. Preserves v0.11 structure and language wherever still correct.
This seed is the foundation document for Loomworks. It names what Loomworks is committed to — what the work is, who consumes it, what its voice is, what its constraints are, what its success conditions are, who governs.
This seed is the first document any session should read before working on Loomworks. Before responding to a feature request, a refactor proposal, an architectural question, or any work that touches Loomworks's settled commitments, the session reads this seed and verifies the proposed work aligns with what the seed commits to.
If something feels misaligned with what this seed commits to, the session does not proceed silently. The session raises the concern in plain English to the Operator before proceeding. The phrasing should name what the seed commits to, name what the proposed work appears to do, and name where the apparent conflict sits.
This seed does not replace the comprehensive specification document (which lives in the record at loomworks-record and is updated as decisions land). The seed names the commitments; the specification names the detail. When the seed is silent on a topic the specification covers, the specification governs. When the seed and the specification appear to disagree, the seed governs and the disagreement is surfaced to the Operator.
This seed evolves through versions. Earlier versions are preserved in the record (archive/ under the engagement-seed location); the highest-numbered current version is canonical. When a decision lands that the seed should absorb, the next version of the seed lands.
Loomworks is DUNIN7's environment for engagement-memory work — accumulating knowledge, organizing it through manifestations, shaping it for consumers, and rendering the artifacts consumers receive. It is built on Loom Protocol, a protocol for the structured recording of assertions with provenance, lineage, and tamper-evident anchoring.
Loomworks is one implementation of the protocol. Others could exist under other names. What makes this particular engagement Loomworks rather than something generic is that it is DUNIN7's, built by DUNIN7's operators against DUNIN7's standards, and it is the environment in which DUNIN7's own engagements will run.
The engagement is also, recursively, operating on itself. Loomworks-the-engagement has produced Renders throughout its own construction — methodology documents, manifests, change requests, scoping notes, standing notes, Discovery records. The engineering substrate is the instrument that will eventually produce these Renders autonomously; today, the Renders are produced by Claude acting as specialist under Operator direction. The recursion is load-bearing, not incidental: the work is being built under the same discipline it is building.
Loomworks's pipeline runs through four rooms, in order: Memory, Manifestation, Shaping, Rendering. Each room performs one operation. The Operator's work moves through them.
Memory is accumulated knowledge with provenance — everything that has been contributed, by everyone, over the life of the work.
Memory has scope. The narrowest scope is the engagement: the engagement's own accumulated knowledge, everything contributed to that one engagement. But knowledge also accumulates at scopes above the engagement — an organization's brand and voice and commitments, a team's conventions, a role's standing instructions, a domain's body of practice, a jurisdiction's rules. These wider scopes are also Memory. Each scope is Memory in its own right — it accumulates, it carries provenance, it does not forget.
An engagement relates to the scopes above it in two ways, and they are not the same relationship. The first is membership — who the engagement belongs to: its organization, and what that organization belongs to. Membership is normally a single chain; an engagement belongs to one organization. The second is reference — what bodies of knowledge the engagement draws on: the domains it reaches for relevant practice and material. Reference is normally many: an engagement reaches a set of domains, peers to one another, each for its own kind of knowledge. A denim-jeans engagement belongs to its brand organization (membership, one) and references both a denim-heritage domain and a cotton-production domain (reference, several, neither above the other). Conflating the two — treating a referenced domain as if it were a parent in the membership chain — is a category error; the detail of how the two relationships compose is specification-level and comes due when the domain layer is built.
A scope's Memory is reachable in one of two access modes. By default a scope is open — reachable by any engagement, any Operator: this is the "all" mode, and it is the default precisely because a knowledge commons compounds when its knowledge is open. A scope becomes restricted when an access-control list is established on it through OVA; from that point OVA governs who may reach it, and the scope is reachable only by those the list permits. Restriction is therefore a deliberate, recorded act — the establishing of an ACL — not a default. Open is the default; closed is the exception. While OVA is not yet enforcing, every scope is effectively open; the access mode is declared and the seam is in place, so that when OVA enforces, scopes that carry an ACL become restricted and the rest remain open. This must hold both ways: the system supports restricted scopes (ACL via OVA) and open scopes ("all"), and the two are not the same — an open scope is open by design, not merely un-restricted because the control layer is absent.
A scope's Memory has a second access axis, distinct from reach: who may contribute to it. For an engagement, contribution is straightforward — the engagement's own contributors write into it. For a scope shared across engagements, such as a domain, contribution is gated, so that a shared body of knowledge does not degrade to whatever any contributor writes. Each shared scope has a trust graph: a set of vetted contributors — its trusted core — may write into the scope's Memory directly, and a contribution from anyone outside the trusted core is held until a member of the trusted core admits it or turns it away. Reach and contribution are independent: a domain is typically open to reach (anyone may draw on it) and gated on contribution (only the trusted core admits what enters it). How a contributor earns a place in a scope's trusted core is governed at the scope level, not fixed by the environment; the environment provides the gate, the trust graph, and the review queue, and each scope adopts the admission practice that fits it.
It carries who contributed it, when, how — typed, spoken, extracted from a document, described from an image — and which scope it belongs to. The system records the lineage automatically. The contributor focuses on the knowledge itself.
Memory does not forget. Contributions that are corrected or superseded remain visible as part of the record. The trajectory matters — not just where the work arrived, but how it got there. A correction is a contribution. A retraction is a contribution. Both are preserved. This holds at every scope.
Memory grows. It is never finished. An engagement with a hundred assertions knows more than it did at ten, and the person arriving at assertion one hundred and one benefits from everything that came before. The same is true at every scope above the engagement.
Every other operation in the system draws from Memory. Memory is the source. Nothing downstream exists without it.
What changed from v0.9, and why (Discovery-record note). Seed v0.9 committed Memory as single-engagement-scoped — "Memory is the engagement's accumulated knowledge" — and was silent on any scope above the engagement. That was a deliberate position: v0.9 was written on 2026-05-26, one day after the architecture specification v0.4 (2026-05-25) had already filed the N-space Memory model, and the seed held the single-engagement line on purpose rather than absorbing the wider model. v0.10 widens Memory to N-scope because the knowledge-elevation pathway (promoting an engagement's knowledge up to a shared scope) has no destination without a tier above the engagement — there is nowhere to promote to. The prior single-engagement framing is not wrong; it is the narrowest scope, still fully present. v0.10 adds the scopes above it.
What changed from v0.10, and why (Discovery-record note). v0.10 widened Memory to N-scope and committed two reach (read) access modes — open and OVA-restricted — but was silent on contribution (write) access to shared scopes. C5 scoping surfaced the gap: a shared domain needs a gate on what enters it, or the commons degrades. v0.11 adds the contribution axis, using the methodology's existing trust-graph vocabulary (trusted core / trusted contributor) rather than minting a new role. A vocabulary-reconciliation pass (recorded in loomworks-role-vocabulary-reconciliation-scoping-note-v0_1) found "Contributor" carried two conflicting senses across the canon; v0.11 ratifies the base sense (any participant who writes) for the seed and notes the philosophy document's divergent senior sense as product framing left standing. The reach axis (v0.10) is unchanged; v0.11 adds the write axis beside it.
A Manifestation is one engagement's Memory organized at a moment in time.
Memory accumulates continuously. Contributions arrive, knowledge grows, corrections land. At any given moment, the engagement's Memory is a body of knowledge — but it has no structure beyond the order contributions arrived.
Derivation is the act of organizing. The system reads the engagement's seed and all committed assertions, and produces a structured ordering — groups with labels, assertions placed within groups, the groups themselves ordered so that foundational knowledge precedes applied knowledge. The result is a Manifestation: the engagement's Memory made readable as a coherent body of knowledge.
A Manifestation is a reading of one scope's Memory. It does not merge scopes. A Manifestation of an engagement's Memory organizes that engagement's knowledge; a Manifestation of an organization's Memory organizes that organization's knowledge. The reading is always of a single body of knowledge — that is what makes it coherent. Composing across scopes — drawing brand from an organization, content from an engagement, rules from a jurisdiction — is a downstream act, performed in Shaping and Rendering, not by pre-merging scopes into one Manifestation.
A Manifestation is not a copy. The assertions remain in Memory. The Manifestation is a reading of Memory — an organizing act that says "here is how this body of knowledge hangs together right now."
When Memory grows and the Operator re-derives, the system produces a fresh ordering. Prior Manifestations are preserved but superseded — the new one reflects the current state of knowledge.
Shaping and Rendering build on Manifestations. They work with organized knowledge, not raw Memory.
What changed from v0.9, and why (Discovery-record note). Seed v0.9 said a Manifestation organizes "the engagement's Memory" and assumed a single engagement throughout. When Memory widened to N-scope, the live question was whether a Manifestation should become the composed N-scope reading — several scopes' Memory merged at a moment in time. v0.10 declines that. A Manifestation stays a reading of one scope's Memory, because the seed's existing commitment is that a Manifestation is a coherent reading of a body of knowledge, and merging several scopes into one Manifestation would make it a composition rather than a reading — collapsing into Manifestation the work the seed already gives to Shaping and Rendering. The alternative considered and set aside: pushing composition up into Manifestation. The reason for setting it aside: it would redefine what a Manifestation is and duplicate downstream work. Composition across scopes therefore lives downstream (see Shaping and Rendering below), where the seed already places selection and composition.
Shaping is the moment where accumulated knowledge gets organized for someone specific.
Everything a scope knows lives in its Memory. A Manifestation organizes one scope's Memory at a point in time. But neither of those is shaped for any particular reader — they are the whole body of knowledge, organized but not directed at anyone.
Shaping takes organized knowledge and asks: what does this specific reader need, and how should it be arranged for them?
Shaping is where knowledge from more than one scope first comes together. A reader's need rarely lives in a single scope: a render may need the engagement's content, the organization's brand and voice, and a jurisdiction's required disclaimers. Shaping draws from the Manifestations of the scopes that bear on the reader's need — selecting, emphasizing, and arranging across them. The Manifestations stay separate, single-scope readings; Shaping is the act that composes across them for a particular reader.
The same Memory, the same Manifestations, produce different Shapings for different readers. The knowledge does not change — what changes is which scopes are drawn from, what gets selected, what gets emphasized, and what gets left out.
What changed from v0.9 (Discovery-record note). v0.9's Shaping drew from a single engagement's Manifestation. v0.10 makes Shaping the room where composition across scopes happens — it draws from several scopes' Manifestations. This is the downstream home for the composition that v0.10 deliberately kept out of Manifestation. The composition rules (which scope wins when scopes conflict, how a jurisdiction's required floor cannot be overridden by an engagement's convenience, how scopes contribute non-conflicting pieces) are specification-level detail, not seed-level; the seed commits that composition lives here, and the specification governs how.
Rendering produces what the reader needs — directly when Loomworks owns the production (documents, reports, audio files, conversations), or as the specification a downstream production system consumes (an app spec for Claude Code, a design spec for whatever produces the final form). The render layer doesn't anticipate every production environment; it supplies the inputs each one needs.
Rendering operates in two modes. This is load-bearing.
Mode A — Loomworks-owned production. Loomworks holds the specialist that produces the artifact. The Render is the artifact itself: a PDF, a docx, an xlsx, a Markdown document, a conversation turn, an HTML page. The specialist runs inside Loomworks; the artifact is what the reader receives.
Mode B — Specification to external production system. Loomworks produces the specification; an external production system consumes the specification and produces the artifact. Application builds are the worked case: Loomworks produces an REQ specification; Claude Code consumes the specification and produces the application. Other cases follow the same shape: a design specification consumed by a fabricator; a clinical protocol consumed by a trial-management system; a contract specification consumed by a legal drafter. The render layer does not anticipate every production environment; it supplies the inputs each environment needs.
The boundary between Mode A and Mode B is methodology surface. A declared render-type names which mode it operates in. A future render-type addition that operates in Mode B requires defining the specification grammar; a Mode A addition requires registering the specialist that produces the artifact.
When a Render composes across scopes, the composition that Shaping arranged is realized here — the organization's brand shows in the artifact's form, the jurisdiction's disclaimer appears where the rules require it, the engagement's content carries the substance. Every Render — Mode A or Mode B — records what it was produced from: which Shape, which specialist, what configuration was in force, and which scopes' knowledge it composed. Lineage is visible, across every scope it drew from.
This section names the identity, sign-up, and sign-in commitments. The detailed implementation lives in the comprehensive specification; this section is the seed-level commitment.
A user is identified by their UUID — a system-assigned, persistent, cryptographic identifier. The UUID is the identity. Authentication proves control of credentials bound to the UUID. The UUID is what other Loomworks records reference; it is what FORAY attests against; it is what OVA authorizes against.
Email and mobile are not identity. They are user-maintained communication attributes — like a display name or a timezone preference. Email and mobile may be associated with a user; they can be used to communicate with the user; the user can add, remove, and change them. They never authenticate; they never key the lookup of a user's record; they never trigger identity-recovery flows.
This is a DUNIN7 standard. It is not Loomworks-specific. It applies across DUNIN7's protocol substrate and every engagement Loomworks hosts.
Sign-up is the flow by which a new person becomes a Loomworks user — receives a UUID and registers their first credentials. The sign-up flow may collect an email address as a delivery channel for the new UUID. This is contact-channel use, not identity use; the email is incidental to the delivery, not the basis of the account.
The sign-up flow registers credentials (a WebAuthn passkey, an authenticator code, or both, depending on path). Once credentials are registered and any limit on the entry path is satisfied, sign-up completes and the user enters the system.
Sign-up is open, and it is limited. It is open in that any person may create a Loomworks account — sign-up requires no invitation, and the commons membership a new account receives is automatic (see The universal commons). It is limited in that the open, un-invited entry path carries a volume limit: a ceiling on how many accounts the open path admits in a given window, so that the front door cannot be used to manufacture accounts at scale. An authorized lift raises that ceiling — a person who arrives holding a valid lift is admitted above the open-path limit. This is the same open-by-default-with-authorized-lift shape the seed already commits to elsewhere: a Memory scope is reachable by all until an ACL restricts it (reach), and a shared scope accepts contributions from its trusted core directly while holding others until admitted (contribution). Sign-up is the third layer the principle governs — entry into the system itself. Open is the default; the limit bounds abuse of the open path; the lift is the authorized way past it.
The mechanism is specification-level and deferred: how the limit is enforced and sized, where it lives, and whether the lift reuses the engagement-join invitation the seed already names (see The universal commons) or is a distinct account-creation invitation. The seed commits the posture — open, limited, lift — and leaves the mechanism to the specification, as it does for the trusted-core admission mechanism and the cross-scope composition rules.
What changed from v0.11, and why (Discovery-record note). Seed v0.11 described sign-up as completing unconditionally: "Once credentials are registered, sign-up completes and the user enters the system" — no limit, no condition on the open path. That was correct for a not-yet-deployed system on a localhost-only footing, but it leaves the open sign-up path with no volume control, so an automated client holding a software authenticator could create accounts in bulk. v0.12 adds the two-tier posture: the open path is preserved but volume-limited, and an authorized lift raises the limit. The v0.11 unconditional position is not wrong as a statement of intent — sign-up remains open to anyone — but it under-specified the open path's exposure; v0.12 adds the limit and the lift. The alternative considered and set aside was to gate sign-up entirely behind invitation (closing the open path); that was set aside because it would contradict the commons's open-front-door commitment, turning Loomworks from open-with-a-throttle into invitation-only. The Operator's current lean on the lift mechanism is toward a distinct account-creation invitation (separate from the engagement-join invitation), deferred to specification rather than committed here.
The sign-in flow identifies a returning user and authenticates them. Sign-in uses credentials, not communication attributes. Two paths:
Path 1 — Passkey. The browser's native passkey prompt identifies the user (via the WebAuthn discoverable-credential mechanism) and authenticates them in a single step. If a second factor is configured, the user is then prompted for an authenticator code.
Path 2 — Organizational sign-in. The user is redirected to their organization's identity provider. The provider handles authentication, including second-factor verification if the organization configures it. The provider returns the user to Loomworks with a token. No Loomworks-side authenticator step follows; the organization owns second-factor verification.
Sign-in does not request an email address. Sign-in does not key user lookup on email. Sign-in does not offer an email-based account recovery path.
Recovery uses credentials the user controls and that cannot be hijacked at an external provider. Recovery codes generated at sign-up, additional registered authenticators, or operator-mediated identity verification are the acceptable mechanisms. Email-based password reset is not a recovery mechanism in Loomworks.
A user maintains their own communication attributes (email, mobile, display name, notification preferences). The Loomworks surface for attribute maintenance lives in the user's profile or settings. These attributes can be added, removed, and changed freely. None of them is identity.
The Loomworks engagement is the universal commons. Every person who creates a Loomworks account automatically becomes a Contributor to this engagement. This is the only engagement with automatic membership — all other engagements require invitation, single sign-on provisioning, or future discovery-based joining. The two-tier sign-up posture (see Authentication framework — Sign-up) does not change this: the volume limit on the open sign-up path governs the rate at which accounts are created, not whether a created account becomes a Contributor. Every account that completes sign-up — whether through the open path or via an authorized lift — receives automatic commons membership. The limit throttles entry; it does not gate membership.
The commons purpose and the build purpose are not separate engagements. They are layers of the same engagement. The build artifacts — methodology documents, manifests, Discovery records — are the deepest educational content for sophisticated users. The educational content — concept references, contributor guides — is the entry point for everyone else. Both layers live in the same Memory, shaped and rendered for different consumers.
The engagement's Memory is public by default — visible to every person in the system. Content must be appropriate for that scope: methodology, educational material, community-contributed knowledge. Not internal DUNIN7 strategy.
The recursion is deliberate. The Loomworks engagement's subject matter is the system it lives inside. Its Memory is knowledge about how Memory works. Its Shapings are shapings about how Shaping works. A person who struggled with their first seed induction and figured something out becomes the person whose contributed knowledge helps the next person. That is the compounding thesis in its purest form: compounding about the system itself, across every person who uses it.
The engineering substrate is building toward Loomworks-as-medium — a place where long-form inventive work lives. Not a platform, marketplace, or incubator; a medium that holds inventive work at the pace the work requires. The three-role framework (Operator, Reviewer, Contributor — the product-framing senior sense, distinct from the base Contributor role above), the six-stage Engagement lifecycle, the badge mechanism, the retirement-with-dignity machinery, the AI-as-faithful-clerk posture — these are the product framing the engineering substrate eventually serves. The full articulation lives in the philosophy and architecture document.
Phase work does not currently build Stages 1-3 or Stages 5-6 of the product lifecycle. Phase work builds Stage 4 (Manifestation, Shaping, Rendering), which is the methodology pipeline. The remaining stages are out of current scope but not out of eventual scope.
Four consumers, in four different modes.
Every person in the system. The first consumer and the broadest. Every person who creates a Loomworks account is a Contributor to this engagement. They consume the commons — educational content, concept references, contributor guides — through the engagement's Shaped and Rendered output. They can contribute knowledge back. The person arriving today who reads a concept reference was served by the person who contributed that knowledge last month. This is the compounding thesis made visible at the system's front door.
Operators running engagements in Loomworks. Every engagement Loomworks hosts — clinical trials, litigation matters, educational courses, agricultural work, future engagements in domains we have not yet touched — has an operator whose job Loomworks is supporting. The operator reads, writes, corrects, promotes, drives the engagement. Loomworks is what their work sits inside.
Contributors working within engagements. Domain experts, participants, specialists — the bankers and sommeliers and oncologists whose knowledge is what the engagements accumulate. They contribute through contributions; Loomworks holds their contributions with provenance.
Future implementers of the methodology. A longer-horizon consumer. The methodology is non-normative with respect to any implementation, but Loomworks is the worked case. What Loomworks ships becomes the reference against which other implementations of the methodology can be built.
Loomworks is built the way DUNIN7 builds everything: by operators holding domain expertise, with AI as the production layer. No coding, terminal work, or architecture decisions performed by the operator. The voice of the system is operator-first — everything technical is Claude Code's work, everything intentional is the operator's. A system feature that requires the operator to understand technical detail to use it is a product deficiency, not an operator failing.
Operator-facing communication from the system is in plain English with examples where examples help the operator make a reasonable decision. Technical language is reserved for technical-reader documents (Claude Code-facing change requests, code, test specifications).
Methodology vocabulary — Memory, Manifestation, Shaping, Rendering, engagement, assertion, Operator, Companion, scope — appears in plain terms in operator-facing surfaces. Codebase shorthand does not leak through to operator-facing surfaces. This is the plain-terms-discipline-protects-methodology-nouns principle, applied at every surface where a user encounters Loomworks vocabulary.
Conforms to the methodology. Loomworks supports what any conforming environment must support, per methodology v0.20 (with v0.21 consolidation pending). Where the methodology has open questions, Loomworks picks a defensible answer and documents the choice.
Built on Loom Protocol. The wire-level substrate. Loom Protocol v0.1 is the current protocol version. Where the methodology requires commitments Loom v0.1 does not yet specify (supersession severity, access-layer primitives, federation, contribution-trust governance, engagement-as-first-class structure, Memory scopes above the engagement), Loomworks implements them at its layer pending future protocol extension.
Leverages FORAY and OVA. FORAY for tamper-evident anchoring of transitions. OVA as the candidate access-control substrate (provisional patent filed March 2026). The access model for Memory scopes has two modes and supports both: open ("all" — the default, reachable by any engagement) and restricted (an access-control list established through OVA, which then governs who may reach the scope). A scope is open until an ACL is established on it; establishing an ACL is the deliberate, recorded act that restricts it. Until OVA enforces, scope access is governed by the seam-marked stub the architecture anticipates, and every scope is effectively open — but the two modes are distinct commitments, and open is open by design, not a placeholder for an absent control layer.
Identity is cryptographic. Per the authentication framework above. Email and mobile are user-maintained communication attributes, not identity. Sign-in is by credentials the user controls. Recovery uses credentials, not external-channel reset.
Built by AI under operator direction. No DUNIN7 developers in the traditional sense. Operators matched to domains; production by AI. This is foundational and non-negotiable.
Operator-authority over artifact state transitions. Automatic state transitions on artifacts the operator has authority over are a category error. The system produces, records, and signals; the operator approves state transitions that affect an artifact's validity or downstream usability. Consonant with the AI-as-faithful-clerk posture in the longer-horizon product framing.
Corrections preserved, not smoothed. Loomworks inherits the methodology's discipline: superseded assertions remain in memory as corrections, vocabulary renames are recorded, trajectory is preserved alongside destination.
Federation-ready. Loomworks is built to federate with other Loom-protocol environments. Internal single-instance use is supported, but the architecture does not foreclose cross-environment reference and shared common pools.
Public Memory by default for the commons. The Loomworks engagement's Memory is visible to every person in the system. This is unique to this engagement and a consequence of the commons purpose. All other engagements default to private. Memory at scopes above the engagement follows the two-mode access model above: open ("all") by default, restricted when an ACL is established through OVA. An engagement's own Memory defaulting to private and a domain scope defaulting to open are not in tension — they are different scope kinds with different defaults, the engagement private to its participants, the domain open so that knowledge compounds.
Only show what is available. No disabled buttons. No grayed-out options. If a feature is not available, it does not appear on the surface. This applies across every Loomworks user-facing surface.
Loomworks-the-engagement commits to produce the following shape-types. These are the intermediate shaped forms that sit between a Manifestation and the Renders that consume them. Each shape-type selects and organizes material from Memory (through the relevant Manifestations) for a specific consumer class. Declaring them makes the selection stream explicit, parallel to what the declared render-types section does for the rendering stream.
Multiple render-types can draw from the same shape-type. The shape-type defines what material is selected and organized; the render-type defines what final-form artifact is produced from that organized material.
These correspond to the material selections the engagement has been performing in practice throughout its construction.
| Shape-type | Render-types it sources |
|---|---|
| Phase execution context | Phase change request, phase scoping note, phase handoff, phase implementation notes |
| Project state | Project state manifest, standing note, infrastructure change request, engagement seed |
| Methodology narrative | Methodology document, philosophy and architecture document |
| Discovery trajectory | Discovery record |
| Commons education | Concept reference, contributor guide |
Five declared shape-types source thirteen declared render-types. Every render-type traces to exactly one shape-type. Every shape-type sources at least one render-type.
Loomworks-the-engagement commits to produce the following render-types. Declared render-types carry strong discipline — rules pinned, specialist registration discoverable from the seed, drift-checkable.
Each render-type names which Rendering mode it operates in (Mode A: Loomworks-owned production; Mode B: specification to external production system).
These are the render-types the engagement has been producing in practice throughout its construction. Declaring them makes the production stream explicit.
These serve the educational and community purpose. Their consumer is every person in the system.
Rules, specialists, and pinned instruction versions for each declared render-type live in the engineering substrate once the Render layer is populated with concrete specialist registrations against this seed. Today, the specialist is Claude under Operator direction; rules are the conventions this project has accumulated across its phases and captured in manifests, standing notes, and Phase CRs.
Future Mode B render-types (application builds, design specifications, etc.) will be added as Loomworks's specification-to-external-production-system mode is exercised in subsequent phases. The architecture supports Mode B; the current declared set is Mode A.
Loomworks is sufficient when an operator can open an engagement, accumulate memory against a seed, produce manifestations from that memory, and watch the environment carry the methodology's disciplines (corrections, considerations, drift, promotion, authorisation) without the operator having to understand how any of it is implemented. The operator's attention stays on the engagement's domain; Loomworks handles the methodology mechanics.
At the commons level: a new person creates a Loomworks account, arrives as a Contributor to this engagement, and can learn about the methodology and system through the engagement's Memory. The educational content is not static copy on a marketing page — it is Shaped and Rendered from living Memory that other Contributors have contributed to and that evolves as the community's understanding deepens.
At the authentication level: signing up takes the new person from "I want to use Loomworks" to "I am a Loomworks user with a UUID and registered credentials" without ever asking them to set an email-based password. Signing in identifies returning users by credentials they control. The user maintains email and mobile as communication attributes if they choose; the system uses them to communicate, not to identify.
At the scope level: an engagement can draw on the Memory of the scopes above it — an organization's brand and voice, a domain's body of practice, a jurisdiction's rules — so that a render composed for a reader carries the right knowledge from each scope, with the composition visible and the lineage recorded. Knowledge that earns wider relevance can be promoted from an engagement up to a shared scope, where it serves every engagement below.
More concretely, at a first-run-complete level: DUNIN7's own engagements run inside Loomworks with their memory, their manifestations, their operators, and the methodology's disciplines active. These engagements enter Loomworks via a separate one-off induction solution that derives their seeds from prior material; that induction solution is not part of Loomworks and is itself not a phase of Loomworks.
Loomworks-the-engagement also produces its own declared render-types at production quality, on schedule with the engineering substrate's build cadence. Success at this axis is the engagement is able to describe and build itself through its own production stream.
Longer-horizon: Loomworks hosts engagements across domains DUNIN7 has not yet anticipated, federates with environments outside DUNIN7, and carries the methodology's disciplines reliably enough that the question "is this working?" stops being asked. And at the longest horizon: Loomworks-as-medium (the product framing) becomes the environment in which inventive work generally lives, not just DUNIN7's own work.
Marvin Percival, founder of DUNIN7 (Done In Seven LLC, Miami), is the Operator for the Loomworks engagement. Engagement-scoped decisions are his. Methodology decisions that affect the broader DUNIN7 program sit with him as founder. Phase-level technical decisions are delegated to Claude Code under operator direction.
Contributor is the base participation role: every person in the system is a Contributor — automatic membership at signup — and a Contributor is anyone who writes into Memory. The Operator governs; Contributors participate. Within a shared scope, a subset of contributors form its trusted core and admit others' contributions; trusted-core membership is a standing within a scope, not a separate role. (The philosophy and architecture document uses 'Contributor' in a second, narrower sense — a Reviewer promoted into internal collaboration on a single engagement — as part of its longer-horizon product machinery, including the invited-Reviewer stages. That product framing is distinct from this base role and is out of current phase scope; where the two documents diverge on the word, the seed's base sense governs the seed.)
v0.12 adds the two-tier sign-up posture to the authentication framework. The change and its reasoning are recorded in the Sign-up section's Discovery-record note. In brief:
Sign-up section — two-tier posture added. Sign-up stays open to any person (no invitation required; automatic commons membership preserved), but the open, un-invited path now carries a volume limit, and an authorized lift raises that limit. Framed explicitly as the same open-by-default-with-authorized-lift principle the seed already commits to for Memory reach (open/restricted via OVA) and Memory contribution (trusted core admits). Sign-up is the third layer the principle governs. The v0.11 unconditional-sign-up sentence was amended to make completion conditional on satisfying any limit on the entry path.
Universal commons section — reconciled. Added language confirming the volume limit governs the rate of account creation, not whether a created account becomes a Contributor. The commons's automatic-membership commitment (line: "the only engagement with automatic membership") is preserved unchanged; the limit throttles entry, it does not gate membership.
Mechanism deferred to specification. v0.12 commits the posture (open, limited, lift) and deliberately leaves the mechanism to the specification and the implementing Change Request: the limit's enforcement, sizing, and location (application layer versus infrastructure layer such as the existing Cloudflare edge); whether the limit is per-source or global; and whether the lift reuses the engagement-join invitation or is a distinct account-creation invitation. This matches the seed's established discipline of committing postures and deferring mechanisms (as v0.11 did for the trusted-core admission mechanism, and v0.10 for the cross-scope composition rules).
Three-layer consistency noted. With v0.12 the seed now applies one principle — open by default, with an authorized path to more — at three layers: engagement-joining (the commons is open; other engagements require invitation), Memory contribution (a scope's trusted core writes directly; others are held until admitted), and account creation (open sign-up, volume-limited, with an authorized lift). The three are distinct mechanisms governing distinct events; the shared shape is intentional and worth preserving as the seed's vocabulary for "open, with a governed way past the open limit."
Discovery-record note on a deferred lean: the Operator's current inclination on the lift mechanism is toward a distinct account-creation invitation, separate from the engagement-join invitation the commons section already names — on the reasoning that the two answer different questions (one admits an existing user into an engagement; the other admits a not-yet-user into the system above the open-path limit). This lean is recorded, not committed; the same-versus-distinct decision is deferred to specification, where it can be made against the actual invitation and claim-token machinery already present in the sign-up flow.
v0.11 adds the contribution (write) access axis to the Memory model; see the Memory section's Discovery-record note for the change and its reasoning. The drafter's notes below are preserved from v0.10 and record that version's changes from v0.9.
Changes recorded by v0.10 (from v0.9):
Memory section — widened to N-scope. v0.9 framed Memory as single-engagement ("Memory is the engagement's accumulated knowledge"). v0.10 reframes Memory as accumulated knowledge with provenance that has scope: the engagement is the narrowest scope, with organization, team, role, domain, and jurisdiction scopes above it. Each scope is Memory in its own right — accumulates, carries provenance, does not forget. A Discovery-record note in the section names the v0.9 single-engagement position, the deliberate one-day-after-the-spec hold, and the knowledge-elevation reason for widening now (nowhere to promote to without a tier above the engagement). Two further commitments were added to the Memory section during the seed-amendment session: - Two relationships to scopes above the engagement: membership and reference. Membership (who the engagement belongs to) is normally a single chain — one organization. Reference (what bodies of knowledge the engagement draws on) is normally many — a set of peer domains, none above the other. The worked case: a denim-jeans engagement belongs to its brand organization (membership, one) and references both a denim-heritage domain and a cotton-production domain (reference, several, orthogonal). Conflating the two — treating a referenced domain as a parent in the membership chain — is named as a category error. This correction came from a worked example during the session that exposed the v0.9-draft single-chain framing ("belongs to an organization, which may belong to a domain, and so on up the chain") as wrong; that draft sentence was replaced. - Two access modes: open ("all") by default, restricted (ACL via OVA) by exception. A scope is open — reachable by any engagement — until an access-control list is established on it through OVA, at which point OVA governs reach. Open is the default because a knowledge commons compounds when its knowledge is open; restriction is a deliberate, recorded act. Both modes are first-class commitments: the system supports restricted scopes and open scopes, and open is open by design, not a placeholder for an absent OVA. While OVA does not yet enforce, every scope is effectively open and the access mode is seam-declared so that enforcement, when it lands, restricts the scopes that carry an ACL and leaves the rest open.
Manifestation section — held single-engagement; composition placed downstream. v0.9 assumed a single engagement. The live question on widening Memory was whether a Manifestation should become the composed N-scope reading. v0.10 declines: a Manifestation stays a reading of one scope's Memory, because a Manifestation is a coherent reading of a body of knowledge and merging scopes would make it a composition. A Discovery-record note names the alternative considered (composition in Manifestation) and the reason for setting it aside (it would redefine the room and duplicate downstream work). Composition across scopes is explicitly located downstream.
Shaping section — named as the room where composition across scopes happens. v0.9's Shaping drew from a single engagement's Manifestation. v0.10 makes Shaping draw from several scopes' Manifestations and compose across them for a particular reader. The composition rules themselves (conflict resolution, jurisdiction floors, orthogonal contribution) are flagged as specification-level, not seed-level. A Discovery-record note records the change.
Rendering section — names cross-scope composition realized in the artifact, and scope lineage. Added a paragraph: when a Render composes across scopes, the artifact carries each scope's contribution (organization brand, jurisdiction disclaimer, engagement content) and the Render records which scopes it composed. Lineage is now visible across scopes.
Constraints — N-scope and access-model touch-ups. Added "Memory scopes above the engagement" to the list of commitments Loom v0.1 does not yet specify. Rewrote the FORAY/OVA constraint to name the two access modes explicitly: open ("all") by default, restricted (ACL via OVA) by exception, both first-class, with the OVA-stub period stated honestly. Refined the public-Memory constraint to "Public Memory by default for the commons" and reconciled it with the new open-by-default for scopes above the engagement (engagement-private and domain-open are different scope kinds with different defaults, not a contradiction).
Voice — added "scope" to the protected methodology vocabulary list.
Success conditions — added a scope-level success condition (an engagement draws on the Memory of scopes above it; composition visible and lineage recorded; knowledge promotable from engagement to shared scope).
Render-type formats — corrected .docx references to HTML/Markdown per the established format default (HTML supersedes .docx as the operator-facing format). This was a known stale spot carried from v0.9; v0.10 corrects it while the section was open.
Changes preserved from v0.9: the Authority-of-this-document section; the Rendering two-modes (Mode A / Mode B) distinction; the full authentication framework (no email as identity, sign-up vs sign-in, two sign-in paths, recovery via credentials); the universal commons section; longer-horizon framing; four-consumer framing; the declared shape-types and their mapping; the authorisation section.
What this version does NOT do: - Does not specify the two-tier sign-up mechanism. v0.12 commits the posture (open sign-up, volume-limited, with an authorized lift) but defers to specification and the implementing Change Request: how the limit is enforced and sized, whether it lives in the application layer or at the infrastructure edge (Cloudflare), whether it is per-source or global, and whether the lift reuses the engagement-join invitation or is a distinct account-creation invitation (Operator lean: distinct, deferred). - Does not scope C5 (the Domain layer) or any build work. The seed amendment is the gate in front of C5 scoping; scoping is a separate session against this widened seed. - Does not specify the composition rules (conflict resolution across scopes, jurisdiction-floor non-overridability, orthogonal contribution). Those are specification-level and come due at C5 scoping time. - Does not resolve whether the auth Organization object and organization-scope Memory unify into one entity. The standing note (loomworks-standing-note-organization-name-collision-v0_1) keeps them separate by default and leaves unification as a clean forward decision; v0.11 does not pre-decide it. Organization Memory is a scope, not a second Organization entity. - Does not decide which scope type ships first or who governs each scope type — C5 scoping questions. (On the 'steward role' deferred here at v0.10: v0.11 resolves the contribution admit-gate as the scope's trusted core, using existing trust-graph vocabulary. The separate cross-Operator promotion-proposer role — what the investigations call a domain steward — remains genuinely open and is a C5 open question, not settled by v0.11.) - Does not absorb every settled decision since v0.9 (Phase 64 credit gate, Phase 66 spend visibility, Axis 11 pagination). This is a seed, not the manifest; those live in the current-status manifest. v0.11 is a focused Memory-model amendment.
DUNIN7 — Done In Seven LLC — Miami, Florida Loomworks candidate seed — v0.12 — 2026-06-07