Version. 0.1 Date. 2026-04-28 Status. Draft. Four assertions for the Operator to contribute to Memory, plus the feature scope for the expandable-section pattern.
Contribute each of these through the Memory room's contribution surface. Commit each one. They become assertions #13–#16 in the Loomworks engagement.
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 — Manifestation, Shaping, Rendering — 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. The body of knowledge has changed, so its best organization may have changed. 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. This is what makes them stable: a Shaping that runs against Manifestation version 3 draws from exactly the same organized knowledge today as it will tomorrow, even if new assertions arrive in Memory overnight.
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.
From Loomworks itself: this engagement's Memory holds everything that has been contributed about how Loomworks works — methodology, principles, decisions, corrections. From that same body of knowledge, a phase preparation shaping selects what is relevant to the next build phase and organizes it so the person writing the change request has exactly what they need. A project overview shaping selects the cross-cutting inventory so someone arriving fresh can orient in minutes. An education shaping selects methodology concepts so a person encountering Loomworks for the first time can understand what Memory is, what an engagement is, how to contribute — without reading a single change request or implementation note.
Same knowledge. Different readers. Different selections.
From other domains: a clinical trial's protocol memory gets shaped differently for the ethics review board, the patient, and the investigating physician at each site. A farm's operational memory gets shaped differently for the parts supplier and the farm owner. Same knowledge in each case. Different readers. Different shapings.
Rendering produces the final artifact that the reader actually receives.
Memory accumulates knowledge. Manifestation organizes it. Shaping selects and arranges it for a specific reader. Rendering produces the thing they hold in their hands — the document, the report, the guide, the reference, whatever form the reader needs.
The distinction from Shaping: a Shaping says "here is the knowledge this reader needs, organized for them." A Render says "here is the actual document, in the actual format, ready to use." The Shaping is the organized material; the Render is the produced artifact.
A render specialist produces the Render. The specialist knows how to turn shaped material into the right format — a methodology document, a contributor guide, a change request, a concept reference. Different specialists produce different formats from the same shaped material.
Every Render records what it was produced from: which Shape, which specialist, what configuration was in force. If the specialist's instructions change, or the Shape changes, or the underlying Memory grows and a new Manifestation is derived, the lineage is visible. The Operator can always see what any Render was built from.
Rendering is the end of the pipeline. Memory is knowledge. Manifestation is organization. Shaping is selection. Rendering is production. The reader receives the Render.
Each methodology room (Memory, Manifestation, Shaping, Rendering) displays an expandable explanation section between the room header and the room content. The section reads its content from a designated assertion in the engagement's Memory.
Collapsed state (default after first visit). A single line: "What is [room name]?" as a clickable toggle. Compact. Takes no room.
Expanded state. The full assertion text, rendered in the room. Includes examples if the assertion has them. A "Collapse" toggle at the bottom.
First-visit behavior. On the Operator's first visit to a room (no prior expansion state stored), the section starts expanded. After the Operator collapses it, it stays collapsed on subsequent visits. The expansion state is stored per-person per-room (local — not a substrate concern).
A new relationship type: explains. The relationship links an assertion to a room concept:
explains Memoryexplains Manifestationexplains Shapingexplains Rendering
The room queries for the assertion that explains its concept. If no such assertion exists, the room falls back to a short static sentence (the current subtitle text).
The explains relationship uses the existing relationship infrastructure from Phase 3. The target is a well-known identifier for each room concept (e.g., concept:memory, concept:manifestation, concept:shaping, concept:rendering). CC determines the exact mechanism — it could be a relationship to a known object ID, a tag, or a convention. The requirement is: one assertion per room, discoverable by the room without hardcoding an assertion ID.
The current room subtitles:
These become the fallback text — used only when no explains assertion exists. Once the assertions are committed, the expandable section replaces them.
The same pattern extends beyond rooms. Each DeclaredShapeType and DeclaredRenderType can have an explains assertion in Memory. The shape type section in the Shaping room, or the render type subsection in the Rendering room, would show an expandable explanation drawn from that assertion.
This is the answer to the scaling problem from Part 1 of the discussion: when the Shaping room has twenty shape types, each one is a compact card with its name and a "What is this?" expandable section. The explanation lives in Memory, not hardcoded in the UI. The Operator (or any Contributor) can improve any explanation by contributing a better one.
This extension is not in scope for the initial feature — it's the natural next step once the room-level pattern works.
explains assertion exists.DUNIN7 — Done In Seven LLC — Miami, Florida Room explanation assertions and expandable-section scope — v0.1 — 2026-04-28