Loomworks — Engine/wrapper boundary standing note

Version. 0.1 Date. 2026-06-02 Provenance. Emerged from a seed-investigation session. Operator: Marvin Percival. The principle is the Operator's; the construction history and seams are evidence gathered from the engine and operator-layer code this session. Status. Standing note. A lens for all future work that touches the engine ↔ Companion boundary — seed-review first, but not only. Candidate for absorption into the methodology document, and possibly the candidate seed / architecture spec as a commitment (see §4). Not a design and not a build: this note does not specify the seed-review surface.

What this note is

A principle surfaced while investigating how the seed is reviewed: the engine is a durable, protocol-grade core, and the Companion is one wrapper over it. The boundary between them is load-bearing and must be protected, not erased. This note records the construction history that produced the principle, the seams that history left behind, and the principle itself as the lens future work is measured against.

It is written because the seed-review investigation kept running into the same shape: capabilities that belong to the engine and capabilities that belong to a wrapper were entangled at the wire, and the temptation each time was to fuse the layers to "fix" it. The principle says the opposite — fix the shape of the boundary, never the existence of it.

1. Construction history

The Loomworks engine was built first. The structured seed, the six fields (R-A5–R-A11), the induction loop, the candidate→committed lifecycle, the governing substrate — these were worked out, argued through, and agreed as the logically-solid core. The Companion came afterward, as a wrapper over that engine whose job is to make operator interaction humane: a conversation where there had been a form.

The evidence found this session:

• The Companion explicitly demoted a pre-existing engine surface. The Phase 31 CR (phases/phase-31-conversational-engagement-creation/phase-31-cr-conversational-engagement-creation-v0_1.md, §1) states: "Phase 31 refactors the engagement creation surface from a form into a conversation. The current creation flow (Phase 25) presents the Operator with a six-field seed form that assumes knowledge the Operator does not have. Phase 31 replaces it with a conversational interface — the first surface built under the companion identity." The form pre-dated the conversation. The conversation did not replace the engine; it wrapped the engine's seed and demoted the form to a fallback ("Surface B, the proficient-operator path"). The structured six fields the form edited are exactly the engine's seed fields — the wrapper changed how a human reaches them, not what they are.

• The operator layer flattens the structured seed to prose at the wire. The engine's conversation endpoint (engine: api/routers/seed_conversation.py) co-produces, every turn, both a structured seed_fields object and a prose brief (seed_document), plus a completion percentage and a status. The operator-layer translator (engine: orchestration/translators.py, the Phase 31→Operator mapping) passes seed_document → draft_specification and status → readiness, and drops seed_fields and completion_percentage entirely — they are not even fields on the operator layer's ConverseResponse type. The operator layer today sees only the prose. The structured representation is produced by the engine and discarded at the boundary.

