Version. 0.3
Date. 2026-05-31
Status. Verified against candidate-seed v0.9. States the workflow as fact. Supersedes the working view (loomworks-workflow-working-view-v0_2), which was unverified and wrong on three points (see "Corrections from the working view").
Drawn from. A direct reading of candidate-seed v0.9 — §27–79 "The four rooms," §133–144 consumers, §81–116 authentication, §175–240 declared shape-types and render-types.
Companion. For what is built vs. intended today, see the status diagram architecture/loomworks-workflow-status-diagram-v0_1.html. This document is the verified architecture (what the workflow commits to); that one is the point-in-time build line. They cross-reference rather than duplicate.
> "Multiple sources and types of content are ingested, and they serve a seed that governs the engagement. Processes organize that content into a more structured view (Manifestation), produce use-case constructions for specific readers (Shaping), and then produce the target data or documents that feed other systems or AI-enabled surfaces (Rendering)."
— Marvin Percival, founder of DUNIN7 (Done In Seven LLC, Miami); plain-language statement of the architecture.
The seed is the founding commitment: what the engagement is, who consumes it, the constraints, the success conditions, who governs. Content does not define the engagement; the seed does. Contributions enter Memory and are organized and shaped in service of the seed.
The direction runs seed → content, not content → seed. This is visible in the pipeline itself: derivation "reads the engagement's seed and all committed assertions" (seed §49) — the seed is an input to organizing, the governing frame against which Memory is read, never a product of it. Everything downstream of Memory is performed against the seed's commitments.
The work moves through four rooms, in order — Memory, Manifestation, Shaping, Rendering — each performing one operation (seed §29). Contributions enter before the first room; declared consumers receive after the last. Identity is the substrate the pipeline runs on, not a stage in it.
Knowledge enters by several modes — typed, spoken, pulled from a document, described from an image — from many contributors. Each contribution carries who, when, and how; the system records the lineage automatically. A contribution becomes an assertion in Memory. A correction is a contribution; a retraction is a contribution.
The unit that lands is an assertion, not an "artifact." Artifacts are what Rendering produces at the far end of the pipeline; conflating the two inverts the flow.
Memory is the engagement's accumulated knowledge — everything contributed, by everyone, over its life. It is the source; nothing downstream exists without it.
Memory does not forget. Superseded and corrected assertions remain visible — corrections are preserved alongside what they supersede, because the trajectory is part of the record. Memory only grows; it is never finished.
A Manifestation is Memory organized at a moment in time. It is a distinct room — one of the four, in order — whose operation is derivation: read the seed and all committed assertions and produce a structured ordering, with groups, labels, and foundational knowledge placed before applied knowledge, so Memory becomes readable as a coherent body.
A Manifestation is a reading of Memory, not a copy — the assertions remain in Memory. It is not an identity with Memory. When Memory grows and the Operator re-derives, a fresh ordering supersedes the prior one; earlier Manifestations are preserved. It is versioned.
Shaping takes the organized knowledge and asks what this specific reader needs, and how it should be arranged for them. The same Memory and the same Manifestation produce different Shapings for different readers — the knowledge does not change; what changes is what is selected, emphasized, and left out. The seed commits to five declared shape-types, each organizing material for a consumer class.
The driver of Shaping is the reader's need. Nothing else is a seed-named driver of the Shape.
Rendering turns a Shape into what the reader gets. One shape-type sources many declared render-types — the seed declares five shape-types sourcing thirteen render-types, each render-type tracing to exactly one shape-type. The declared set is enumerated and extends only by explicit, disciplined declaration.
Rendering operates in two load-bearing modes, and a render-type declares which it uses:
Every Render — Mode A or Mode B — records what it was produced from: which Shape, which specialist, what configuration. Lineage is visible.
The pipeline serves four declared consumers (seed §133–144):
A consumer who contributes becomes an input back into Memory — the engagement compounds, and Loomworks is recursively an engagement that does this to itself.
A person is their system-assigned UUID; authentication is by credentials they control. Email and mobile are not identity (seed §89) — they are user-maintained communication attributes. Identity decides who may contribute and who may consume; it frames the pipeline's entry and exit. It is substrate around the pipeline, not a stage within it.
Per discovery-record discipline, the prior position is preserved alongside the corrected one. The working view (loomworks-workflow-working-view-v0_2) was unverified against the seed and wrong on three points:
Working view: "Manifestation is Memory reimagined, not a downstream room Memory feeds" — an identity. Corrected: the seed lists Manifestation as a distinct room, one of four, in order, whose operation is derivation. The surviving intuition is "a reading of Memory, not a copy"; the identity (≡) does not hold.
Working view: Shaping is driven by both textual direction (intent) and available skills, neither alone determining the Shape. Corrected: the seed names one driver — the specific reader's need. "Available skills" is a substrate executor detail, not a seed-level driver of the Shape.
Working view: "each render is produced by an agent / AI / API endpoint" — one producing capability. Corrected: the seed distinguishes Mode A (a specialist inside Loomworks produces the artifact) from Mode B (Loomworks produces a specification an external system consumes). In Mode B, Loomworks does not produce the final artifact at all. "Rendering operates in two modes. This is load-bearing."
The two-views v0.1 draft (wrong format, with a dropped "View A" foil) and the working view v0.2 are superseded; the correction is preserved here rather than by carrying those drafts into the record.
This document states what the workflow commits to — the verified architecture. What is built, in flight, or intended-but-not-yet-built is the status diagram's job: architecture/loomworks-workflow-status-diagram-v0_1.html. The short version: the four-room substrate is built and now metered (Phases 64/66), while the engagement still renders itself by hand — the seed's autonomous-production recursion, along with Mode B, FORAY anchoring, OVA, and federation, are committed but unbuilt. The status diagram carries the live picture; this document does not duplicate it.
DUNIN7 — Done In Seven LLC — Miami, Florida Loomworks Workflow — v0.3 (verified) — 2026-05-31