DUNIN7 · LOOMWORKS · RECORD
record.dunin7.com
Status Current
Path standing-notes/loomworks-standing-note-vocabulary-language-vertical-profiles-v0_2.md

Loomworks Standing Note — Vocabulary resolution, language, and vertical profiles — v0.2

Document: loomworks-standing-note-vocabulary-language-vertical-profiles-v0_2 Version: v0.2 Date: 2026-06-29 Provenance: Claude.ai scoping session. Operator: Marvin Percival. Arose from the engagement-vs-project surface-vocabulary question during the create-stage build; developed into a resolver/architecture direction. Status: Standing direction note. Records a settled architectural framing + a named opportunity. Not a spec, not a build order. Most of what it describes is deferred (Phase A/B+, pre-partner). Canonical home: loomworks-record.

v0.2 correction (2026-06-29, recorded not smoothed): v0.1 §5 said the create-flow noun should be shaped as display(term, locale, profile) "from the start" — assuming a single vocab source either existed or was a one-line cost. Grounding (the create-stage-polish CR Step 0) found neither holds: there is no single vocab source today, strings.ts is itself inconsistent (mixes project and engagement strings), and "engagement" is hardcoded inline in the nav — so introducing a single source is net-new with blast radius into the library/nav filters and the focus-chip. Corrected position: the create-flow fix is an in-place "project"→"engagement" swap of the 8 create-stage strings now; the single source + display(term, locale, profile) resolver + strings.ts consolidation is the Phase-A effort (where the resolver is shaped), not a side effect of a copy fix. §5 below carries the v0.1 text with this correction noted inline. The architecture (§2–§4) is unchanged — only the when* of introducing the resolver moved (from "now, one line" to "Phase A, deliberately").


Plain-language summary

Loomworks is meant to be white-label and multi-language (per the May 2026 analysis). This note settles how the object-noun and other vocabulary terms should be resolved to display text, so the two capabilities — speaking a different language, and using a different industry's words — share one mechanism without being confused for each other. The key decision: one resolver, two independent inputs. Display text is a function of both which language (locale) and which vocabulary flavor (profile). Keeping these two as separate, orthogonal dials — rather than collapsing vocabulary into language — is what makes "Loomworks for Law, in German" a cheap table-cell instead of a bespoke build. That orthogonality also unlocks vertical packaging: a coherent set of noun-mappings per industry (law → "matter", agency → "campaign", clinic → "case"), shippable across every language for free. None of this is built now. The one thing it changes today: when the create-flow noun is routed through a single source, shape that source as display(term, locale, profile) from the start, with the defaults hardcoded — a one-line cost that keeps the whole direction open.


1. The decision DUNIN7's word is "engagement"

For the DUNIN7-branded instance, the object noun is engagement — the methodology noun (seed, spec, codebase all use it), the right word for the professional-services Operator (the Aldous-shaped buyer says "engagement" natively), and a word the product can own (where "project" is generic to the point of invisibility, colliding with every other work tool). The create-flow surfaces that leaked "project" ("Set up the project", "Your project is committed and active") are a bug — they bypassed the vocabulary layer and hardcoded "project" directly. Fix: the surface says "engagement" consistently, sourced from one place.

This is an instance default, not a global truth. White-label partners can set a different object noun in their instance config (the May analysis already lists vocabulary.project as a configurable term). The word travels with the brand/instance, not the individual Operator.

2. The architecture one resolver, two orthogonal inputs

Language and vocabulary-preference are mechanically the same operation — map a canonical value to a display string for an audience — so they share one resolver. But they are different concepts at different scopes, and collapsing them is a trap.

The resolver:


display(canonical_term, locale, profile) -> display_string

display("engagement", locale="en", profile="default") -> "engagement"
display("engagement", locale="en", profile="legal")    -> "matter"
display("engagement", locale="de", profile="default")  -> "Engagement"
display("engagement", locale="de", profile="legal")    -> "Mandat"

Why orthogonal, not collapsed (the load-bearing rationale). If "language" means "preference" — i.e. vocabulary variants are presented as languages — then a German law firm (German + legal nouns) needs a bespoke "german-legal language", a French agency needs "french-agency", and translation sets multiply as language × vocabulary (a product). Kept orthogonal, you maintain N languages + M profiles (a sum), composing at lookup time. The German-legal cell exists as de × legal with no bespoke set. Orthogonality is what makes verticals-across-languages additive instead of combinatorial.

