"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 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; lineage is recorded 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; conflating the two inverts the flow.
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. It only grows; it is never finished.
Memory organized at a moment in time. 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, foundational knowledge before applied, 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 asks what this specific reader needs, and how it should be arranged for them. The same Memory and 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.
Rendering operates in two load-bearing modes, and a render-type declares which it uses:
A specialist inside Loomworks produces the artifact itself — a document, a report, an HTML page, a conversation turn. The artifact is what the reader receives.
Loomworks produces a specification; a system outside Loomworks — a downstream service or an AI-enabled surface — consumes it and produces the artifact (e.g. a build spec that Claude Code turns into an application). In Mode B, Loomworks does not produce the final artifact; it produces the specification.
Every Render — Mode A or Mode B — records what it was produced from: which Shape, which specialist, what configuration. Lineage is visible.
A consumer who contributes becomes an input back into Memory — the engagement compounds, and Loomworks is recursively an engagement that does this to itself.
Identity. A person is their system-assigned UUID; authentication is by credentials they control. Email and mobile are not identity (seed §89). 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:
1. Memory ≡ Manifestation → distinct rooms
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.
2. Skills as a Shaping driver → reader-need only
Working view: Shaping driven by both textual direction (intent) and available skills.
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.
3. Render mechanism flattened → Mode A / Mode B load-bearing
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 — the highest-numbered current version of architecture/loomworks-workflow-status-diagram-vN_M.html. In short: 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 two cross-reference rather than duplicate.