Version. 0.2 Date. 2026-06-11 Status. Standing note. Settles the three-way "skill" distinction the manifest carried as open, and names the layering of customization vocabulary (the personal side, method, vertical) that a discussion of custom Companions surfaced. Operator-facing. HTML primary to follow; this Markdown source alongside. Change from v0.1. One correctness fix to the central claim. v0.1 §2.1 said "a custom Companion is the personal scope populated," which let the personal base be re-based per user and collapsed being-yours with being-specialized. v0.2 corrects this: the personal side is a property of the person, bound to identity (the UUID), always present, following the person across every Companion, driver, and specialization. Specialization (a method, a vertical) is content laid over the personal side, never a replacement for it. This re-reads the architecture's own UUID-binding (foundation note §1; functional spec §3) and four-facet separation (foundation note §5; functional spec §8) faithfully, where v0.1 under-read them. A fourth correction is added to the trajectory (§3) recording the fix. All other content preserved from v0.1. Author posture. Discovery posture: the corrections that produced the final layering are preserved alongside the conclusion, so a later reader can reconstruct how it was reached, not only where it landed. Source grounding. Grounded against candidate seed v0.12, Companion architecture foundation note v0.2, Companion functional spec v0.2, current-status manifest v0.50 (the open residue), and queued-directions v0.26 (§1.2 the Loomworks-skill definition, §8.1 supplied-Memory reframe). Settled in discussion 2026-06-11; nothing here is built.
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).
DUNIN7 — Done In Seven LLC — Miami, Florida Loomworks standing note — skill, method, and the customization vocabulary — v0.2 — 2026-06-11