Version. 0.1 Date. 2026-04-17 Status. Standing note for the Loomworks project. Surfaces during any Loomworks phase that touches Render-shaped work. Primary relevance: Phase 9 (projections, Sec-C of the spec). Secondary relevance: any earlier phase whose HTTP surface produces artifacts whose consumers have specialist-specific requirements. Origin. Surfaced during the final exchanges of the Loomworks Phase 5 chat, 2026-04-17, as Marvin was separating a Render discovery conversation into its own project. Now a committed scoping principle in the Render discovery. Carried here into the Loomworks project so Loomworks work that approaches Render-shaped territory has the principle available when it gets there.
Knowledge of specialist-specific requirements belongs to the specialist layer, not upstream. A Shaped set is specialist-agnostic — it carries what specialists will need without formatting for any one. A rendered artifact is specialist-specific — it is produced by a specialist (or a specialist chain) that knows its own consumer. Pulling specialist-specific knowledge upstream into Shaping would reproduce inside Shaping the same unknowable-specialist-population problem the Render framework is being built to solve. Therefore: the framework must hold specialist knowledge in specialists, with the framework governing the interface.
A test of any proposed move's layer: does this require knowledge of a specific specialist's requirements? If yes, Render. If no, Shaping.
Loomworks is a playground built on the Loom Protocol. The playground spec (v0.10) commits, in Sec-C, to projections — the mechanism by which the playground produces renders from its memory. Phase 9 of the Loomworks build implements Sec-C. When Phase 9's CR is drafted, the Shaping/Render boundary discipline must be understood and honoured by the CR's construction decisions. Specifically:
The boundary discipline also matters for phases before Phase 9, whenever a CR proposes an HTTP surface whose consumer is something other than "any authenticated contributor reading JSON." Examples: a Phase 8 contributor-operations surface that produces audit reports; a Phase 6 design-intent surface that emits intent-amendment artifacts; any phase that considers producing a PDF, a CSV export, a webhook payload, an email body. Each of those is a Render specialist the CR needs to recognize as such — not disguise as "a response format" that Shaping-side selection logic pretends to know about.
Phase 5 (considerations and terminal states — currently in execution) does not touch Render. Its HTTP surface returns JSON representations of memory objects, which is the traffic-cop-free generic-specialist case — the consumer is the Loomworks API client, which expects JSON, and no specialist dispatch is involved. The principle applies in the trivial sense only: JSON serialization is a Render specialist, its requirements are well-known, the CR implicitly handles it, and no Shaping-layer drift is possible. Phase 5 does not need to be amended on account of this note.
Phases 6 (design intent) and 7 (cadence configuration) similarly do not visibly touch Render work. If their CRs, when drafted, find that they do, the principle applies and the CR should cite this note.
Phase 8 (contributor and agent operations) may touch Render-shaped work if its surface produces report-like artifacts. The Phase 8 CR should include a section checking the principle before committing construction decisions.
Phase 9 (projections) definitely touches Render. The Phase 9 CR must cite this note, treat the principle as binding, and stress-test its construction decisions against it.
The handoff document that carries Phase 5's completion forward to Phase 6 should reference this note in its "conventions to honour" section, alongside section-reference conventions, versioned-filenames discipline, Discovery-record posture, and skill-vs-agent distinction. The convention name is Shaping/Render boundary discipline. Every subsequent Loomworks phase handoff inherits the convention through the chain.
The Phase 9 CR specifically — when it is drafted, probably in a chat several months from now — should:
Phase 5 is in execution. Amending the Phase 5 CR to contain this principle would be scope-creep on an active build, and the principle does not affect Phase 5's correctness. Adding the principle to the Loomworks construction brief would be a methodology-level commitment that the Render discovery has not yet earned the right to make — the discovery is at day zero; its commitments are scoping principles for itself, not yet general commitments for Loomworks.
A standing note sits between the two. It records the principle in the Loomworks project's knowledge base so future Loomworks phases see it when they need to, without asserting a methodology-level commitment the Render discovery has not yet worked through. When the Render discovery reaches a resting point (Discovery record, framework specification, or whatever its output turns out to be), Loomworks phases can cite the stable output. Until then, this note is the interface between an active build and an active discovery.
The Render discovery is being run in a separate project, opened 2026-04-17. Its v0.2 handoff is the record of what the discovery inherits from the Phase 5 chat, including the principle captured in this note. Anyone working on a Loomworks phase that touches Render should consider reading the Render project's current state (the v0.X Discovery record, whatever version is current) before drafting the phase's CR. The reverse is not required — the Render discovery does not need to track Loomworks phase progress.
DUNIN7 — Done In Seven LLC — Miami, Florida Loomworks Standing Note — Shaping/Render Boundary Discipline — v0.1