Version. 0.2
Date. 2026-07-04
Status. Concept document. Addition to the legacy-knowledge arc package. Names a product configuration, not new core architecture.
Author. Claude.ai (investigation layer). Operator: Marvin Percival.
Grounding note. Corrected in this version. v0.1 claimed seed grounding ("Phase 41," a Companion-naming section) that does not exist — verified by CC against the live seed. The actual governing authority is standing note v0.6 plus manifest §672. See loomworks-companion-skill-customization-verification-response-v0_1 for the full finding.
Changes from v0.1. Two corrections, both from CC's verification: (1) "skill pack" is not seed or standing-note vocabulary — the settled term is method (a vertical when sold as a domain-aimed offering), a bundle of capability families, conversational voice/register, and skills (bounded engine transforms). (2) The "Memory-room skills versus Shape/Render-room skills" framing was close but non-canonical and implied two unrelated categories. The canonical axis, per standing note §8: a method drives two surfaces of one thing — an interaction surface (applied at install: how the Companion listens, asks, confirms, recalls) and a production surface (named at Shaping: how a render is produced) — unified by the method, not separated into two skill kinds.
A Legacy Systems Companion is not a new product — it's a method laid over the Companion that already exists, aimed at one job: talk to programmers who work in COBOL, RPG, MUMPS, or Assembler, in their own vocabulary, and know what to ask about each language's characteristic blind spots. The method has two surfaces, not two separate skill packs: an interaction surface (how it listens and asks — the code-explanation step, tuned elicitation questions, the right terms) and a production surface (how it produces a render — the specification output once Shaping is reached). One method, two surfaces, under one product, not four separately branded tools. Where it touches modern integration (REST APIs, JSON, MQ, cloud), the rule is firm: Loomworks specifies the bridge, it does not build it. The Companion, once it holds both the code's mechanism and the retiree's rationale, produces a specification for wrapping the legacy system in a modern interface — an AI builder or an integration platform does the actual construction. That keeps Loomworks out of a crowded, well-funded middleware market it has no reason to enter, while still delivering the "bridge old and new" story the buyer wants.
Not a new capability. Companion naming and personality are already settled and shipped — every person can name their Companion, and the architecture already treats the AI behind a Companion as invisible and replaceable, with trust living in the substrate rather than in which Companion happens to be fronting the engagement. A Legacy Systems Companion is a method laid over that same mechanism: a bundle, in the standing note's terms, of capability families, conversational voice/register, and one or more skills — configured for one context, an engagement whose subject is a legacy system.
What changes per language — the method's interaction surface:
What does not change per language: the Memory model, the provenance discipline, the commit lifecycle, the Domain Expert program, the pricing model. One product underneath every language's method.
Each per-language configuration is a method (per standing note §1.3: a bundle, not a primitive), not a "skill pack." It has two surfaces, not two separate kinds of skill:
Both surfaces are legitimately Sense-1 "skills" in the engine sense (a bounded transform), living in different rooms — but they are not unrelated categories. They are the interaction-components and production-components of one method, per standing note §8. If the method is aimed at a domain and sold as its own offering, it is a vertical rather than a general method — the Legacy Systems Companion's per-language configurations are plausibly verticals, given they are domain-specific and intended to be sold.
This is the same operation-not-format extensibility already governing the upload pathway — adding a language is adding a method, not building new architecture. Sequencing follows the market-sizing document: COBOL is the most visible but also the most contested (every Camp 4 vendor targets it); MUMPS and Natural carry less competitive noise and clearer proof points, so they are reasonable candidates for the first method built past COBOL, not COBOL by default.
This is the discipline worth holding firmly. REST APIs, JSON and XML processing, message queuing, cloud integration patterns — none of this should become something Loomworks builds. That market (MuleSoft, Boomi, IBM App Connect, and the broader iPaaS field) is large, funded, and not where a solo founder should compete.
What Loomworks does instead: know enough to specify the bridge. Once the Companion holds both the code's mechanism (from the extraction skill, the interaction surface) and the retiree's rationale (from capture), it can produce a Rendering Mode B output through the method's production surface — a specification, not a running integration. "Wrap this batch job as a REST endpoint; here is the JSON shape; here is what the MQ listener must preserve from the original flat-file record layout; here is the one field that means something different than it looks like." An AI builder — Claude Code or a comparable production system — builds against that specification. Loomworks stays the knowledge layer. It never becomes the integration platform.
This is the reimagining rung (New Systems from Proven Knowledge v0.1) made concrete per language: the specification is only trustworthy because it traces to captured, provenanced knowledge, not because Loomworks has integration-platform features.
The buyer does not think in language names. They think "my expert retires in April." The Legacy Systems Companion concept should never surface as four separately branded tools (a "COBOL Companion," an "RPG Companion," and so on) — that fragments the pitch and multiplies the marketing burden a solo founder cannot carry. One Companion, one product, one pricing model; the per-language method is an internal configuration detail that shows up as competence once code is uploaded, not as a product name on the website.
Standing on built ground: Companion naming and per-person configuration (engine-level companion_name/ActorRef construct — not seed-committed, per CC's verification); the extensible upload pathway operation-not-format shape that makes a method a small addition on its interaction surface; Rendering Mode B as settled architecture for specification output.
Not built: any language-specific extraction skill (COBOL's is the only one scoped, as a queued direction, not yet a Change Request); elicitation-prompt tuning per language; the bridge-specification render-type itself, which would need its own grammar declaration in the Phase 38 registry, following the same pattern already used for application-specification and req-table. Confirmed by CC: no such grammar exists in the current registry's thirteen declared render-types.
Not scoped at all yet: how many per-language methods justify their own build effort versus staying generic; whether the bridge-specification output needs a dedicated grammar or can reuse application-specification as-is; whether the seed should absorb a Companion-customization commitment at all — currently this entire model lives in the standing note, not the seed, and extending seed authority over it is an Operator decision, not assumed here.
DUNIN7 — Done In Seven LLC — Miami, Florida Loomworks — Legacy Systems Companion Concept — v0.2 — 2026-07-04