layers-conceptual-model

/layers-conceptual-model

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

The conceptual model is the most neglected load-bearing layer. It defines the objects the product recognises, how they relate, what states they can be in, and the vocabulary for all of it — a deliberate decision about how the product models its domain, independent of any interface.

It is not the users' messy mental model (that's the domain layer), and not a database schema, wireframe, or flow. But the gap between this model and what engineers build matters: a large, unexamined gap is both UX debt (users meet a product that contradicts the model) and technical debt (the system is hard to evolve).

---

The decisions this layer makes

• What objects the product recognises, and where each object's boundary is
• How those objects relate — cardinality, and named roles where an object plays several
• What a user can do to or with each object
• What states an object can be in, and which transitions matter
• The product's vocabulary — one name per concept, one concept per name

If none of these is genuinely open, you may not need this layer right now. Say so rather than working it for the sake of it.

---

Disciplines — what keeps the model honest

Apply these to whatever you produce, in any order. They are the high-value part of this layer.

• Real objects only. A true object is instanceable (you can have many), structured (has its own attributes), and useful (the user cares about it in its own right). This catches two errors: an attribute promoted to an object, and — more often — instances mistaken for objects: "CAC" and "ROAS" aren't objects, they're instances of one object, Metric. When several nouns are of-a-kind, model the type as the object; the specific names are instances or values.
• Attributes that are really relationships. If an attribute is just the name or ID of another object in the model, model it as a relationship — don't duplicate it.
• Name the role when an object plays several. "belongs to one User (as referrer)", not "belongs to one User."
• No speculative additions. Every object, attribute, action, and relationship should trace to a stated user need. Scope creep here propagates through every layer above. (Tracing to strategy vocabulary doesn't count — strategy words aren't yet objects.)
• Can-be-an-object ≠ should-be-first-class. The "real objects only" test tells you something can be an object — not that the product should commit to it as a first-class, persistent, stateful entity. That elevation is a design bet with a cost. Justify it by concrete use: what flow or job forces this thing to persist, hold state, and be returned to? If nothing does, it's transient, or it's premature. And when an object exists only because of an unvalidated strategy bet, mark it provisional — model it as a hypothesis, don't "lock" it, and don't build the layer above on it until the bet is tested.
• Verb precision. Does a generic verb (Edit, Delete, Update) hide operations with different real-world consequences? "Edit address" conflates correcting a typo (overwrite is fine) with recording a house move (which should preserve history). When a generic verb could mean genuinely different things, name the operations separately — "Correct address" vs "Register change of address" isn't verbose, it's precise.
• Implementation is not design. When talk drifts to how something is stored, generated, or computed, redirect to what the user can do and what happens to things that referenced it. Flag genuinely entangled questions for an engineering conversation rather than forcing a premature answer.