/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?