Version. 0.1 Date. 2026-05-11 Status. Methodology investigation. Names a three-mode framing for what Loomworks engagements do: runtime, workspace, and authoring-environment. Each mode places the engagement in a different relationship to the work it produces, with different architectural disciplines required. Adds the REQ/CR loop as the load-bearing architectural property of the authoring-environment mode specifically. Internal/architectural audience. Author. Claude.ai (investigation layer). Operator: Marvin Percival. Provenance. The conversation followed the engagement domain composition investigation v0.1 and the manifest-of-difficulties exchange in which Claude asked the Operator what would be difficult to achieve with Loomworks. The Operator's responses converged on a recognition the methodology hadn't yet named: many of the apparent difficulties (high-frequency interaction, anonymous work, autonomous operation, visual aesthetics under maturing APIs) dissolved into a single pattern — Loomworks isn't the runtime for that work; Loomworks is the authoring environment for systems that handle that work. The engagement holds the domain of what gets built; the deployable artifact runs outside Loomworks at its own tempo. The recognition was initially framed as a binary (Loomworks as runtime vs Loomworks as authoring environment); the Operator pushed back with a question about what "workspace" means, surfacing that the three-mode framing (runtime / workspace / authoring-environment) is the cleaner cut. Claude initially conflated workspace with runtime; the three-mode trio is the corrected framing. The Operator then added a further sharpening: the engagement that produces the REQ for an application render must be able to receive CR and naturally deliver the REQ for the render refactor or additions. This added the REQ/CR loop as the load-bearing architectural property of the authoring-environment mode — the produced system and its authoring engagement maintain a continuing dialogue over the system's lifetime, with operational reality flowing back as CRs against the REQ. The four-turn trajectory (difficulties enumerated → binary framing → trio clarified → REQ/CR loop added) is preserved in §10 below. Informed by. Closed-loop engagement investigation v0.1 (the feedback-shape pattern; orthogonal to resident/delivery; canonical in Accounting Engagement's reconciliation evaluator). Resident-engagement investigation v0.2 (resident vs delivery as consumption locality; operational vs infrastructure as Memory-backing locality; closed-loop as feedback shape — all three as orthogonal axes). Engagement domain composition investigation v0.1 (N-domain composition; operational scope as a candidate scope when feedback flows back). Terms of Use Engagement investigation v0.2 (worked instance of workspace-mode authoring; two-axis versioning with rules and document versions). Structural defensibility investigation v0.1 (the FORAY chain of custody from REQ through render through deployment). Phase 47 Credit Management (canonical runtime-mode infrastructure engagement; the Accounting reconciliation evaluator is its closed-loop pattern). Phase 45 delegation contract and approval cards (substrate prerequisite for the deployed-agent case). Forge methodology (REQ-NNN format with CR-amendment cycle — the operative pattern this investigation generalizes to authoring-environment engagements).
Claude enumerated difficulties Loomworks would have to address — high-frequency interaction, anonymous work, adversarial Operators, autonomous operation, and others. The Operator's responses converged on a pattern the methodology hadn't yet named cleanly: most of the apparent difficulties dissolved when reframed as Loomworks produces the system; the system operates elsewhere. The engagement holds the domain; the deployable artifact runs outside.
This initial recognition (Claude framed it as binary) was correct but partial. The Operator's "Loomworks as workspace — explain" question surfaced that the binary framing collapsed two distinct cases:
The trio (runtime / workspace / authoring-environment) is the corrected cut. The three modes are not types of engagement; they are three modes an engagement can operate in. The same engagement architecture (Memory, four-room pipeline, render specialists, protocol triangle) supports all three; what differs is what happens after the engagement produces something.
The Operator then added the load-bearing sharpening for authoring-environment mode specifically: the engagement must be able to receive CRs about the produced system and naturally deliver a refactored REQ as its next render. This is what makes authoring-environment more than just "workspace with a deployed artifact" — it carries an architectural commitment to continuing dialogue with the produced system over the system's lifetime.
Five claims this investigation will defend:
The engagement is the runtime for the work it does. The Operator's actual value is realized inside the engagement — Memory holds the working state, the Companion mediates interaction, renders produce outputs the Operator consumes, the work concludes inside Loomworks.
Canonical instance: Credit Management. The credit work happens inside Loomworks. The engine's substrate holds the state. Reconciliation, balance maintenance, model-profile assertions, oracle rates — all are inside. The work doesn't ship anywhere else to be valuable; the substrate is the value.
Other runtime-mode engagements: the methodology engagement itself (this conversation is happening inside it); the standing-Companion engagement once built; engagement-creation assistance; Observer's view layer over shape Memory. These are all engagements whose value is realized in their own substrate, with no "produced thing" that operates elsewhere.
Architectural disciplines:
The runtime case is the architectural core of Loomworks. The substrate's discipline (protocol triangle, four-room pipeline, Memory governance) is shaped around the runtime case being trustworthy. The other two modes inherit from this core.
The engagement produces an artifact that's read or consumed. The artifact ships; gets read by an audience; doesn't act after production. The engagement's relationship to the artifact effectively ends at production, though further renders (new versions, updates, corrections) can be authored from the same engagement.
Canonical instance: Terms of Use Engagement. The rules accumulate in Memory; renders produce HTML, PDF, plain-text variants; the artifacts ship to readers; the readers consume them but don't generate operational feedback back to the engagement (other than objections via the bilateral-terms contribution channel, which is real but light-weight).
Other workspace-mode engagements: marketing pages; FAQs; press releases; research papers; reports; proposals; contracts; documents of all kinds; presentations; blog posts; book manuscripts. Most written deliverables are workspace-mode. The page-engagement / domain-knowledge-manages-uniformity recognition from earlier this session covers this category at scale.
Architectural disciplines:
The workspace case is the largest category by volume in Loomworks. Most written work fits this shape. The architecture absorbs it cleanly because the four-room pipeline, render lifecycle, and two-axis versioning are exactly what workspace-mode work needs.
The engagement produces a system that acts. The system ships; runs; produces consequences; calls APIs; has users; encounters reality. The engagement's relationship to the system continues after production through a structured feedback channel: the system reports back; the engagement absorbs the feedback as CRs against its REQ; the next render produces a refactored REQ that drives the next deployment.
Canonical instances (mostly future, not yet built): an authored autonomous agent that operates on the Operator's behalf; a built application with end-users; a deployed automation that runs against external systems; a high-frequency trading bot; an anonymous-user-facing platform whose creators (attested) authored its rules in Loomworks but whose users (not attested) operate it. Each is a system with its own runtime, its own users, its own behavior under conditions Loomworks doesn't govern in real time.
Closer to built today: the Credit Management Engagement's Accounting Engagement reconciliation evaluator pattern (Phase 49) — though Accounting reconciles within Loomworks, the same pattern extends to deployed systems where reconciliation happens externally and feeds back. The closed-loop engagement investigation v0.1 named this pattern; authoring-environment mode is its more demanding instance.
Architectural disciplines:
The authoring-environment case is the highest-leverage category in Loomworks. One well-authored autonomous agent or built application can produce more value than a thousand workspace-mode documents. The architectural extension to support it (delegation credentials; deployed-system audit substrates; structured CR intake; the REQ/CR loop discipline) is real work but bounded.
This is the architectural commitment that distinguishes authoring-environment from workspace. Without it, the engagement is write-once and the produced system drifts from its authoring substrate; with it, the engagement and the system stay coherent over the system's lifetime.
The REQ — specification of what the produced system is — lives in the engagement's Memory as a structured artifact. It is itself composed across N scopes (engagement-specific rules, organization-scope commitments, jurisdiction-scope regulatory floor, audience scope where relevant). The REQ at any moment is what would render the produced system if a render were triggered now.
CRs arrive from operational reality. A user reports a bug. A regulator requests a clarification. The system itself logs an anomaly. A monitoring tool detects drift. An end-user requests a feature. Each CR is structured: it has a source (attribution), a description (what's being requested or reported), a target (what part of the REQ it bears on), a timestamp (when it arrived), and a structured proposal (where possible — what the requester thinks should change). The CR is itself an assertion in Memory, going through held-then-commit governance, attributable, contestable, supersession-threaded.
When the engagement is ready to render the next version of the system, the render specialist composes the existing REQ with the accumulated CRs. The CRs may be:
The next render produces a new REQ version, with the CRs that were adopted threaded through the version's history. The deployed system is updated to match the new REQ; the chain of custody from CR-received through REQ-amendment through render through deployment is FORAY-attested.
Authoring-environment mode requires four disciplines that workspace mode doesn't:
The Forge methodology already operates this way. REQ-NNN as the specification format; CRs as the amendment mechanism; the cycle produces evolved specifications over time. The Forge case is managed specifications for internal artifacts — software components, system designs, organizational processes. The recognition this investigation makes is that the same pattern generalizes to managed specifications for deployed external systems — the same REQ/CR discipline applies when the artifact being managed is operational rather than internal.
The methodology's existing REQ-NNN format remains the operative shape; what the engagement-modes investigation adds is the frame that names where this pattern applies (authoring-environment mode specifically), how it composes with the rest of the architecture (closed-loop's authoring-environment-mode instance), and what the architectural commitments are when adopted.
This is worth absorbing into v0.21 as a named generalization: the REQ/CR pattern from Forge applies to all authoring-environment engagements in Loomworks.
The other modes can operate without continuous loops. A runtime-mode engagement doesn't have a produced system to maintain dialogue with; the engagement is the runtime. A workspace-mode engagement may receive light feedback but doesn't need structured CR intake; the rendered artifacts are consumed but don't operate.
The authoring-environment mode can't operate without the REQ/CR loop and still be coherent. A produced system without a continuing relationship to its authoring substrate is just a deployed thing that drifted from its design. Operational reality always teaches the design things the design didn't anticipate; without a feedback channel, those lessons are lost or get encoded informally outside the methodology, and the engagement's substrate ceases to reflect what the system actually is.
The REQ/CR loop is what makes authoring-environment mode an engagement in Loomworks's sense rather than just a one-shot production tool. Without the loop, you have a code generator; with the loop, you have an authoring environment that maintains the system over its lifetime.
The trio is one axis among several that the methodology has accumulated. Worth working through how it composes with the others, because the existing axes don't replace each other and the trio doesn't replace them either.
From resident-engagement investigation v0.2. Resident engagements have consumers inside Loomworks; delivery engagements ship artifacts to consumers outside.
Composition with the trio:
So: runtime → always resident; workspace → typically delivery with some resident exceptions; authoring-environment → always delivery with strong resident scaffolding.
From resident-engagement v0.2 and the manifest. Operational engagements have Memory the engine doesn't depend on; infrastructure engagements have Memory the engine reads on the hot path.
Composition with the trio:
From closed-loop engagement investigation v0.1. Closed-loop engagements consume their own renders as observations or refinements; open-loop engagements ship renders without feedback.
Composition with the trio:
So: closed-loop is orthogonal to the trio in runtime and workspace modes, but required for authoring-environment mode, with the REQ/CR loop as the specific shape.
The Terms of Use Engagement: workspace + delivery + operational + open-loop-with-bilateral-terms-objections. Renders ship outside; engine doesn't read its Memory on hot path; light feedback channel for objections but no structured CR loop.
Credit Management: runtime + resident + infrastructure + closed-loop. Engine reads credit Memory on hot path; reconciliation evaluator produces corrective renders that feed back into the same engagement.
A future deployed-bot engagement: authoring-environment + delivery + operational + closed-loop-as-REQ/CR-loop. Bot is deployed outside; engine doesn't read bot's runtime substrate; CRs from bot operations and external feedback flow back to drive REQ refactoring.
The four axes describe orthogonal properties; each engagement instances values on all four. The trio is one axis among four; the methodology's engagement taxonomy is four-dimensional.
The universal adapter operates in three modes. Engagement-as-universal-adapter doesn't fix the count of modes any more than it fixes the count of engagement types — the adapter accommodates whichever mode the supplied domain calls for. Runtime engagements supply domain for substrate work; workspace engagements supply domain for content production; authoring-environment engagements supply domain for system specification.
The trio doesn't introduce new substrate; it names how the existing universal adapter is being used in three different relationships to work.
The N-domain composition recognition gains a candidate scope in authoring-environment mode: operational scope. CRs from the deployed system's operation are domain — they describe what the system is encountering, what's needed, what's broken — and they compose with engagement scope, organization scope, jurisdiction scope, etc. when the next REQ is authored. Operational scope is on the same composition list as the other scopes.
This composition has a specific shape: operational scope's contributions are evidence-based (here's what happened; here's what was requested) rather than normative (here's what should be). The render specialist composes the evidence-based operational scope with the normative other scopes to produce the next REQ. The governance discipline for distinguishing evidence from norms is real methodology work the architecture hasn't yet articulated.
The structural defensibility investigation v0.1 named rules-in-Memory plus upstream OVA enforcement plus mechanical FORAY attestation as the load-bearing posture. Authoring-environment mode extends this across the deployed-system boundary.
The chain of custody is: composed REQ at moment T → render produced at moment T → deployable artifact at version V → deployed at moment T' → operational reality from moment T' onward → CRs arriving from moment T' onward → composed REQ amendments → next render at moment T'' → next deployable at version V' → next deployment at T''. Every step in this chain is FORAY-attested at the Loomworks side. The deployed system's own operational attestation (if it carries one) extends the chain beyond Loomworks.
This is what makes authoring-environment mode genuinely defensible: compliance investigation can trace from any deployed-system behavior back through the CRs, the REQ versions, the rule-set compositions in effect at each version, and the production events. "Why did the system do this in March" becomes a queryable composition across the trail.
The standing Companion (queued directions Section 10) is the right surface for Operator interaction with deployed systems. The bot reports a problem; the standing Companion surfaces it to the Operator under their declared proactive scope (Section 10.3); the Operator considers whether to file a CR through the engaged Companion in the relevant engagement. The standing-Companion-to-engaged-Companion mode handoff (Section 10.4) is the operational pattern.
This composes naturally. The deployed system reports to the engagement's CR intake channel (programmatic). The engagement's standing Companion notices accumulation patterns (multiple similar CRs; threshold severity; long-standing items). The standing Companion surfaces to the Operator proactively. The Operator switches to the engaged Companion to author the CR disposition (adopt; modify; decline; defer). The engaged Companion's work feeds the next render.
Observer (queued directions Section 11) operates at fleet level and is content-blind. For authoring-environment-mode engagements specifically, Observer can surface shape patterns across deployed systems — "deployed systems from authoring-environment engagements of class X are accumulating CRs at rate Y; the threshold for methodology drift is being approached." This is methodology-validation feedstock for the architecture's own learning: which authoring-environment patterns are working; which are accumulating CR debt; which are stable.
Observer can't see what any specific deployed system does (content boundary); it can see the shape of CR flow into authoring-environment engagements. This is genuinely useful and composes with Observer's existing surfacing categories (Section 11.6).
The Operator authors a trading bot inside Loomworks. The engagement's Memory composes:
The render specialist for trading-bot engagements (Population-1 or Population-2 specialist) produces the bot's deployable: code, configuration, deployment manifest. Version 1.0 ships to the operational environment.
The bot operates. It executes trades. It encounters market conditions the design didn't fully anticipate. It logs anomalies. End-users (if any) request features. Regulators issue clarifications. Each becomes a CR arriving at the engagement's CR intake channel.
CR examples:
Each CR is governance-bearing. Each disposition is attested. The next render of version 1.1 produces a refactored REQ that addresses the adopted CRs. The deployed-system version updates. The chain of custody is queryable.
Already worked through in the Terms of Use Engagement investigation v0.2. Re-positioned here:
This is workspace mode, not authoring-environment. The Terms of Use ships; gets read; doesn't act after production. The bilateral-terms objection channel is light-feedback, not structured CR. If a Terms of Use Engagement were reframed as authoring-environment (e.g., the rules drive an enforcement system that runs externally with its own operational reality), then structured CR intake would apply. As currently designed, it's workspace.
This is worth flagging because the architecture's discipline is different. The Terms of Use can be amended through governance; the deployed enforcement substrate (Loomworks itself) operates under the rules; but the rules' relationship to operational reality is one of OVA enforcement, not REQ/CR loop. The rules govern; the engine enforces; there's no "deployed system" separate from Loomworks itself.
Already worked through in queued directions and the resident-engagement investigation. Re-positioned here:
This is runtime mode. The credit work happens inside Loomworks. There's no produced system that operates elsewhere. The closed-loop pattern (Accounting reconciliation evaluator) is internal — the engagement observes its own state and produces corrective renders that change the engagement's state.
This is what makes Credit Management runtime rather than authoring-environment. If a future engagement produced an external credit-management system that ran on partner infrastructure with its own operational reality, that would be authoring-environment with a REQ/CR loop. Credit Management as currently built is runtime.
The Operator authors a customer-service agent inside Loomworks for their business. The engagement composes engagement scope (the agent's behavior, escalation rules, knowledge base, voice), organization scope (the business's brand voice, support policies, contact information), and audience scope (which customer segments the agent serves with what register).
The render produces the agent's deployable. It ships to the operational environment (the business's website or messaging platform). It serves customers.
CRs flow back:
The business owner interacts with the deployed agent through the standing Companion (proactive surfacings about CR accumulation; mode-handoff to engaged Companion for CR disposition). The agent itself reports CRs programmatically through the engagement's CR intake channel. The next render produces version 1.1 of the agent; the agent updates in deployment; the chain is FORAY-attested.
This is the canonical authoring-environment example. Almost everything Loomworks could add to the customer-service-agent market is an instance of this pattern.
Three implications for how new engagements are designed.
The engagement-creation flow should surface "what mode is this engagement operating in?" as part of seed drafting. The Operator's answer shapes which disciplines apply:
This is engagement-design work that the methodology hasn't yet articulated. The engagement-creation queued direction (Section 1.1) should absorb mode declaration as a first-class concern.
Render specialists are typed by what they produce. The trio sharpens this:
The Specialist SDK (Population 1/2/3) should differentiate by mode. Population-1 specialists for runtime-mode renders (engine-side) differ from Population-1 specialists for workspace-mode renders (which differ from Population-1 specialists for authoring-environment-mode renders). The mode dimension is a load-bearing axis for specialist categorization.
FORAY attestation discipline varies by mode:
Authoring-environment mode is the most attestation-intensive. The substrate sizing for FORAY in authoring-environment engagements is meaningfully higher than for workspace mode. Worth planning for.
Three for v0.21 consolidation.
Name the trio explicitly. Most engagement-design conversations to date have implicitly mixed runtime, workspace, and authoring-environment cases without distinguishing them. Naming the three modes makes the differences architecturally visible and lets future capability work attach to the right mode.
The trio composes orthogonally with three existing axes (resident/delivery, operational/infrastructure, closed-loop/open-loop) into a four-dimensional engagement taxonomy. v0.21 should consolidate the four axes as the methodology's engagement classification.
Name the REQ/CR loop as load-bearing for authoring-environment mode specifically. Without the loop, the engagement is write-once and produced systems drift. With the loop, the engagement maintains continuing dialogue over the system's lifetime.
The REQ/CR pattern from Forge generalizes here. The methodology should absorb this generalization: REQ-with-CR-amendment from Forge is the operative pattern for all authoring-environment engagements in Loomworks.
The engagement-creation discipline should require mode declaration as part of seed drafting. The mode shapes which disciplines apply, which render specialists are appropriate, which audit substrate sizing is needed. Without explicit mode declaration, engagements drift into hybrid shapes that don't serve any mode well.
The engagement-creation queued direction (Section 1.1) needs this absorbed. The Discovery-to-seed flow should ask "what is this engagement producing and how does the production relate to operational reality?" as a structuring question.
The recognition moved through four turns:
Each turn refined what the prior turn left underspecified. The pattern matters for trajectory preservation: the three modes didn't land in one move, and the REQ/CR loop discipline emerged after the trio was named. Future readers reconstructing the path should see all four turns — and particularly Claude's two corrections (from "Loomworks isn't for that" to "Loomworks authors the system for that" and from binary to trio framing). Both corrections share a discipline already named in earlier investigations: don't commit the methodology to overly narrow framing when the architecture supports more. The engagement architecture supports three modes; calling it "the runtime" misses two; calling it "runtime or authoring-environment" misses one.
The Operator's REQ/CR addition is also a methodology recognition the architecture's existing Forge analogue (REQ-NNN with CR-amendment) already encoded but hadn't been generalized to the deployed-systems case. The recognition is that Forge's pattern wasn't just for managed-specification work inside an organization — it was the operative shape for any case where an authored substrate drives operational reality and operational reality feeds back. Authoring-environment mode is that pattern at the engagement layer.
The v0.21 consolidation should absorb the following from this investigation:
DUNIN7 — Done In Seven LLC — Miami, Florida Loomworks — Engagement Modes Investigation — v0.1 — 2026-05-11