Version. 0.3
Date. 2026-04-30
Purpose. Draft text for the Operator to contribute through the Memory room UI. Eighteen assertions — five for DeclaredShapeTypes, thirteen for DeclaredRenderTypes. Each is contributed as a separate assertion, committed, then linked to its concept via the explains relationship script.
Voice. Matches assertions #1 (Memory), #13 (Manifestation), #14 (Shaping), #15 (Rendering). Plain language. Concrete. No jargon.
Phase preparation assembles the material needed to plan and execute a build phase.
Before a phase begins, someone needs to know: what has been decided, what the current state of the project is, and what is relevant to the work ahead. Phase preparation selects that material from the Manifestation — the current snapshot of Memory — and organizes it so the person scoping the phase and the person executing it can work from a shared, current picture.
Each phase starts from a different state. The material changes — new decisions, new residues, new constraints. Phase preparation captures those differences so that the scoping note and change request reflect reality at that moment, not a stale snapshot.
The shaped material feeds four render types: the phase change request, the phase scoping note, the phase handoff, and the phase implementation notes. Each is a different document for a different moment in the phase lifecycle, but all draw from the same prepared material.
Project overview assembles a cross-cutting inventory of the project: what has been built, what is current, what is open.
The audience is anyone who needs to orient to the project without reading through every phase. A new Claude session, an Operator reviewing the overall state, someone returning after time away — all of them need the same thing: a reliable picture of where things stand.
The material includes phases completed, documents produced, vocabulary in force, residues open and resolved, named principles, test counts, frontend surfaces, and the document authority chain. It is comprehensive by design — the overview is the place where nothing is left out.
The shaped material feeds four render types: the project state manifest, the standing note, the infrastructure change request, and the engagement seed. Each serves a different purpose but all need the same underlying inventory.
Methodology assembles the methodology as a coherent body of knowledge: principles, pipeline, vocabulary, and trajectory.
The methodology is not static — it has changed over time. Earlier positions were corrected, vocabulary was renamed, new concepts crystallized from practice. Methodology shaping captures the current state of the methodology while preserving the trajectory that brought it here.
The audience is anyone needing to understand what the engagement builds and why. This includes future Claude sessions orienting to the project, the Operator reviewing methodology coherence, and anyone who might implement the methodology in a different context.
The shaped material feeds two render types: the methodology document and the philosophy and architecture document. One is the methodology itself; the other is the broader vision that the methodology serves.
Discovery assembles the path of a specific inquiry: what was considered, what crystallized, what was set aside.
Discoveries are not summaries. A summary tells you what was decided. A discovery tells you how the decision was reached — the alternatives that were weighed, the positions that were rejected and why, the moments where something new emerged that changed the direction. The negative space matters as much as the positive.
The audience is anyone reviewing how a decision arrived: the Operator revisiting an earlier choice, a future methodology revision that needs to understand the reasoning behind the current position, or a contributor trying to understand why something works the way it does.
The shaped material feeds one render type: the discovery record. Discovery records are among the most valuable artifacts an engagement produces, because they preserve the reasoning that other documents compress away.
Education assembles methodology and system concepts from the Manifestation and organizes them for accessibility.
The audience is every person in the system — not just the Operator or the build team, but anyone encountering Loomworks for the first time. The selection criterion is approachability: material is chosen and organized so that someone new can orient without needing to read phase change requests or methodology documents.
What each concept means in plain language. How it works. How to participate. What the system expects of Contributors. Education shaping turns internal knowledge into knowledge that is genuinely available to everyone.
The shaped material feeds two render types: the concept reference and the contributor guide. One explains what things are; the other explains how to participate.
A phase change request is the instruction set for a build phase.
It tells the executing agent — Claude Code — exactly what to build: what changes, in what order, with what acceptance criteria, and where the checkpoints are. It also tells the Operator what to expect, what to verify at each checkpoint, and what the post-phase state should look like.
A change request draws from Phase preparation material: the decisions, current state, and constraints relevant to that phase. The scoping note comes first (what to build and why), then the change request (how to build it). They are siblings — different documents from the same shaped material, written at different moments in the phase lifecycle.
The format is Markdown primary, with a Word companion. Every change request is archived in the substrate repository at docs/phase-crs/.
A phase scoping note captures the decisions that define a phase before the change request is written.
Scoping comes first. What does this phase deliver? What is in scope, what is out? What decisions need to be made before the change request can be drafted? The scoping note answers these questions and records the Operator's choices.
The audience is the change request drafter — typically Claude — and the Operator reviewing the scope before committing to it. Scoping-note-before-change-request is a non-negotiable discipline: you cannot write precise instructions until the scope is settled.
The format is Markdown primary, with a Word companion.
A phase handoff bridges two sessions.
When a phase spans multiple Claude sessions — or when a fresh session needs to pick up where the previous one left off — the handoff captures what happened, what was decided, what is ready to do next, and what the Operator needs to know. It is the minimum viable context for continuity.
The audience is the fresh Claude session picking up the work, and the Operator confirming that the handoff captures the correct state. A good handoff means the new session does not need to re-derive what the previous session already established.
The format is Markdown primary, with a Word companion.
Phase implementation notes record what the executing agent actually did.
A change request says what to build. Implementation notes say what was built — including pragmatic interpretations, unexpected findings, and deviations from the change request. They are written at the end of a phase, after the work is done, as part of the acceptance gate.
The audience is future change request revisions (what did we actually do last time?), the manifest (absorbing the phase into the project record), and the Operator (verifying that what was built matches what was intended).
The format is Markdown.
The project state manifest is the canonical orientation document for the project.
It tells a fresh session everything it needs to know: what documents are authoritative, what the substrate and frontend states are, what vocabulary is in force, what residues are open, what the completion plan looks like. Every fresh chat reads the manifest first.
The manifest is a current-status record, not a foundation. It sits above the methodology document and names what is authoritative versus superseded. It absorbs each completed phase and carries unconsolidated memory from sessions that have not yet been folded into the methodology.
The format is Markdown primary, with a Word companion. Versioned — each phase produces a new version.
A standing note carries a decision or observation that applies across multiple phases.
Unlike a change request (which is phase-specific) or the manifest (which is the full project inventory), a standing note isolates one topic that future phases need to reference without re-deriving it. Examples: a boundary decision between two system layers, a testing discipline that applies to all future phases, a design constraint that was settled once and should not be revisited.
The audience is Claude and Claude Code across future phases. A standing note exists because the alternative — re-explaining the same decision in every change request — is fragile and invites drift.
The format is Markdown, with an optional Word companion.
An infrastructure change request instructs project-level changes that do not belong to a numbered build phase.
Operational amendments, script-based data corrections, cross-cutting tooling changes, and one-off substrate modifications that span multiple phases — these are infrastructure work. They follow the same change request discipline (steps, checkpoints, acceptance gate) but are not assigned a phase number.
The audience is Claude Code executing the change. The format is Markdown.
The engagement seed is the founding document of an engagement.
It declares what the engagement is about, who consumes its output, what shape types and render types it commits to producing, and the voice and constraints that govern how knowledge is contributed. The seed is written before the engagement begins and is amended as the engagement matures.
Every engagement has exactly one seed. The seed is versioned — amendments produce new versions while preserving the history. The seed is both a governance document (what we committed to) and a reference document (what the engagement actually produces).
The audience is the engagement itself — the Operator, contributors, and the system reading the seed to know what to produce. The format is Word primary, with a Markdown companion.
A discovery record preserves the trajectory of a specific inquiry.
It records not just what was decided, but how the decision was reached: the alternatives considered and set aside, the corrections that landed, the moments where something new crystallized. The negative paths — what was tried and rejected — are as important as the final position.
The audience is future methodology revisions and anyone reviewing how a decision arrived. A discovery record is built from chat sessions and working notes, but it is not a transcript — it is a curated record of the inquiry's path, organized so that someone reading it later can reconstruct the reasoning.
The format is Markdown.
The methodology document presents the methodology as a single coherent document.
It is not a collection of phase change requests or a running log. It is a deliberate synthesis: what the methodology is, how it works, what its principles are, how the pipeline operates, what the vocabulary means, and how the current position was reached. It absorbs corrections, incorporates discoveries, and reflects the current state of the methodology's development.
The audience is future Claude sessions orienting to the project, the Operator as reviewer, and anyone who might implement the methodology elsewhere. The format is Word primary, with a Markdown companion.
The philosophy and architecture document presents the broader vision that the methodology serves.
Where the methodology document describes how the system works, the philosophy and architecture document describes why it works this way — the design principles, the architectural decisions, the thesis about where engagement-memory work fits in the landscape. It is the document that explains the "why" behind the "how."
The audience is future product-vision work and the Operator as primary reader. The format is Markdown.
A concept reference explains a single methodology or system concept in plain language.
What Memory is. What an engagement is. What designations mean. What a seed is and why it matters. How the Loom Protocol relates to the methodology. Each concept reference takes one idea and makes it clear to someone encountering it for the first time.
Concept references are educational — they are not build documentation. They do not assume the reader has followed the project's development. They start from "what is this thing?" and explain it with enough context that the answer is genuinely useful.
The audience is any person in the system. The format is rendered for the engagement overview surface.
A contributor guide is practical guidance for participating in engagements.
How to contribute knowledge. How to read an engagement overview. How to use the dashboard. How designations work in practice. A contributor guide takes a task — something the person actually needs to do — and explains how to do it, step by step, without assuming prior familiarity.
The difference from a concept reference: a concept reference explains what something is; a contributor guide explains how to do something. One is knowledge, the other is instruction.
The audience is new and intermediate Contributors. The format is rendered for the engagement overview surface.
DUNIN7 — Done In Seven LLC — Miami, Florida Phase 28 — Explanation assertion drafts — v0.3 — 2026-04-30