Layers Conceptual Model

# /layers-conceptual-model

*Assumes `/layers-intro` has been loaded for framework context.*

The conceptual model is the most neglected load-bearing layer. It defines the objects the product recognises, their relationships, what states they can be in, and the vocabulary used for everything. It lives in the solution space: it is not a capture of users' existing mental models (which are contradictory and messy — that's the domain layer's job), but a deliberate design decision about how the product will model its domain.

**What it is — and isn't:**
- A **design decision** that resolves the messy domain into a coherent, opinionated structure
- **Not a database schema** — engineers make their own data decisions, but the gap between this model and what they build matters. A large, unexamined gap is both UX debt (users encounter a product that contradicts the model) and technical debt (the system is harder to evolve).
- **Not a wireframe or flow** — no screens, no navigation. Those belong to the layers above.
- **Not neutral** — every naming decision, every relationship boundary, every included or excluded object reflects a point of view.

**Decisions this layer needs to make:**
- What objects will this product recognise, and what are their boundaries?
- How do those objects relate to each other?
- What can users do with each object?
- What states can each object be in, and what transitions matter?
- What is the product's vocabulary — one name per concept, chosen and committed to?

**Methods:**

| Method | When |
|---|---|
| **Noun foraging + OOUX** (Sophia Prater) | Default when you have research or domain notes to mine. Extracts objects from naturalistic language. |
| **Semantic IxD / action grammar** (Daniel Rosenberg) | When you have many actions across many objects and want to audit verb consistency and precision. |
| **Event storming — commands/policies phase** (Brandolini) | Domain has complex processes. Start from what happens, work backwards to objects involved. |
| **Card sorting** | Vocabulary is unclear or contested across users or teams. |
| **DDD bounded context mapping** | Multiple user types use the same words differently — surfaces where the model has natural seams. |
| **Walking the existing product** | Redesigning. The current UI reveals the implicit model — compare it to how users actually think. |

Default: **noun foraging and object definition**.

**Quality signals — what good looks like:**
- Every object is independently meaningful to the user — not a UI element, not a vague abstraction
- Relationship roles are explicitly named when an object can play multiple roles
- Attributes that are really relationships have been challenged and converted
- No speculative additions — every object, attribute, and relationship traces to a user need
- State transitions are defined for objects whose status materially changes what users can do
- Temporal decisions are addressed: deletion semantics, relationship temporality, history
- Ubiquitous language is established: one name per concept, one concept per name

---

## Guided session

*Tell me what product or feature you're defining a model for, or say "guide me" to start noun foraging and object definition.*

Ask: *"Where should I capture the work from this session?"* (see `/layers-intro` for options)

Check what the designer has from the problem space — domain notes, research, user needs. If nothing: proceed but flag that a model built without domain knowledge often reflects assumptions more than users' reality.

If redesigning: *"Describe the current model, even informally — what implicit model does the existing product have?"*

---

**Phase 1 — Frame the scope**

1. What product or feature are we defining a conceptual model for?
2. What's the core job users are trying to do with it?
3. What ma