Version. 0.9
Date. 2026-05-26
Status. Ninth version. Adds: self-asserting authority section at the top; authentication framework (no email as identity, sign-up vs sign-in distinction, UUID-and-authenticator-code for sign-in); four-rooms section with corrected framings per room-explanations-and-expandable-scope-v0_1.md and the marketing observation cluster v0.1; render-specialist-boundary-two-modes distinction (Loomworks-owned production vs. specification-to-external-production-system). Preserves v0.8 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 the engagement's accumulated knowledge — everything that has been contributed, by everyone, over the life of the engagement.
When someone contributes to an engagement, their contribution enters Memory. It carries who contributed it, when, and how — typed, spoken, extracted from a document, described from an image. 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 engagement arrived, but how it got there. A correction is a contribution. A retraction is a contribution. Both are preserved.
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.
Every other operation in the system draws from Memory. Memory is the source. Nothing downstream exists without it.
A Manifestation is 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: Memory made readable as a coherent body of knowledge.
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 the Manifestation. They work with organized knowledge, not raw Memory.
Shaping is the moment where the engagement's accumulated knowledge gets organized for someone specific.
Everything the engagement knows lives in Memory. The Manifestation organizes 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 that organized knowledge and asks: what does this specific reader need, and how should it be arranged for them?
The same Memory, the same Manifestation, produces different Shapings for different readers. The knowledge does not change — what changes is what gets selected, what gets emphasized, and what gets left out.
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.
Every Render — Mode A or Mode B — records what it was produced from: which Shape, which specialist, what configuration was in force. Lineage is visible.
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, sign-up completes and the user enters the system.
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 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 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 — 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), 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).
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. 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.
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 current Manifestation) 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.
.docx primary, .md companion..md primary, .docx companion..md primary, .docx companion..md primary, .docx companion..md primary, .docx companion..md..md, .docx companion..md..md primary, .docx companion..md..md.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.
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.
Contributors to Loomworks as an engagement are every person in the system — automatic membership at signup. The Operator governs; Contributors participate. In the longer-horizon product framing, Reviewers are invited by the Operator per the philosophy document's Stage 2-3 machinery; that machinery is out of current phase scope.
Changes from v0.8:
room-explanations-and-expandable-scope-v0_1.md (assertions #13-#16 contributed to the engagement's Memory on 2026-04-28). The Rendering subsection adds the render-specialist-boundary-two-modes distinction.loomworks-ui-discovery-sign-in-and-dashboard-v0_1.md, 2026-04-24); the sign-up vs sign-in distinction; the two sign-in paths (passkey and organizational SSO); email and mobile as user-maintained communication attributes; recovery via credentials not external-channel reset.Changes preserved from v0.8: structure, language wherever still correct, the universal commons section, longer-horizon framing, four-consumer framing, the declared shape-types and their mapping to render-types, the authorisation section.
What this version does NOT do:
DUNIN7 — Done In Seven LLC — Miami, Florida Loomworks candidate seed — v0.9 — 2026-05-26