The owner's frame, 2026-08-18: with agents writing most of the code, the estate can stop stacking onto one codebase and run "a factory approach": parts that each provide a specific value, standard plumbing every part needs, and customer-facing apps that are assembled from a mix of both, each with some one-off, imperfect, customer-specific additions, which is fine and is how every sibling app was built. This doc gives that frame words: eight of them, each with what we mean by it today, the estate read through them, questions that usually help decide which word fits, and the weaknesses we already know about. It is a vocabulary for naming, filing, and planning. It is not a taxonomy: the words overlap, a thing may take two of them, and at least one kind of thing has no word yet. Third pass, 2026-08-18; earlier passes and a skeptical review are logged at the end so the reasoning is auditable. Tagged as working names by the owner on 2026-08-18 after the third naming test; expected to change if a fourth naming strains it.

Audience: anyone naming a thing, filing a doc, planning a build, or deciding where a piece of work belongs.

Why words, and two commitments#

The factory works only if its parts are standard: an agent building the ninth module must not rediscover what a module is, and an agent assembling an app must not read a module's source. Agreeing on a word for a thing is the cheapest way to agree on its contract, owner, version cadence, docs, and callers, which is all this vocabulary is for. Two commitments sit under the frame:

• The seams are the product. Modules and apps are replaceable; the contracts between them and the runner they share are what compound.
• Bespoke work is allowed and labelled. Every sibling shipped customer-specific glue. It is a label on code under any word, with rules that keep it bounded (below), not a word in the table.

The words#

One row per word. What we mean is how the word is used in this tree today, written tightly so it can be argued with; it is not a rule of membership. Maturity says how much weight the word can bear: settled (used the same way everywhere, no known strain), working (used consistently here, known to overlap with a neighbour), provisional (kept for now, might fold into another word). Examples are what exists in the estate. Also called are the alternatives considered.

Eight words. Payload, runner, module, fitting, and app are said of things that run; contract, reference data, and canon of things they are built with. The count is not a claim that the space is covered.

Three notes the words need beside them:

• Reference data is the only kind of data with a word of its own. The other content buckets in guides/02 (identity data, system config, tenant config, the job snapshot, the record) are owned by an app, a runner, or a module and have no word of their own.
• A declared output transform (canon/15) has no word either; it is an artifact of the manifest, owned by the module for module-native outputs and by the app for exports.
• A pure data transform with no vendor, no model, and no state is a function inside whatever calls it, not a payload and not a module (guides/00).

A label that crosses all of them: bespoke#

Bespoke (working name; also trim, custom, one-off) is a label, not a word in the table above. The table answers "what kind of part is this"; bespoke answers "how far may it travel". Bespoke code sits under a word (an app, a payload variant) and carries the label because it exists to meet one customer's exact need, names that customer, and would not belong in a second app. It is allowed, because that is how every sibling shipped, and the label comes with governance because otherwise it spreads:

• it lives in a named place (bespoke/<customer>/ in an app; a bespoke: tag on a payload variant), never scattered across FE and BE
• it appears in the owning instance doc's Lapses or a Bespoke section
• it carries an expiry or a review date; at review it is promoted (to a payload variant, a module, a fitting, or tenant configuration), declared permanent with a reason, or deleted

The estate's examples: JEGS and Zeder upload and enhancement templates hardcoded across App V5's frontend and backend (owner, evidence/20260817-owner-answers.md §12); walmart's global rate floor standing in for per-seller tiers (walmart_items_rpm, guides/02, evidence/20260818-data-model-split/walmart-mvp.md §7); customer xlsx skeletons committed to App V5's backend repo (evidence/20260818-data-model-split/enhancement-product.md §4).

Three delivery forms, not words in the table#

• Scaffolds and templates are how a kind of thing is delivered as code to start from: the runner template, a module scaffold, an app starter. A scaffold is a runner or a fitting or an app in template form.
• Shared services are fittings deployed once and called (the issuer, a shared vendor cache); most fittings are libraries. Same word, two forms.
• Tools are code that produces or checks an artifact of another kind and runs nowhere at request time: the snapshot tool that publishes reference data, scripts/build-do-nots.py that generates canon, a conformance runner, and a proof surface such as versable-builder's playground (canon tooling that also hosts primitives; vb-fable's warning is that a proof surface out-costs the product if it becomes one). A tool is filed under the word whose artifact it produces.

Questions that usually help decide#

Ask roughly in this order. They are not a test with a single answer; when two questions both say yes, the thing is both, and the doc filing goes with whichever the reader would look under first.

1. Does it have users and tenants, and does a customer open it? App.
2. Does it take an item and return an outcome? Payload. (If it would break when the queue or store changed, it is still a payload; it is a leaking one, fix it per canon/01.)
3. Does it accept jobs, run payloads, and serve /jobs? Runner if it is the shared engine; Module if it is a deployment of it with its own manifest, version, and identity audience.
4. Is it authored here, would every runner and app need it, and does swapping it for an equivalent leave what the customer can do unchanged? Fitting. Bought infrastructure (Redis, Cloud Tasks, GCS, Langfuse) is not classified; the adapter over it is the fitting.
5. Is it data with a publisher and a version, loaded rather than queried? Reference data.
6. Does it exist so two things built by different people agree? Contract.
7. Does it tell someone how to build one of the above? Canon.

And the label: does it name a customer? Bespoke, on whichever word it sits under.

Confusions the tests catch:

