Loomworks methodology — two scoping-and-grounding disciplines — standing note — v0.1

Document: loomworks-methodology-scoping-grounding-disciplines-v0_1 Version: v0.1 Status: standing note — candidate for the methodology canon (operations/loomworks-methodology-canon-v0_1) at the next consolidation. Two disciplines validated through the create-stage arc of 2026-06-28, each recorded with the concrete evidence that earned it. Date: 2026-06-28 Origin: The engagement create-stage scoping arc. Two failure-and-correction patterns recurred sharply enough across one session to be worth naming as standing disciplines, not one-off lessons. Both are about the gap between what a scoping document assumes and what the codebase actually is — one at design time (importing machinery a problem doesn't need), one at verification time (asserting a code path runs from reading it).

Plain-language summary

Two disciplines, both learned the expensive way in one session:

1. Ground for the true size before scoping. When you scope a new capability, first ask whether the product already has most of it — and watch for importing machinery a problem doesn't actually need. Twice this session a piece scoped as "the heaviest net-new capability" turned out to be "feed the existing machine differently" — because the real spine already existed and the heaviness was imported assumptions.

1. Exists is not works. A code path being present is not the same as it running. Verify against the real runtime — especially anything touching an LLM or an external API — before asserting a premise. Once this session a feature was scoped on "the machinery is built" (true from reading the code) when in fact it failed the moment it ran (it required input the cold-open couldn't give).

Both are cheap to apply (one grounding pass) and expensive to skip (a whole CR built on a wrong premise).

Discipline 1 — Ground for the true size; watch for imported machinery

The principle. Before scoping a capability as net-new, ground whether the product already implements most of it, and interrogate every piece you're about to build for whether it's solving the actual problem or a problem you imported by an assumption. The true size of a piece is usually smaller than the first framing, because the first framing tends to drag in machinery from how some adjacent thing was solved.

The tell. Phrases like "the heaviest, newest capability," "a bespoke subsystem," "a new pipeline," "extend the existing X to also do Y" — especially when X was built for a genuinely different purpose. When you catch yourself threading a new intent through the eyes of an old needle (contorting an existing endpoint, field, or mechanism to accept something it wasn't shaped for), that contortion is the smell. The required-field you're about to relax, the boundary you're about to bridge, the token you're about to extend — ask whether the problem they solve is yours or imported.

The evidence (three instances, one session):

• Door 2's bridge — imported two boundary crossings and a token. Door 2 ("I'll tell you" — structured foundation questions) was first scoped as routing the deployed marketing Example Generator into the product. That assumption imported: an anonymous→authenticated boundary, a claim-token to cross it (extending the credit-claim mechanism), a marketing→product crossing, the generator's Cloudflare/Haiku infrastructure, and nearly a pinned model. Every piece dissolved when the assumption was dropped — leave the generator where it is; copy its intent, not its deployment. Door 2 became: ask the questions in the product, for an already-signed-in Operator, using the product's own AI-logic methodology, with the task-appropriate model. No boundary, no token, no credits, no marketing change. The withdrawn cr-generator-create-bridge-v0_1 is the artifact of the imported version; loomworks-create-stage-door-2-scoping-note-v0_1 records the strip-down.

• Door 3's subsystem — imported a "document-to-seed" capability that already existed. Door 3 ("here's my specification" — a document) was first scoped as "the heaviest net-new capability." Grounding found the product already extracts a seed from an uploaded document (extract_seed_fields_from_text over the upload pathway's transformed text, reaching the same commit spine). Door 3's true size: feed the Operator's document to the existing extraction + a review surface assembled from existing display patterns + one small editable-field component. Not a subsystem.

• The spine itself — discovered, not designed. The deepest instance: all three doors turned out to be three text inputs to one compose→commit spine (extract_seed_fields_from_text → draft → induct → commit) that is the create conversation's own commit terminal. The "create-stage spine" I had started to design from scratch several turns earlier already existed in the product. It was discovered by grounding me_create_engagement.py, after nearly building three new copies of it (one per door).

The corrective practice. Before scoping a capability:

1. Ask "does the product already do most of this?" and ground it — read the real route/skill/component, don't assume from the feature name.
2. For each piece you're about to build, ask "is this solving my problem, or a problem I imported by an assumption about reuse / origin / boundary?"
3. Separate intent (what the thing should do — copy this), deployment (where an existing instance runs — often leave alone), implementation (the existing code — learn from it, reuse only where it fits the intent, never contort to fit), and incidental choices (model, infrastructure — inherit the product's, don't import the source's).
4. We learn from work that has been done; that it does not match exactly what we want now does not mean it was not good. The existing implementation is a resource and a teacher, not a constraint to thread through.

The payoff. The create stage went from "three heavy net-new capabilities" to "feed one existing spine three ways, plus a review surface for the one door that brings finished work." The imported machinery — boundaries, tokens, credits, subsystems, pinned models — was, in aggregate, most of the originally-scoped work, and none of it was real.

Discipline 2 — Exists is not works

The principle. A code path being present in the source is not evidence that it runs — especially at LLM/API edges, where the real behavior is determined by an external service's constraints that the local code does not encode. Ground the premise against the real runtime before building on it. Reading the code tells you the path exists; only running it tells you the path works.

The tell. A scoping premise of the form "the machinery is built; we just need to wire/fire/call it" — asserted from reading handlers, templates, and signatures. The phrase "X is built to do Y" deserves the question "built to do Y from what input, and does it run on the input we'll actually give it?"

The evidence (one instance, this session):

• The create cold-open — "speak-first is built" was half-true. Door 1's grounding asserted the engine's create_engagement_entry is built to greet first (true: the template reads "the Operator has just signaled they want to start a new project," the handler accepts an empty message, the endpoint accepts the intent hint). The frontend was built to fire an empty opening converse. The mocked tests passed. The live check 400'd: generate_response unconditionally appends {"role":"user","content": operator_message}, and the Anthropic Messages API rejects empty content — a system-only call is impossible. The greeting machinery greets in response to a non-empty opener; it cannot cold-open from silence. The premise "speak-first is built" was true for what the code contains and false for what runs from an empty opener. The mocked tests passed precisely because they did not exercise the real responder. A secondary harm surfaced only at runtime too: the empty operator turn got recorded, poisoning every subsequent converse with the same 400 until the polluted turns were cleaned.

The corrective practice.

1. When a scoping premise is "the path exists / the machinery is built," grade it: exists in source vs. runs on the real input we'll give it. Only the second licenses building on it.
2. For anything touching an LLM or external API, the live check is not optional polish — it is the acceptance gate. Mocked-green is necessary, never sufficient. (The cold-open CR's acceptance is a live entry→active→commit sequence, not the suite, for exactly this reason.)
3. When grounding, ask the grounder to distinguish exists from works explicitly, and to flag what could not be resolved read-only rather than assert it. (The cold-open grounding did this — it confirmed the non-empty greeting runs live, confirmed the empty one 400s live, and flagged the one multi-turn property it could not resolve read-only for live verification. That is the shape of honest grounding.)

The payoff. Caught on the dev engine (8 polluted turns to clean) instead of in production (every Operator greeted with "I'm having trouble thinking right now," and every create conversation's commit poisoned). The frontend work was not wasted — it is correct and held, shipping alongside the engine cold-open fix the live check revealed was needed.

How the two disciplines relate

They are the same discipline at two moments. Discipline 1 guards design time: don't scope machinery the problem doesn't need (and the product may already have). Discipline 2 guards verification time: don't assert the machinery works from reading it. Both are corrections to the same root error — treating a document's account of the codebase as the codebase. The scoping note's "this is net-new and heavy" and the grounding's "speak-first is built" were both documents about the code that the real code (Discipline 1) and the real runtime (Discipline 2) corrected. The standing practice that subsumes both: ground against the real thing — the real code for what exists, the real runtime for what works — before committing structure to a change request. This extends the project's existing "ground before drafting" lesson with two sharper edges: true-size grounding and runtime grounding.

Seed / canon alignment

These extend, not replace, the existing methodology lessons:

• "Ground the design in the real code before drafting steps" (the Stele Phase-3/4 lesson) — Discipline 1 sharpens it to true-size grounding (the real code may already do most of it); Discipline 2 sharpens it to runtime grounding (the real code running, not just present).
• "Correctness guarantees live in code, not prompts" — adjacent; Discipline 2 is its verification-side twin (correctness claims live in runs, not reads).
• "Handoffs must not encode imagined state as fact" — Discipline 1's "imported machinery" and Discipline 2's "exists-not-works" are two species of encoding-imagined-state.

For the canon consolidation

Recommend both enter the methodology canon at the next consolidation, phrased as standing disciplines:

• Ground for the true size; separate intent from deployment, implementation, and incidental choices; reuse what fits the intent, import nothing.
• Exists is not works; the live check is the acceptance gate at LLM/API edges; grounding must distinguish exists from works and flag what it cannot resolve read-only.

DUNIN7 — Done In Seven LLC — Miami, Florida Loomworks methodology — two scoping-and-grounding disciplines — standing note — v0.1 — 2026-06-28 Two disciplines from the create-stage arc, each with its evidence. (1) Ground for the true size; watch for imported machinery — three instances where "heaviest net-new capability" became "feed the existing spine differently" once imported boundaries/tokens/subsystems were stripped, culminating in discovering the create-stage spine already existed. (2) Exists is not works — the create cold-open's "speak-first is built" was true in source and false at runtime (empty opener 400s; mocked tests passed by not exercising the real responder). Both correct the same root error: treating a document's account of the codebase as the codebase. Candidate for the methodology canon.