Version. 0.8 Date. 2026-04-28 Status. Eighth version. Spells out all abbreviations and acronyms in operator-facing text. No abbreviations anywhere a reader encounters the seed. Standing rule: operator-facing text uses plain language only.
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.
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 (docs/discovery-records/loomworks-philosophy-and-architecture-v0_1.md).
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).
Conforms to the methodology. Loomworks supports what any conforming environment must support, per methodology v0.17. 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).
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.
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.
These serve the educational and community purpose, parallel to the commons render-types.
| 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 (Position C on Field 11; declared render-types carry strong discipline — rules pinned, specialist registration discoverable from the seed, drift-checkable).
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..docx primary, .md 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.
Ad-hoc renders (produced outside any declared render-type) are not part of Phase 10 v0.1's dispatch handling; if an ad-hoc render need arises, it either warrants a new declared render-type (preferred) or waits for the engineering substrate's ad-hoc path to land in a future phase.
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.
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 (see above) 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.
DUNIN7 — Done In Seven LLC — Miami, Florida Loomworks candidate seed — v0.8 — 2026-04-28