The word "skill" was carrying three different jobs in the Loomworks canon, and the manifest flagged the ambiguity as unsettled. This note gives each job its own word: skill (a bounded transform in the engine), skill file (an Anthropic-platform instruction package, kept at arm's length), and method (a practitioner's encoded way of working). It then settles how customization vocabulary stacks. The load-bearing point: your personal side — your identity, your personal Memory, your continuity — is bound to you (your UUID), is always present, and follows you across every Companion you use. It is never swapped out. A method is optional specialization laid over your personal side. A vertical is a method aimed at a domain and sold as an offering. When you use someone's vertical, you are still you, with your personal side intact; their method is content running for you, as you. The personal side is invariant; method and vertical are optional content over it.
The manifest (v0.50) carried: "Skills" terminology three-way distinction unsettled. Carried. This note settles it. Three architecturally distinct things wore the one word; each now has its own.
The canon definition (queued-directions §1.2): a bounded structural transformation; no registered actor, no instruction set. A strict input/output contract — known input shape to known output shape, single-shot, no agency.
Phase 53 settled a sharp point: the discipline that survives is bounded contract, not no-LLM. A skill may call an LLM internally; what makes it a skill is the strict contract wrapping it and the absence of any will of its own. The value is the constraint.
Worked cases already in canon, all Sense 1: the Discovery-to-seed skill (Discovery record in, candidate seed out, conforming to R-A5–R-A11), the ExtractionSkill protocol, shaping skills, the materializer registry.
Keeps "skill." It is the canon definition, it is built, it is load-bearing. Qualify as Loomworks skill or bounded skill only where context needs the disambiguation.
The Anthropic-platform SKILL.md artifact: an instruction package plus assets a model loads to do a task well. This project carries several (candidate-seed, foray, forge-spec, ogilvy-writing-audit).
This is an instruction set — exactly the thing a Loomworks skill (1.1) is defined not to be. The collision is direct and worth naming: the candidate-seed skill file (guides a model in a chat to author a seed) and the Discovery-to-seed skill (a contracted engine transform) do overlapping work from opposite sides of the architecture. Same domain, same old word, different kind.
Named "skill file" when it must be named, and otherwise kept out of Loomworks architecture vocabulary — it is an Anthropic-platform tool DUNIN7 uses to do its own work, not a Loomworks primitive.
What the sales-lens session called "purpose-built skills, the core of customization": a customer's method — their way of working a domain — encoded as reusable, delegable capability. The executive coach's intake sequence; the litigator's discovery-review discipline.
The key architectural recognition: a method is not a primitive — it is a bundle. It is composed from lower mechanisms the canon already names:
So "method" names a commercial-and-product bundle, not an engine primitive. The sales instinct ("purpose-built skills are the moat") was right; the word was wrong. The moat is not "we serve your vertical" — it is your method, encoded: the way a specific expert actually does the work, which a competitor cannot copy by serving the same domain.
"Method" chosen over "vertical" for this sense because it names the content (the encoded practice), not the market position; and because it composes grammatically downward — "a method uses these skills" reads correctly, where "a vertical uses these skills" stacks a category on a category. No canon collision: "method" is not in the seed's protected vocabulary.
| Term | Layer | Agency | Instruction set | Lives |
|---|---|---|---|---|
| Skill | Engine substrate | No | No | In the engine, in the pipeline |
| Skill file | Model-guidance | No (guides a model) | Yes | Outside the engine (SKILL.md) |
| Method | Commercial / product | No (a bundle) | (a bundle) | Sold to / built for a customer; composed from primitives |
No two share a word.
A discussion of "how do we create custom Companions" surfaced that customization vocabulary stacks in a specific way. The layering was reached through four corrections (§3); this section states the destination.
Your personal side is a property of you, not of any Companion. It is bound to your identity (your UUID), it is always present, and it follows you across every Companion you use. It is never swapped out, never re-based, never replaced by specialization.
The personal side is three of the four personal facets the architecture already names (foundation note §5; functional spec §8): personal Memory (your content — what is held about you and your world), personal continuity (your identity — the persistent, named presence with your shared history), and personal capabilities (your function — your interface to the system). All three are yours and travel with you. The architecture already binds the Companion identity to the person's UUID (foundation note §1; functional spec §3, the built companion-kind actor bound to the person's UUID); the personal side is the content and continuity that binding carries.
This is the load-bearing correction over v0.1. v0.1 said "a custom Companion is the personal scope populated," which quietly allowed the personal base to be whoever's Companion this is — re-based per user. That is wrong. The personal side is not the base of a Companion; it is a property of a person, and it rides along no matter which Companion they are using.
The fourth facet — specialization (a method, or a vertical) — is content, and unlike the personal side it can be anyone's: yours, or a coach's method you are using, or a domain vertical you bought. Specialization is added and removed; the personal side never is.
A method (§1.3) is optional encoded practice laid over the personal side. It can be aimed two ways:
When you run a method — your own or someone else's — your personal side stays present underneath it. The method changes what the work looks like and how it is done; it does not change whose Companion this is. It is yours, running their content.
A vertical is a method pointed outward: aimed at a domain, packaged as an offering, sold. "Vertical" names the market position (the offering aimed at a domain); the method is the substance inside it that makes it work. You sell a vertical; the method is the moat inside it.
The invariance in §2.1 settles what happens when someone uses your vertical: they are still themselves. When you use a coach's vertical, you bring your own personal side; the coach's method is content running for you, as you. You do not become a guest in the coach's Companion — you bring your Companion, and it puts on the coach's method. Your personal Memory is present; your continuity is intact; the coach's method supplies the specialization. Two things in play, cleanly separated: your identity (yours, invariant) and the method (content, borrowed).
This preserves the architecture as written: foundation note §5.4 and functional spec §8.4 keep "vertical" untouched. The §8.4 phrase "personal vertical" is now read as the specialized corner of the personal side — the facet where a method aimed outward would live — not as the whole of customization, and not as something that displaces the rest of the personal side.
Your personal side — identity, personal Memory, continuity — is bound to you (your UUID), always present, and follows you across every Companion. It is never swapped out. A method is optional encoded practice laid over your personal side; it can be yours or someone else's, and you stay yourself while running it. A vertical is a method aimed at a domain and sold as an offering. The personal side is invariant; method and vertical are optional content over it.
Bound, as everything Companion is, by the founding axiom (functional spec §1.1): the Companion never reaches further than the raw Engine API. Customization shapes how the access layer behaves — voice, vocabulary, which capabilities surface, what is pre-authorized — never what the Engine permits. A custom Companion cannot be a fork; the Engine is the product and governs every caller equally.
The invariance also sharpens the agent case (Axis 2, the agent driver). If the personal side follows the person, then when an agent runs your method, the identities stay cleanly separated: you are the principal (your personal side, your UUID, your Memory — the agent acts for you); the method is the content the agent runs; the agent is the driver, carrying OVA authorization to act as you under your personal identity, not its own. The agent has no personal side — it borrows yours, by authorization. This is exactly what OVA proves: "authorized to act for the person without being the person" (functional spec §9.1). The personal side stays the principal's across every driver and every specialization.
The §2 layering was not reached in one step. It took four corrections, each loosening an assumption the prior one still carried. Preserved so the path is walkable.
Start — Decision B. Vertical is the offering; method is the substance inside it. Settled in discussion as the first clean split of the overloaded "vertical." Assumption it carried: customization is always domain-aimed (every custom Companion has a vertical).
Correction 1 — "I have engagements across many subject areas; this is not really a vertical." The Operator's own desired Companion spans many domains, so it is not domain-aimed and has no vertical. Result: method lifted out of vertical and named the primitive; vertical became method-aimed-at-a-domain; the personal scope became method-aimed-at-you. Assumption still carried: every custom Companion has a method (is specialized in some encoded way).
Correction 2 — "the 'my Companion' example is a generalist." A generalist Companion serves the Operator across everything with no encoded method at all. Result: the requirement that customization means specialization fell away. The personal scope became the base (customization-to-you by default, no method required); method became optional specialization on top; vertical stayed as method-aimed-at-a-domain. Assumption still carried: the personal scope is the base of a Companion — which let the base be re-based per user.
Correction 3 — "have we preserved the personal side across all types? It is associated with our identity, so it should follow us across Companions." The personal side is not the base of a Companion that could vary per user — it is a property of the person, bound to the UUID, always present, following the person across every Companion, driver, and specialization. Result: the personal side is invariant; specialization (method, vertical) is content laid over it, never a replacement. When a person uses someone else's vertical, they keep their own personal side and run the other's method as content. This is the destination in §2.
Why the destination is right and not merely last. The architecture already bound the Companion identity to the person's UUID (foundation note §1; functional spec §3) and already listed the four personal facets with specialization (vertical) as a separate, fourth facet (foundation note §5; functional spec §8). The first three facets — Memory, continuity, capabilities — are the person; the fourth is specialization. Correction 3 recovers that separation, which v0.1 had collapsed by treating "populate the personal scope" and "specialize the Companion" as one operation. The corrections did not invent structure; they recovered the structure the architecture already implied, and freed it first from the domain-aimed assumption ("vertical"), then from the specialization-required assumption ("method"), then from the per-Companion-base assumption (v0.1 §2.1) that obscured identity-invariance.
Settled.
Open (named, not decided here).
§1.3 lists "the delegation contract" among a method's components, which raised a tension: the delegation contract is the sole locus of Companion authority (functional spec §9.3), so if a method contained a contract, installing a method would install authority — a back door around Operator-final-authority. This section settles it.
A delegation contract is identity-and-engagement-bound: it authorizes a specific agent to act for a specific Operator (their UUID) in a specific engagement, and it is recorded as assertions that persist with that engagement (functional spec §9.3). A method is identity-and-engagement-agnostic: it is portable content that travels across engagements and across people (you can use a coach's method; the coach can sell it to many).
These are incompatible. A contract is bound to one UUID and one engagement; a method is bound to neither. A method therefore cannot carry a contract — not as a matter of policy, but structurally. This is the same invariance principle that settles the personal side (§2.1): authority binds to the person and the engagement; content does not. A method is content. Content cannot carry authority.
What a method carries is a contract proposal: a description of what authority the method would need to run — which operations it needs included, which it recommends excluding (requiring explicit approval), a recommended autonomy rule (per_action / pre_authorized), a recommended scope and duration. The proposal is inert. It describes a shape; it grants nothing.
When a method is installed into one of the Operator's engagements:
Installing the method (step 1) and authorizing the agent (step 3) are two separate, deliberate acts, with the held contract (step 2) as the visible checkpoint between them. Propose, never carry — and the proposal becomes authority only through the same held-then-commit ceremony that governs all of Memory.
What the proposal is recorded as, and where it lives, is not settled. The contract is assertions in an engagement; the proposal is portable content that exists before any engagement adopts it — a portable, inert authority-shape the spec does not yet name. Two candidate homes: (a) the proposal is part of the method's own definition (a "recommended contract" block alongside capability families) — simplest, the working lean; (b) the proposal is a separate declared artifact the method references, reusable across methods — more flexible, more machinery, likely premature. This is a spec-level representation decision, left to the eventual Companion-spec revision, not settled here.
A common first instinct is that a method is "like a SKILL.md." This undersells it by an order of magnitude. A skill file is instructions a model loads — it shapes how a model behaves in one session, and it lives outside the engine, inheriting none of the engine's disciplines. A method is content that lives inside the architecture, persistent, with provenance, bound by the Engine's disciplines, laid over the Operator's invariant personal side. A skill file is a prompt; a method is a populated slice of the architecture.
From §1.3, a method is composed from primitives the canon already names — the floor:
Where a method becomes more than the sum of those parts — each possible because the method lives inside the architecture, and each beyond what a skill file can reach:
All five are possible because a method is content living inside the architecture, so it inherits everything the architecture does — provenance, composition, Shaping, proactivity, accumulation, the vocabulary wall, scope-reach. A skill file lives outside the engine and inherits none of it. The boundary a method pushes past is exactly the boundary of "instructions to a model." A method is not instructions about the work; it is the work's accumulated, composable, provenance-bearing shape, laid over the Operator's invariant personal side. A skill file is at most the seed of a method's capability-and-voice layer; the Memory, composition, proactivity, and accumulation are architecture a skill file cannot touch.
A method can learn voice from accumulated assertions (§6.2 #1). That raised the real question: when an engagement speaks — in its Shaped and Rendered output — is that the Operator's voice, or a blend of the Operator and the Contributors? This is a governance question, not an attribution one (Contributors are always acknowledged; every assertion carries its contributor unforgettably — that is not in question here).
The engagement speaks in one voice, and that voice is the Operator's to govern. Two reasons:
The Contributors' voices do not vanish. They live in Memory, in the assertions, as written and attributed. They are simply not the engagement's outward voice by default. The mapping is room-shaped:
The engagement reads from many registers and speaks in one. Contributors' writing stays exactly as written in Memory; the Operator chooses one coherent register for what the engagement emits.
"The Operator's voice" names the default ownership, not a fixed register. Whether the engagement's voice equals the Operator's own register is itself an Operator decision:
The point: the engagement's voice is singular and Operator-governed; a blend is something the Operator commits to, not an automatic averaging of whoever wrote most.
Blend-by-default — averaging Contributors' registers into the engagement's voice automatically — would make the voice drift with who wrote most lately, ungoverned: hire a verbose new Contributor and the engagement starts sounding verbose, with no one deciding it. That is an automatic state transition on something the Operator has authority over, which the architecture names a category error (seed §165: the system surfaces and signals; the Operator approves). The voice must not move on its own.
So the learned-voice machinery serves the Operator, never replaces them: the Companion learns the available registers from accumulated assertions and surfaces them ("your Contributors write in these registers; here is what an engagement voice could draw from"); the Operator governs what the engagement's voice actually is. Learning informs; the Operator decides.
This is the source-is-acknowledged / authority-is-granted shape again: the Contributors' registers are supplied (in Memory, attributed); the engagement's voice is granted (the Operator decides what it is). It is the third instance this session, after the personal side (§2.1 — identity binds to the person; content laid over) and propose-never-carry (§5 — a method proposes; the Operator commits). Three instances of one principle — the source is acknowledged; the authority is granted — strengthen it as a candidate for naming as a first-class methodology principle at v0.21 consolidation.
The engagement speaks in one voice, governed by the Operator. The Contributors' registers live in Memory, attributed, as written — preserved as input, not erased. Whether the engagement's voice is the Operator's own register, an adopted house voice, or a blend that draws in a Contributor's register is the Operator's deliberate choice — never an automatic average of who wrote most. Learning surfaces the available registers; the Operator governs which one the engagement speaks in.
A method can relate to an engagement in two ways, and the distinction is not lifetime (persistent vs. transient) but function — which surface of the engagement the method drives. The engagement has two surfaces, and a method's components sort to one or the other.
A method installed into an engagement drives the interaction surface: the Companion's behavior — the conversational surface, how Q&A is delivered, how the engagement behaves when it is talked to. This is the live, in-the-moment experience of working with the engagement. It is driven by the method's interaction components: capability families (which operations the Companion initiates, in the domain's terms) and conversational voice (how it speaks in dialogue). The installed method shapes the conversation.
This is squarely the Companion's behavioral contract (functional spec §1.2) — gather, confirm, converse, deliver — populated for the domain. A coaching method installed makes the Q&A behave like a coach: it asks the coach's intake questions, surfaces goals the coach's way.
A method named at Shaping drives the production surface: how a specific render is created — its unique style, structure, arrangement. This is the artifact, not the conversation. It is driven by the method's production components: shaping logic (how the domain arranges knowledge for a reader — §6.2 #2) and render specialists (domain-specific production — §6.1). The Shaping methods shape the artifacts.
This is squarely the Shaping room (seed §73–85), which already composes across sources for a particular reader. Naming a method at Shaping is the room reaching for exactly the kind of asset it is built to use: a method's shaping logic is a Shaping-room asset. Methods are named at Shaping the way scopes are — "shape this for this reader, using these methods' structures and styles."
A method is a bundle (§6.1) whose components naturally sort to one surface or the other. So a method is not either installed or referenced — it is an object whose interaction components light up when installed and whose production components are drawn on when referenced at Shaping.
This makes the two surfaces independently choosable. A custom Companion can be installed with one method (so the Q&A experience behaves a certain way) and reference different methods at Shaping per render (so outputs are produced in other styles). Worked case: a Companion installed with a coaching method talks like a coach, and at Shaping references a brand-styling method for the client summary and a compliance method for the disclaimer — three methods, two surfaces, one Companion. The conversation and the artifacts are shaped independently.
Because the interaction surface has one coherent behavior, an engagement normally has few installed methods (often one). Because a render can compose several styles, Shaping normally references many. This echoes the seed's two relationships to scopes (§37): an installed method is like membership (normally one — defines what the engagement is); a method referenced at Shaping is like reference (normally many, peer to one another — drawn on for a need, none defining the engagement). The cardinality is not a separate rule; it follows from which surface the method drives.
A method drives one of two surfaces of the engagement. Installed → the interaction surface (the Companion's behavior, how Q&A is delivered) — driven by the method's interaction components, normally few. Referenced at Shaping → the production surface (how a render is created, its unique style) — driven by the method's production components, normally many. One method can drive both, or different methods can drive each: the installed method shapes the conversation, the Shaping methods shape the artifacts. Cardinality follows function; voice stays Operator-governed across both (§7); referenced-method conflict inherits the deferred scope-composition resolution (seed §85).
The interaction surface (§8.1) is where the installed method gives an engagement its interaction character — how it asks (elicitation), how heavily it confirms, what it proactively recalls mid-conversation (§6.2 #3), and how it pitches answers (register and depth). This is what makes one engagement feel like a coach and another like a litigation associate, even though both are the same Companion over the same Engine.
That interaction character is not a set of free-floating style choices. Interaction style is itself a typed domain — there are established frameworks and taxonomies of personality and interaction (personality typologies, interaction-style models, and the like), each with its own structure, vocabulary, and settled distinctions. A method's interaction character would be grounded in that domain, the way a litigation method's content is grounded in legal doctrine.
In the architecture's terms, this is a referenced domain (seed §37, the reference relationship; queued §8.1, supplied domain Memory). The interaction surface does not invent its character; it references an interaction/personality domain held as Memory with provenance. So §8.1 is sharpened: the installed method's interaction components are its conversational components grounded in referenced knowledge about interaction itself.
This interaction/personality domain is not present in the canon today — not built, not seeded, not referenced anywhere. It is a referenced-domain dependency the interaction surface needs and does not yet have. Naming the dependency is the finding of this section.
The substantive typology work — which interaction styles exist, how they map to elicitation/confirmation/recall/delivery behaviors, how a method selects and composes them — cannot be driven from a single discussion session and is deliberately not attempted here. Doing it from reasoned-from-memory typologies would violate the vocabulary-deference discipline: defer to a domain's settled structure rather than substituting a default reconstruction of it. The right home for that work is a session — or an engagement — where the interaction/personality domain is actually present as sourced Memory, typed, with provenance, governing the substance rather than being narrated.
Open direction (for a domain-present session): bring an interaction/personality domain into the canon as referenced Memory, then do the interaction-surface typology work against it. Until then, §8.1's interaction character is structurally located but substantively ungrounded.
This composes with the standing Companion (queued §10), the Operator-bound mode that runs across all engagements. The picture: the personal side is invariant (§2.1), carried by the standing Companion across every engagement; each engagement's installed method supplies its interaction character, grounded in the referenced personality domain; so a person moving between engagements moves between interaction characters (coach-mode here, litigation-mode there) while their identity stays constant underneath. One identity everywhere; per-engagement character. This is a distinctive product property — most assistants are one personality everywhere; Loomworks would be one identity everywhere with per-engagement character — but it rests on the deferred domain (§9.3) before the character half can be done justice.
A tension noted, not resolved (it waits on the same domain): where an engagement's method-supplied interaction character pulls against the Operator's standing personal preferences (the personal side prefers terse; the installed method asks open and waits), which governs? The working lean, consistent with §7 and §5: the personal side sets the floor, the method shapes within it, and genuine conflicts are surfaced for Operator decision, not auto-resolved (seed §165). This would be the fourth instance of the source-supplies / Operator-governs principle (after §2.1, §5, §7).