• A "module" that reads the customer's org table is an app fragment.
• A "fitting" that changes what a customer sees (a review queue, an export shape) is app.
• A feature two apps need is a module or a fitting waiting to be extracted; the tell is the second copy.
• Reference data queried live from another system's database is reference data placed wrongly (canon/05).
• A payload that imports a queue client, a store client, or a tracing client is a runner leak (canon/01).
• Bespoke that survives two reviews is promoted or declared permanent.

The estate read through these words#

One line per real thing, to see whether the words are enough to name it. A cell may carry two words.

Two things the reading exposed. The sibling apps each contain a runner and payloads and fittings inside one repo, which is exactly the App V5 assumption the factory replaces (guides/00), and the words give that extraction a vocabulary: lift the runner out as the shared one, lift payloads into modules, lift fittings into recipes, and the app keeps what is left. And several things needed two words or a note, which is the honest signal that this is a vocabulary and not a partition.

Known weaknesses#

Written here so the tidiness above is not read as finality. Each is real; none is fixed yet; the trigger for fixing them is at the end.

1. Three kinds of distinction in one list. Payload, runner, module are nested (a module is a payload mounted on the runner, deployed); fitting is cross-cutting; app is a deployment; contract, reference data, canon are artifacts. A cleaner shape is two axes, artifact kind (running code, deployment, data, spec, knowledge) by role (produces value, carries value, composes, assembles), with these words as cells. A flat list was kept because folders and plans are named by single words.
2. The runner passes the fitting test. Authored here, every module needs it, swapping it for an equivalent changes nothing a customer can do. It has its own word because two contracts bind it and the owner named workers as primary; that is an emphasis, not a difference in kind.
3. Module is a level, not a kind. "Deployment of runner plus payload with a manifest" puts module at a different level from payload and fitting, which is why the manifest became the discriminator and why today's deployments had to be called modules-in-waiting.
4. Connectors strain the job shape. The contract is N items in, N outcomes out; a marketplace's reconcile and unpublish sweep are long-lived sync loops over state the app does not own. Calling a connector "a kind of module" may bend the job envelope to fit. This is likely the first place the runner needs a second primary shape (a sync loop with a cursor and a reconcile).
5. App-side engines have no word. The orchestrator loop, the review queue engine, and the catalog as system of record are filed under app, and the "a feature two apps need is waiting to be extracted" test will fire on all three once Winhere, walmart, and the console share them. They are neither modules (not item to outcome) nor fittings (not every app needs an orchestrator). A word is missing here.
6. Bespoke is a wish without a mechanism. A label with a folder, a review date, and a promotion path binds only if something enforces it; nothing does yet, and the label will be skipped exactly when it matters.
7. The wire field was renamed to protect a word. payload became input on the wire so the word means one thing. Cheap now; still the vocabulary bending the contract rather than the reverse.
8. Reference data is borderline. It is the only data word beside two document words; it earns its place because every sibling placed it differently, and it folds into a fitting concern plus an artifact type without loss if fewer words are wanted.

When to restructure: use these words to name the next three real things (the runner template, the content module upgrade, the console plan). If the third one does not fit without a note, move to the two-axis shape and add the app-engine word then. Do not polish the list before that.

Names#

The owner asked for a name for the plumbing word and for the choice to be tagged. Working names; expiry is the same trigger as above. Candidates and reasoning:

Recommendation: Fittings. Full vocabulary: payloads, runner, modules (and connectors), fittings, apps, contracts, reference data, canon, plus the bespoke label. All plain words. Collisions inside the estate, and which reading wins where:

Tagged 2026-08-18 by the owner: working names, "just tagging", no restructure. The eight words above and the bespoke label stand as the working vocabulary, with the restructure trigger unchanged (naming test three, the console plan, passed with the one friction noted in plans/v6-decision-set.md D10). Two more working names joined at the same ruling, at the estate level rather than the class level:

versable-builder currently describes itself as "a monorepo forge" (its ADR-001 context); under this tag it is the foundry, and that relabel is the versable-builder lane's to carry. Still to tag in adr/006 and the versable-builder glossary when those files are next touched.

What the words change in this tree#

• canon/01 is the payload/runner seam; the other canon docs each bind one or two words (02 fittings and apps, 03 and 04 runner, 05 to 09 fittings, 10 module and app, 11 module, 12 and 13 fittings, 14 module, 15 module and app); contracts/ is the seams; patterns/ is how to build each kind; guides/ are the decisions that cut across kinds; instances/ breaks down every shipped app and module; v6/ is the canon for the first app.
• Repo and folder names carry the word: modules/content, runner/py, fittings/identity, apps/console; reference data is a published artifact in object storage, so its folder, if any, holds the publisher tool, not the snapshot.
• A plan for a new thing starts by saying which word it takes, and says so if it takes two or none; a "none" is a finding for this doc.
• Every app gets a bespoke/<customer>/ folder and a Bespoke section in its instance doc.

Third pass: the skeptical review, 2026-08-18#

A fresh reviewer read the second draft against the whole tree (evidence/20260818-class-model-review.md, 29 findings). All were folded above except where noted; the dispositions are in that file. The ones that changed the model: the fitting clause now discriminates on what a customer can do, not what they see, and requires "authored here" so bought infrastructure exits the test; the ordered test's second question now returns a word; tools became a third delivery form; the manifest is stated as prescriptive and today's deployments as modules-in-waiting; the module is one capability by default with co-hosting as the canon/14 exception, reconciled with the charter; the wire field payload was renamed input so the word means one thing; the "no collisions" claim was replaced by a collision table.

Changes from the first draft, and why#