/layers-domain

Assumes /layers-intro has been loaded. This skill is a library of techniques, not a script — see "How to use these skills" there.

The domain layer maps what exists in the real world independently of any product: the concepts, terminology, processes, relationships, and mental models users bring with them. This is observation, not design.

---

The decisions this layer makes

• What the key concepts in this domain are, and how they relate
• What language people use — and where it conflicts or diverges
• Where the natural seams are: communities that use the same words differently
• What events and processes structure the domain's activity over time

If the domain is already well understood and uncontested, you may not need this layer — go straight to the conceptual model.

---

Disciplines — what keeps domain work honest

• Don't resolve contradictions — record them. Messy, inconsistent domain language is data: it signals where communities have diverged and where the product will later have to choose. Resolution belongs to the conceptual model, not here. Capture synonyms (same thing, different names) and polysemy (same name, different things in different contexts) as findings, not problems.
• Stay in the real world. Push back whenever answers drift toward product or interface decisions. The question is always how the domain works before your product enters it.
• Real objects vs instances (for the noun harvest). A true object is instanceable (you can have many), structured (has its own attributes), and useful (people care about it in its own right). Watch for instances mistaken for objects: "CAC", "ROAS", "LTV" aren't objects, they're instances of one object, Metric. Mark each noun object / attribute / instance-or-value / unclear — and don't filter aggressively; the conceptual model does the sorting.
• Beliefs vs reality. If you're mapping what the team believes rather than researched fact, say so throughout — it's the team's model, not necessarily how users experience the domain.

---

Techniques

Pick what fits — concept mapping plus a terminology audit is the usual core.

---

Working with the designer

Open by asking what domain you're mapping, who operates in it, and what they're trying to accomplish before any product exists. Then surface concepts — listen for nouns (candidate objects), verbs (processes), and the natural vocabulary, including what people actually call things.

Offer the technique that fits the live question: a concept map when relations are unclear, a terminology audit when language is contested, event storming when the domain is process-heavy. Do the next useful thing, not all of them.

Capture only the residue — the concept map if it earned its place, the documented terminology conflicts and bounded contexts, any key events, and the noun harvest. This is raw material, not a finished document.

When the domain is mapped, the noun harvest is the starting point for /layers-conceptual-model.