Two readings of "use language to mean preference" — one sound, one rejected:

Open plumbing item (named, not solved). Language already reaches the Companion persona ({language} directive). A vocabulary profile that should also govern the Companion's speech (the instance says "matter" → the Companion says "matter") needs to reach the persona/prompt, not just the frontend display map. The vocabulary-to-Companion path is not fully spec'd in the May analysis. Real design item for when profiles become real; do not hand-wave as "just language."

3. The opportunity vocabulary-profile-as-vertical

The profile axis is not cosmetic relabeling — it is vertical packaging. A profile is a coherent set of noun-mappings that makes the whole surface speak an industry's native language:

| Vertical | engagement → | contributor → | render → | (illustrative) | |---|---|---|---|---| | Coaching (Aldous) | engagement (native) | client | session summary / deliverable | | Law | matter | counsel / associate | work product | | Agency | campaign | stakeholder | creative / asset | | Clinic / case mgmt | case | care team | care plan |

Same engine, same methodology, same four rooms underneath — each vertical sees a surface that looks built for them. This is the white-label promise made concrete: a partner gets not just logo + colors (the brand layer) but their industry's vocabulary (the profile layer). "Loomworks for Law", "Loomworks for Coaching" — each a vertical profile, not a separate build. A real differentiator and a pricing lever.

Because locale and profile are orthogonal, a vertical profile is language-independent — author the legal noun-overrides once, they ride on every language file. "Loomworks for Law in German" = de × legal, no bespoke build. The verticals multiply across languages for free. This is the payoff of the §2 orthogonality decision.

4. The distinction vocabulary profile vs. domain profile

A vertical has two layers, related but separable:

You can ship the vocabulary profile well before the domain profile. The vocabulary profile is the fast visible win; the domain profile is the real defensibility. Knowing they're separable means the vertical story can be delivered incrementally — surface first, substance later — rather than waiting for the whole thing.

5. Build boundary what changes now vs. what's deferred

Now (the only build implication) — CORRECTED in v0.2: the create-flow object-noun fix is an in-place "project"→"engagement" swap of the 8 create-stage strings (DocumentCreateFlow, create-engagement page, ChatView; FoundationQuestionsForm already clean). It does NOT introduce a single source or the resolver. (v0.1 said "shape the source as display(term, locale, profile) from the start" — but grounding found no single source exists, strings.ts is itself inconsistent, and building one has blast radius into the library/nav filters and the focus-chip. So the resolver is introduced at the Phase-A consolidation, not as a side effect of this copy fix. Recorded in cr-create-stage-polish-v0_1.) The in-place swap fixes the inconsistency the Operator sees now; §2/§3/§4 stay open for Phase A.

Deferred (Phase A/B+, pre-partner — do NOT build now):

Discipline reaffirmed: the idea is compelling; that is exactly when the strip-it-down / build-only-what's-needed discipline matters. Build the one-line resolver shape now; defer everything else until a real partner/vertical/language pulls it.

6. Reconciliation flag against the May analysis + seed

The May white-label analysis (loomworks-white-label-multilanguage-analysis-v0_1) keys the configurable term as vocabulary.project: "project" — i.e. it used "project" as the default, which conflicts with the methodology's "engagement". Worth reconciling: the default vocabulary value should be "engagement", and the config key should be "engagement" (or a neutral key like object_noun), so the config system doesn't bake "project" in as the canonical name for what the seed calls an engagement. Minor, but it should be fixed when the instance-config vocabulary work (Phase A) is actually drafted.


Companion documents


DUNIN7 — Done In Seven LLC — Miami, Florida Loomworks Standing Note — Vocabulary resolution, language, and vertical profiles — v0.2 — 2026-06-29 One resolver, two orthogonal inputs: display(term, locale, profile). Language (exhaustive, reaches the LLM) and vocabulary profile (selective, per-brand) share the lookup mechanism but stay separate concepts — orthogonality makes verticals-across-languages additive (N+M) not combinatorial (N×M). The profile axis is vertical packaging (law→matter, agency→campaign): the white-label promise made concrete, language-independent, shippable per-vertical. Vocabulary profile (surface, cheap) is separable from domain profile (shape-types, substance, the moat). DUNIN7's noun is "engagement". Build-now: shape the create-flow single source as display(term, locale, profile) with defaults hardcoded — one-line cost. Everything else deferred to Phase A/B+ pre-partner. Reconcile the May analysis's "project" default → "engagement".