Loomworks — The Architecture, and What's Built — v0.1

Version. 0.1 Date. 2026-05-31 Drawn from. candidate-seed v0.9 (the intent — the rooms, modes, render-types, commitments) read against current-status manifest v0.47 (what exists, what's in flight, what's residue). The built/intended line is my own reading of the two. Status. A status view — visual companion to the architecture specification (architecture/loomworks-architecture-specification-v0_4.html). HTML primary at loomworks-workflow-status-diagram-v0_1.html; this is the Markdown source. The verified v0.3 workflow document is a separate, not-yet-produced artifact. Perishability. This diagram carries a point-in-time status layer (built / in flight / intended); for live numbers and current state see the highest-numbered current-status manifest, and future status shifts are handled as new versions (v0.2…).

Status key

Applied per capability, not per room:

• ● Built — in main today.
• ◐ In flight — partial / residue / deferred-with-a-gap-stated.
• ○ Intended — committed by the seed, not yet built.

The seed commits to a four-room pipeline that eventually runs autonomously. The manifest shows the substrate of that pipeline is largely built, while the engagement still produces its own Renders by hand. Each room carries its capabilities with their own status. The labels between stages name what passes.

The pipeline

Entry · contribution into Memory

• ● Built — Contribution + provenance. Typed, spoken, from a document, from an image; who/when/how recorded automatically; lands as an assertion. Source-identification unified turn provenance onto the actor model. (manifest Entry 106; seed §Memory)
• ● Built — Upload pathway → UploadEventReceived. Files reach Memory at event grain with full provenance; reachable through the in-engagement composer. (manifest §78; Phase 58/59)
• ○ Intended — Upload content → assertion grain. Drafting held assertions from upload events is not built — upload content sits beside the assertion surface, not within it. (queued-directions §15.3)

↓ passes: an assertion, with provenance

Memory — accumulate · ● Built

• ● Built — Accumulation, corrections preserved, lineage. The source room; never forgets; superseded/retracted assertions stay visible. (seed §Memory)
• ● Built — Personal memory (per person). Per-person memory with a held→committed lifecycle; the three-bug persistence cascade fixed and recovered. (queued-directions §16.2; Phase 43)
• ● Built — Public-by-default commons. The Loomworks engagement's Memory is visible to everyone; automatic membership at signup. (seed §The universal commons; Phase 15)

↓ passes: the seed + all committed assertions

Manifestation — derive / organize · ● Built (engine)

• ● Built — Derivation → organized, versioned reading. Reads seed + committed assertions into a structured ordering; a reading of Memory, not a copy; re-derived and superseded. (seed §Manifestation)
• ◐ In flight — Operator-facing room surface. The four-room internals UI (Workshop) is intentionally frozen at Phase 45; the live product is the Operator Layer, which centers on the Companion conversation, not the room internals. (manifest §76)

↓ passes: organized knowledge — a Manifestation

Shaping — select for a reader · ● Built (engine)

• ● Built — Shaping agents + 5 declared shape-types. Reader-need-driven selection/emphasis/omission; shape events and shaping executors in the engine. (seed §Shaping, §Declared shape-types; Phases 9/21/23/40)
• ◐ In flight — Operator-facing Shaping surface. Same Workshop freeze; the room exists in the engine, the surface for it is not the active product. (manifest §76)

↓ passes: a Shape — material for one reader

Rendering — produce what the reader gets · ◐ Split

• ● Built — Render substrate (Mode A mechanism). Registered render specialists, external-service polling, render content kinds, incremental re-render. The machinery for Loomworks-owned production exists. (Phases 10/22/27/34/35/36)
• ○ Intended — Autonomous production of the 13 declared render-types. The engagement's own documents (methodology docs, manifests, CRs, scoping notes, this diagram) are produced today by Claude under Operator direction — not yet by registered substrate specialists against the seed. (seed §Declared render-types: "Today, the specialist is Claude")
• ○ Intended — Mode B (specification to external system). Loomworks produces a spec an outside system builds (e.g. REQ → Claude Code builds the app). Architecture supports it; all current declared render-types are Mode A; no Mode B type declared yet. (seed §Rendering, §240)
• ○ Intended — Commons educational render-types (concept reference, contributor guide). Declared for "every person in the system," rendered from living Memory — not yet produced. (seed §Commons render-types, §Success conditions)

↓ passes: a Render — the artifact (A) / a spec built outside (B)

The reader · four declared consumers

• ● Built — Operators & contributors — the live product surface. The Operator Layer: dashboard, inbox, chat, settings, engagement-navigation, the Companion, approval cards, the new Spend surface. (manifest §78; Phase 46+, 66)
• ◐ In flight — Long-conversation surface (pagination at scale). Primary surface fetches 50 turns once, no load-earlier; scoped as the Axis 11 item, not yet built. (queued-directions §16.3; Axis 11 scoping note)
• ○ Intended — Every person in the system — the commons consumer. Educational consumption depends on the commons render-types above, which aren't built yet. Future-implementer consumption is longer-horizon. (seed §Who consumes the work)

The ground the pipeline stands on — not stages in it

• ◐ Built / in flight — Identity — UUID, no-email-as-identity, passkey sign-in. The identity model and passkey sign-in surface exist; real-passkey registration on the dev RP-ID is unresolved (dev uses the /auth shortcut), so the passkey path isn't proven end-to-end. (seed §Authentication; queued-directions §13.3)
• ● Built — Solvency — credit gate + spend visibility & pause. Prepaid hard gate over the three model-rooms; per-run spend visible; default-on approval pause for async spend. (manifest Entries 107/108; Phases 64/66)
• ○ Intended — Lineage anchoring — FORAY (tamper-evident). Provenance is recorded; but FORAY anchoring is a seam-marked no-op at 16 reserved sites — FORAY is framed as an external service Loomworks will call, not yet wired. (manifest §74, §4.B; seed §Constraints)
• ○ Intended — Access control — OVA. Named as the candidate access substrate (provisional patent filed March 2026); not built. (seed §Constraints)
• ○ Intended — Federation across Loom environments. Architecture doesn't foreclose cross-environment reference; single-instance use is what runs today. (seed §Constraints)

Where intent and status diverge

The four-room substrate is built — Memory, Manifestation, Shaping, and the Mode-A render machinery all run in the engine — and a solvency layer now meters and gates the pipeline (Phases 64/66). The Operator Layer is the live surface; the Companion drives it.

The largest gap is the seed's own recursion: it commits to an engine that produces the engagement's declared render-types autonomously. Today the engagement still renders itself by hand — Claude as specialist under Operator direction produces the manifests, CRs, scoping notes, and this very diagram. The render mechanism exists; it has not been turned on the engagement's own document stream.

The rest of the committed-but-unbuilt frontier: Mode B (specification to an external builder), the commons educational render-types, FORAY anchoring (seam-marked, not wired), OVA access control, and federation. In flight or residue: the passkey path end-to-end, upload→assertion grain, conversation pagination, and the deferred Manifestation-pause (Phase B). By the seed's own scope statement (§131), the product lifecycle's other stages (1–3, 5–6) are out of current scope, not behind.

DUNIN7 — Done In Seven LLC — Miami, Florida Loomworks — Architecture & Status (Intent vs. Built) — v0.1 — 2026-05-31