• The narrative-refinement round-trip exists on one side of induction only. During the conversation (call it Sub-phase A), an operator refinement ("make the tone warmer") is appended to the transcript, the whole transcript is re-sent, and the LLM re-emits the full seed_fields and a re-rendered brief together — the two representations stay in sync because one call co-produces both. But in Sub-phase A there is no structured Seed object and no induction yet — the conversation endpoint never calls draft_seed or induct_seed. The structured Seed is first created after the brief is finished, at the brief-commit step (engine: api/routers/seed_commit_from_brief.py, Phase 54), which then runs induction. In that post-brief induction phase (Sub-phase B), refinement today is structured-field editing (the Workshop form's amend-and-re-induct loop with findings anchored to fields) — not a narrative round-trip. The bridge — refine the narrative → the inducted structured seed updates → the narrative re-renders, with findings in view — exists in no repo.

2. The seams this history produced

These are not bugs. They are the natural result of two layers built at different times for different purposes — a core built to be logically solid, and a wrapper built later to be humane. Stated as seams, not faults:

• Seam 1 — the wire flattens two representations into one. The engine offers both structure and prose; the operator-layer boundary carries only prose. The structure exists and is thrown away at the seam.

• Seam 2 — the narrative loop and the induction loop don't meet. The humane round-trip (narrative in, narrative out, structure kept in sync) lives before the engine's structured seed and findings exist. The engine's findings-bearing induction lives after, reachable today only through structured-field editing. The wrapper's humane mode and the engine's rigorous mode are on opposite sides of a gap.

• Seam 3 — the form was demoted, not deleted, and the two paths diverged. The structured form path (engine-shaped) and the conversational path (wrapper-shaped) both reach the same engine seed, but as parallel surfaces rather than one boundary with two presentations. The engine truth is reached two ways that were built at different times.

Each seam is a place where the boundary's shape is imperfect — where the engine isn't yet exposing, through a clean interface, exactly what a wrapper needs. None of them is a reason to fuse the layers.

3. The principle

The engine is the durable core; the Companion is one wrapper; the boundary between them is load-bearing and must be protected.

• The engine is the logically-solid, durable substrate. It does robust work — the seed, induction, the lifecycle, the governing spec. It must be extremely strong, strong enough to outlast any particular way of working with it. Its correctness does not depend on, and must not be entangled with, how any one wrapper chooses to present it.

• The Companion is ONE wrapper over the engine — the current way of making the engine humane, conversation instead of forms. It is an implementation choice, not the only possible one, and not part of the engine's definition.

• The boundary is load-bearing and must be protected, not erased. Making the wrapper too close to the engine — letting wrapper concerns leak inward, or letting the wrapper reach into engine internals — destroys the very flexibility that lets the engine do robust engine work while a wrapper communicates with it. The strength of the engine and the freedom of the wrapper both live in keeping the boundary clean.

• The payoff: the engine must survive any wrapper. A completely different wrapper — built by DUNIN7 later, or by a third party, on current or not-yet-imagined technologies — must be able to sit on the same engine and get the same robust work from it. The engine outlives its wrappers. If replacing the Companion would require changing the engine, the boundary has already failed.

This is the same commitment Loomworks already holds one level down, restated one level up. The Loom protocol must survive changes in technology; protocol-over-implementation means the durable thing is the agreed substrate, not any program that speaks it. Here: the engine is protocol-grade substrate, and the Companion is an implementation choice over it. The Companion is to the engine what an implementation is to the protocol — valuable, current, replaceable.

4. The design consequence for seed-review (framing, not a decision)

Stated as the lens, not as a spec. The seed-review surface is not designed here.

• Capabilities belong on the correct side of the boundary. Structured seed, induction, the six fields, the governing specification — these stay engine-side and clean. Narrative rendering, review presentation, operator-agreement, the humane back-and-forth — these are wrapper work, and they must talk to the engine through the boundary, never by reaching into engine internals.

• **The fix for the narrative-vs-induction seam is boundary shape, not fusion.** The remedy is the engine exposing, through a clean interface, what a wrapper needs to run a humane review against an inducted seed — both representations, the findings, the lifecycle state. It is not welding the narrative loop and the induction loop into one entangled surface. If the answer requires the wrapper to know engine internals, it is the wrong answer.

• Flattening should be a wrapper's CHOICE, not a boundary failure. The current wire carries only prose. That is acceptable if it is the wrapper choosing to show only prose — and unacceptable if it is the boundary failing to offer structure. So the boundary should expose both representations (structured and narrative) and let each wrapper choose which to surface. The Companion may choose prose-only; a future operator-facing or third-party wrapper may choose to show the structured seed, the findings, both. The engine's job is to offer; the wrapper's job is to choose. Today the structure is offered by the endpoint and discarded by the translator — the boundary offers it, one wrapper drops it. That is the shape to preserve and make deliberate, not to "correct" by pushing structure away from the engine.

Any future seed-review work is measured against this: does it keep the engine able to survive a different wrapper? If a proposed change would make the engine assume this Companion, it is moving the boundary the wrong way.

5. Flag — does this belong as a commitment?

Yes, plausibly — flagged, not acted on. "The engine must survive any wrapper" reads like a commitment, not merely an observation: it is a constraint on all future construction, of the same kind as the constraints already in the candidate seed (operator-authority over state transitions; corrections preserved not smoothed; built on Loom Protocol; the protocol must survive changes in technology). It is a sibling of the existing Shaping/Render boundary standing note — another load-bearing internal boundary the system commits to keeping clean.

Recommended handling:

• Now: keep as this standing note. Do not amend candidate-seeds/loomworks/loomworks-candidate-seed-v0_9.md or architecture/loomworks-architecture-specification-v0_4.md in this pass.
• Next consolidation: evaluate promoting a one-line constraint into the candidate seed's Constraints section (alongside constraint 6 operator-authority and the Loom-protocol constraints) — e.g. "The engine is protocol-grade substrate; the Companion is one replaceable wrapper over it. The engine must survive any wrapper." — and a corresponding entry in the architecture spec's core-concepts / boundaries material. The architecture spec already names internal boundaries as first-class; this is one more.
• The decision to promote is the Operator's; this note exists so the principle is on the record and citable before any seed-review work begins.

Standing note. No engine or wrapper code changed. No seed-review surface designed. Filed in loomworks-record/standing-notes/. Sibling to loomworks-standing-note-shaping-render-boundary-v0_1.md. Pairs with the seed-investigation findings and the title-review-at-induction design note (investigations/loomworks-title-review-at-induction-design-v0_1.md).