Version. 0.1 Date. 2026-05-17 Author. Marvin Percival (DUNIN7 Operator) with Claude.ai. Status. Observation cluster. Surfaces issues observed on the live marketing page at https://loomworks.doneinseven.com/ as of 2026-05-17, plus connected observations about Loomworks methodology and codebase that surface alongside the marketing page review. Each observation is named and routed (immediate fix / Phase 60 scope / Phase 61+ candidate / v0.21 methodology candidate / queued-direction entry). The document does not prescribe execution — it routes the observations so they enter the right work stream.
What this document does. Records observations made on 2026-05-17 about (a) the live Loomworks marketing page at https://loomworks.doneinseven.com/, which contains room-description and room-order errors that contradict the actual codebase, and (b) connected methodology and codebase observations that surfaced during the marketing-copy review. Each observation is routed to the right work stream — immediate fix, Phase 60 absorption, Phase 61+ candidate, v0.21 methodology candidate, or queued-direction entry — so the work doesn't get conflated.
What's most urgent. The marketing page is publicly visible and contains errors that misrepresent what Loomworks actually does. The "What Loomworks is" body uses the wrong room order and wrong room descriptions. The page also contradicts itself: the hero subhead has rooms in correct order; the body has them in wrong order, ~50 words apart. Recommended action: marketing-page copy update before any further public-facing communication.
What's connected but not urgent. Five observations about Loomworks methodology and codebase surfaced during the marketing review. None are blocking. Each is routed: render-specialist boundary clarification (v0.21 or v0.22 methodology candidate); marketing-copy-versus-codebase drift discipline (v0.21 candidate); room-description authoritative-source question (v0.21 candidate); declaration vs. assertion vocabulary clarification (small docs fix); plain-terms-discipline check on user-facing surfaces (Phase 60+ candidate).
What's out of scope for this document. Fixing the marketing page (separate work; this document specifies what needs to change). Phase 60 scoping (separate session). v0.21 methodology consolidation (separate dedicated session; this document feeds candidates into it).
Operator decisions needed.
Observed: The body reads "Memory (what's known), Shaping (how work organizes), Rendering (how artifacts come together), and Manifestation (how artifacts ship into the world)."
Should be: Memory → Manifestation → Shaping → Rendering.
Source for correct order:
loompa-geology-field-example-v0_1.docx: "a four-stage pipeline: Memory accumulates knowledge, Manifestation organizes it, Shaping selects and structures it for a specific consumer, and Rendering produces the final artifact the consumer receives."phase-22-cr-rendering-room-ui-v0_1.md §17 post-CR state: "Full pipeline: Memory → Manifestation → Shaping → Rendering live in the UI."Severity: High. Public-facing page misrepresents the architecture's core sequencing.
Observed: The body assigns:
Should be:
Source for correct descriptions:
room-explanations-and-expandable-scope-v0_1.md (the authoritative room-explanation document; assertions #13–#16 contributed to Loomworks engagement's Memory). Verbatim source for each room's function.loompa-geology-field-example-v0_1.docx four-stage pipeline summary.Severity: High. Each room's function is misrepresented; the cumulative effect is that a reader cannot correctly understand what Loomworks does.
Observed: The hero subhead lists rooms in correct order ("Memory, Manifestation, Shaping, and Rendering"). The body, ~50 words later, lists them in wrong order ("Memory, Shaping, Rendering, and Manifestation").
Severity: Medium independent of 1.1/1.2 — even before correcting descriptions, the internal contradiction signals to attentive readers that the page wasn't carefully reviewed.
Observed: "Asserts can hold or commit; drafts can revise..."
Should be: "Assertions" (the Loomworks-vocabulary noun). "Asserts" reads as a verb-used-as-noun and likely a typo.
Source:
room-explanations-and-expandable-scope-v0_1.md: "An engagement with a hundred assertions knows more than it did at ten."phase-15-cr-loomworks-universal-commons-v0_1.md §8.1: "Every piece of knowledge enters Memory as an assertion."Severity: Low (typo-grade) but should land in the same revision.
Observed: "drafts can revise" — drafts don't revise themselves; they get revised.
Should be: "drafts can be revised" (passive; matches Phase 45 D9 request_revision intent which proposes re-production of drafts via Operator request).
Severity: Low (grammar-grade).
Observed: The current "how artifacts come together" framing for Rendering (even setting aside the wrong-room-assignment issue) suggests Loomworks produces artifacts end-to-end.
Should be: Rendering produces either (a) the artifact directly when Loomworks owns the production (PDF, docx, xlsx, audio, conversation), or (b) the specification that a downstream production system consumes (app spec for Claude Code, design spec for a manufacturer, contract spec for a legal drafter). The render layer doesn't anticipate every production environment; it supplies the inputs each one needs.
Source: This framing surfaced in conversation on 2026-05-17 and is not yet in any authoritative source document. Per Operator: "Loomworks may simply produce the REQ file (spec) that is then fed into a production system (Claude Code). The render system cannot anticipate the future production environments but it can supply the inputs."
Severity: Medium — this is true to current architectural reality but not yet documented in methodology, which means the marketing-page fix lands ahead of the methodology consolidation. See Section 3.1 for the methodology routing.
Replacement text for the "What Loomworks is" section, grounded in authoritative sources:
> A four-stage pipeline for agentic work. The Companion is your surface to it: the same interlocutor through Memory (what's known), Manifestation (how that knowledge hangs together), Shaping (how it's arranged for a specific reader), and Rendering (the artifact they receive, or the specification that produces it). > > Memory accumulates the engagement's knowledge — source materials (files, documents, recordings, spreadsheets) and contributed assertions, with provenance and the full trajectory preserved. Manifestation is a reading of Memory at a point in time: an organizing act that says how this body of knowledge hangs together right now. Shaping takes that organized knowledge and arranges it for someone specific — selecting, emphasizing, leaving out, according to what that reader needs. Rendering produces what the reader needs — directly when Loomworks owns the production (documents, reports, audio files, conversations), or as the specification a downstream production system consumes (an app spec for Claude Code, a design spec for whatever produces the final form). The render layer doesn't anticipate every production environment; it supplies the inputs each one needs. > > The same Memory and Manifestation produce different Shapings for different readers, and each Shaping renders into the form its reader needs. Each engagement is a persistent space. Assertions can hold or commit; drafts can be revised; delegations can be granted, scoped, or revoked. The Operator stays in the loop where it matters and out of the loop where it doesn't.
Hero subhead may stay unchanged (correct room order; reads cleanly).
"Try it" section may stay unchanged.
The hero subhead's "Memory, Manifestation, Shaping, and Rendering" sequence is correct. Worth preserving as evidence that someone got the order right at the hero level even while the body drifted. No fix needed; flagged so the fix to the body doesn't accidentally propagate to the hero where things are fine.
The marketing page lives outside the Loomworks codebase proper (it's at doneinseven.com, presumably static site hosting). Two options for the fix:
Option A: Direct edit. Operator (or whoever owns the marketing site) edits the page copy to match Section 1.7. Fastest path. Low risk because the page change is text-only and the change is sourced.
Option B: Route through the marketing engagement. The Phase 57 marketing engagement infrastructure exists in DUNIN7/loomworks-marketing repo per userMemories and Phase 51 close. If the marketing page is rendered from the marketing-engagement's render output, the fix routes through that. Higher discipline; uses the production pipeline for production output.
Recommendation: Option A for this fix specifically because the marketing page is publicly visible and contains misrepresentation; speed matters more than pipeline discipline for this one. For future marketing-copy revisions, route through the marketing engagement to test that the pipeline actually works end-to-end.
The methodology candidate this surfaces (marketing-copy-not-routed-through-marketing-engagement) is Section 3.2 below.
Each observation surfaced during the marketing page review. None block the marketing-page fix. Each is routed to the appropriate work stream.
Observation. The marketing copy revision in Section 1.7 introduces a new framing — Rendering produces either the artifact directly OR the specification a production system consumes. This is true to the current architectural state (PDF/docx/xlsx render specialists live in Loomworks; future render specialists for apps will hand off to Claude Code or similar external production systems). But this framing is not yet in any authoritative source document. room-explanations-and-expandable-scope-v0_1.md says only "Rendering produces the final artifact that the reader actually receives" — which was true at Phase 22 but is too narrow for current state.
Implication. The methodology document needs to absorb the render-specialist-boundary distinction. Phase 22's DeclaredRenderType registry assumed Loomworks-owns-production; as specialist integrations multiply, the registry needs to distinguish Loomworks-owns-production render types from handoff-to-external-system render types, and the architecture needs to express the seam.
Routing. v0.21 or v0.22 methodology candidate. Worth adding to the v0.21 consolidation slot (between Phase 59 close and Phase 60 scoping per P59-D10). Naming proposal: render-specialist-boundary-two-modes — names that Render operates in two modes (Loomworks-owned production vs. specification-to-external-production-system), and the boundary between them is methodology surface worth making explicit. The candidate carries this conversation's framing back to the methodology document.
Note for marketing copy. Section 1.7's framing lands ahead of methodology consolidation. Once v0.21/v0.22 absorbs the candidate, future marketing copy should align to the methodology's vocabulary rather than the marketing-copy-derived language. Discipline: the methodology document is authoritative; marketing copy reflects it; corrections flow from methodology → marketing, not the reverse.
Observation. The marketing page contains room-description errors and a wrong room order that contradict the authoritative codebase sources (room-explanations-and-expandable-scope-v0_1.md; Phase 18/21/22 CRs; userMemories; Loompa geology doc). The page has drifted from the codebase reality without anyone catching the drift until a manual review surfaced it.
Implication. No discipline currently exists for keeping marketing copy synchronized to methodology and codebase reality. The marketing page is edited independently of the codebase; the room-description authoritative source (room-explanations-and-expandable-scope-v0_1.md) lives in the project knowledge but isn't surfaced to whoever maintains the marketing site; methodology revisions don't trigger marketing-copy review.
Routing. v0.21 methodology candidate. Naming proposal: external-surface-copy-needs-codebase-sync-discipline — names that marketing copy, investor copy, partner copy, regulatory copy all consume Loomworks's vocabulary and must stay synchronized to authoritative sources. Worth a v0.21 entry surfacing the question: what's the mechanism by which marketing-copy revisions get reviewed against codebase reality? Candidate mechanisms: (a) marketing-engagement as the authoritative render pathway; (b) periodic external-surface audit (this document is the first instance); (c) marketing-copy review as a Phase 60+ checklist item before public revisions land.
Related to Section 3.5 below (plain-terms-discipline check on user-facing surfaces).
Observation. room-explanations-and-expandable-scope-v0_1.md was contributed to the Loomworks engagement's Memory as assertions #13–#16 at Phase 23 close. It contains the canonical room descriptions for Memory, Manifestation, Shaping, and Rendering. But the current marketing page didn't use it — the page's room descriptions appear to predate the room-explanations doc or were authored without reference to it.
Implication. When multiple documents could be authoritative for a piece of vocabulary, which is The Source? The candidate sources for room descriptions in Loomworks:
room-explanations-and-expandable-scope-v0_1.md — explicit room-explanation document; Operator-contributed assertions.what-dunin7-is-building-v0_20.md) — the authoritative methodology artifact per userMemories.Routing. v0.21 methodology candidate. Naming proposal: authoritative-source-hierarchy-for-loomworks-vocabulary — names that Loomworks's own vocabulary has a precedence ordering and the precedence should be explicit. Candidate ordering: methodology document → room-explanation assertions → phase CRs → seed → marketing copy. Marketing copy is downstream; it reflects upstream; corrections flow downward.
Observation. During the marketing-copy review I (Claude.ai) initially drafted "assertions made, declarations held, work history" as the Memory description and the Operator caught that "declarations" is the wrong word — declarations are seed-registered DeclaredShapeTypes/DeclaredRenderTypes (Phase 22+), not Memory-held items. The word "declarations" is reserved for engagement-level type registrations; Memory holds assertions with provenance and trajectory, not declarations.
Implication. Internal documents and Claude.ai-drafted artifacts may use "declarations" interchangeably with "assertions" or "claims" in ways that conflate engagement-type-declarations with Memory-asserted-claims. Worth checking whether any other Loomworks documents drift on this.
Routing. Small docs fix. Not a methodology candidate (the methodology vocabulary is correct; only some downstream documents may drift). Periodic vocabulary audit of Loomworks documents is a Phase 61+ task; not urgent. If a clean grep is feasible — search the codebase and project knowledge for "declarations" used in Memory-related contexts, confirm none of them conflate the two senses — that's a small bounded check. Worth doing at v0.21 absorption time when document-wide review is already in progress.
Observation. userMemories has plain-terms-discipline-protects-methodology-nouns as an established methodology principle: "Methodology nouns must remain first-class in source-of-truth documents; technical vocabulary belongs only in code-translation contexts." Applied to user-facing surfaces (marketing page, Operator Layer interface, Companion responses), the discipline means: Loomworks's methodology vocabulary (Memory, Manifestation, Shaping, Rendering, engagement, assertion, Operator, Companion) appears in plain terms; codebase shorthand (ExecutorResult.framing_kind, PurposeClassification, UploadEventReceived) doesn't leak through.
Implication. The marketing page mostly follows this discipline — it uses Memory/Manifestation/Shaping/Rendering as first-class methodology nouns. The Loomworks Operator Layer (the consumer-facing UI) also presumably follows this discipline at Phase 46+ but it's worth verifying. Phase 60 OL consumer surfaces (5 of them per Phase 59 carry-forward) all need to express Companion behavior in plain methodology vocabulary, not codebase shorthand.
Routing. Phase 60+ candidate (Operator Layer scope) + v0.21 methodology refinement. For Phase 60: the OL consumer surfaces for AskOperatorToClarify, AskOperatorForProcess, content-reliability warning, fallback affordance, and accompanying_message consumption all need to be reviewed against plain-terms-discipline before they land. For v0.21: worth surfacing the principle's application-to-external-surfaces dimension — the discipline isn't only about source-of-truth documents; it extends to every surface where a user encounters Loomworks vocabulary.
| Observation | Where it goes | When | |------------|---------------|------| | 1.1 Wrong room order (body) | Marketing page fix | Now (immediate) | | 1.2 Wrong room descriptions (body) | Marketing page fix | Now (immediate) | | 1.3 Page contradicts itself hero vs. body | Marketing page fix | Now (immediate) | | 1.4 "Asserts" → "Assertions" | Marketing page fix | Now (immediate) | | 1.5 "Drafts can revise" → "Drafts can be revised" | Marketing page fix | Now (immediate) | | 1.6 Rendering description doesn't acknowledge handoff mode | Marketing page fix | Now (immediate) | | 1.8 Hero subhead works (no fix) | None | n/a | | 3.1 Render-specialist boundary clarification | v0.21 or v0.22 methodology candidate | At v0.21 consolidation slot | | 3.2 Marketing-copy-versus-codebase-drift discipline | v0.21 methodology candidate | At v0.21 consolidation slot | | 3.3 Authoritative-source-hierarchy-for-Loomworks-vocabulary | v0.21 methodology candidate | At v0.21 consolidation slot | | 3.4 Declaration vs. assertion vocabulary check | Small docs fix; periodic vocabulary audit | At v0.21 absorption time or queued | | 3.5 Plain-terms-discipline on user-facing surfaces | Phase 60+ candidate (OL scope) + v0.21 refinement | Phase 60 scoping + v0.21 consolidation |
Decision 1: Approve marketing-page copy revision. Section 1.7 contains the replacement text for the "What Loomworks is" section. Hero subhead and "Try it" section unchanged. Approve text → queue marketing-site update via Option A (direct edit) or Option B (marketing engagement routing). Recommended path: Option A for this fix; Option B for future revisions.
Decision 2: Confirm routing of the five connected observations. Each observation in Section 3 has a recommended routing. Operator approves the routings or adjusts.
Decision 3: Determine who executes the marketing-page edit. This document specifies what needs to change; it doesn't execute the change. Marketing-site maintainer (Operator or designated) makes the actual edit.
room-explanations-and-expandable-scope-v0_1.md — authoritative source for room descriptions; assertions #13–#16 in Loomworks engagement Memory.loompa-geology-field-example-v0_1.docx — second-source for four-stage pipeline framing; verbatim "Memory accumulates knowledge, Manifestation organizes it, Shaping selects and structures it for a specific consumer, and Rendering produces the final artifact the consumer receives."what-dunin7-is-building-v0_20.md — authoritative methodology document.phase-15-cr-loomworks-universal-commons-v0_1.md — Phase 15 founding Memory assertions with verbatim Memory definition.phase-18-cr-manifestation-room-ui-v0_1.md — Manifestation room substrate grounding.phase-21-cr-shaping-room-ui-v0_2.md — Shaping room substrate grounding.phase-22-cr-rendering-room-ui-v0_1.md — Rendering room substrate grounding; verbatim "Render produces the consumer-facing artifact from a Shaping."phase-23-cr-shaping-room-redesign-v0_1.md — Shaping room redesign + DeclaredShapeType rename.phase-45-cr-delegation-contract-and-approval-cards-v0_1.md — delegation vocabulary source.DUNIN7 — Done In Seven LLC — Miami, Florida Loomworks Marketing Page Observation Cluster — v0.1 — 2026-05-17