# Conceptual Modeling

> Use when translating messy business requirements, stakeholder language, or early product ideas into an implementation-neutral domain model before database schemas, API endpoints, or DDD aggregates are named. Covers entities, attributes, named relationships, cardinality, identity criteria, specialization/generalization, aggregation/composition, reification, abstraction-level control, stakeholder validation, and modeling anti-patterns. Do NOT use for database ER diagrams with keys and normalization, formal ontology axioms with OWL/RDFS, or DDD tactical design; use those dedicated skills instead.

- Skill: `jacob-balslev/conceptual-modeling-2` (Agent Skill, multi-file: 4 files)
- Install (CLI): `npx skillmds@latest add jacob-balslev/conceptual-modeling-2`
- Raw SKILL.md: https://api.skillmd.com/api/skills/jacob-balslev/conceptual-modeling-2/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Product & Planning
- License: MIT
- Author: jacob-balslev (https://skillmd.com/u/jacob-balslev)
- Updated: 2026-09-21
- Page: https://skillmd.com/skills/jacob-balslev/conceptual-modeling-2

---

# Conceptual Modeling

## Concept of the skill

Conceptual modeling is a meaning-first translation layer. It turns stakeholder language and domain scenarios into an implementation-neutral map of entities, attributes, identity criteria, relationships, cardinalities, and specialization constraints. The model is not the database, not the API, and not the ontology; it is the shared domain agreement those later artifacts must preserve.

This skill exists to catch modeling mistakes while they are still cheap: ambiguous nouns, unnamed relationships, hidden many-to-many concepts, attributes that should be entities, physical design leaking into business diagrams, and subtype claims that silently change business rules. It gives agents a repeatable way to surface decisions before code, migrations, or formal axioms harden them.

This skill owns pre-implementation business meaning and stakeholder validation. It does not choose primary keys, indexes, SQL normalization forms, migration steps, OWL/RDFS axioms, SHACL shapes, DDD aggregate boundaries, anti-corruption layers, implementation names, or code-level correctness. Those are downstream skills once the conceptual model is stable. Conceptual modeling is the architectural floor plan before engineering drawings: it says what rooms exist, how people move between them, and what must be connected, while leaving materials, wiring, and load calculations to later specialists. The common mistake is treating a conceptual model as a vague sketch or as an early database diagram. A good conceptual model is neither. It is precise about meaning, identity, relationship names, cardinality, and business constraints, while deliberately refusing to decide storage, framework, or reasoning technology too early.

## Coverage

Conceptual modeling translates real-world domain language into a structured, stakeholder-readable model before implementation details are allowed to enter. It covers:

- Entity discovery: distinguishable things the domain tracks, with identity criteria for what makes two instances the same.
- Attribute placement: properties that describe one entity, derived values, multi-valued attributes, and signals that an attribute is actually a missing entity.
- Relationship modeling: named relationships, role labels, cardinality, optionality, direction, aggregation, composition, association, dependency, and relationship reification.
- Specialization and generalization: subtype/supertype modeling with disjoint versus overlapping and total versus partial constraints.
- Abstraction-level control: keeping conceptual models above logical schemas, physical storage, APIs, ontology axioms, and DDD tactical design.
- Stakeholder validation: scenario walk-throughs, negative testing, terminology audits, and conflict resolution when different stakeholders use different concepts.
- Anti-pattern detection: implementation leakage, missing entity, god entity, phantom relationship, premature normalization, attribute-as-entity, unnamed relationship, and over-formalization.

## Philosophy of the skill
Every software system is a model of a domain. If the model is wrong, correct code faithfully automates the wrong understanding. Conceptual modeling exists to make the model explicit while change is still cheap. A requirement like "users can place orders" hides real decisions: is a cart an order, can one order split into many shipments, is a refund a payment state or a separate event, and who can validate those answers?

The discipline is to stay deliberately one layer above implementation. The model should be precise enough that a stakeholder can reject it, but neutral enough that it does not smuggle in UUIDs, foreign keys, cascade rules, API routes, aggregate boundaries, or OWL axioms. Those downstream choices are important; they are just not conceptual modeling.

A useful conceptual model is not decorative. It is a decision surface. Every entity, relationship name, cardinality, and subtype constraint should answer: "What would break in the business if this were modeled differently?"

## Boundary Routing

| User need | Use | Why |
|---|---|---|
| Discover business entities, attributes, relationships, identity, and cardinality before implementation | `conceptual-modeling` | This is the meaning-first layer. |
| Translate a validated conceptual model into logical or physical storage design | `entity-relationship-modeling` | Data modeling adds keys, constraints, provenance, normalization, denormalization, and indexing tradeoffs. |
| Design database ER diagrams, tables, primary keys, foreign keys, junction tables, inheritance mapping, or SQL translation | `entity-relationship-modeling` | ER modeling is database-facing implementation design. |
| Formalize classes, properties, axioms, SHACL shapes, OWL/RDFS semantics, or reasoning assumptions | `ontology-modeling` | Ontology modeling is machine-checkable semantic formalization. |
| Decide whether one edge is IS-A, PART-OF, synonymy, causal, thematic, symmetric, or transitive | `semantic-relations` | Semantic relations supplies edge-type tests consumed by conceptual models. |
| Discover domain events, commands, policies, and aggregate candidates after the concept inventory | `event-storming` | Event-storming turns the concept inventory into behavior and workflow evidence. |
| Define stable promises across accepted boundaries, services, modules, APIs, events, jobs, or agent tools | `system-interface-contracts` | Interface contracts start after the parties and boundary are known. |
| Choose final implementation names, casing, suffixes, or rename mechanics | `naming-conventions` | Naming follows a settled model; it should not decide the model. |

## 1. The Three-Level Architecture

| Level | Question | Audience | Output | Forbidden leakage |
|---|---|---|---|---|
| Conceptual | What exists and how does the business understand it? | Stakeholders, product, domain experts, senior builders | Entity list, relationship map, cardinality, business constraints | UUIDs, tables, indexes, framework names, API routes |
| Logical | How should information be structured independent of one storage engine? | Architects, senior engineers | Types, schemas, constraints, interfaces, provenance | Vendor-specific DDL or performance tuning |
| Physical | How is it stored and accessed in this system? | Database/backend engineers | SQL DDL, indexes, partitions, migrations, storage settings | Unvalidated business assumptions |

Rules:

- Build conceptual before logical. Jumping from raw requirements to tables usually preserves the first interpretation, not the correct interpretation.
- Conceptual models must be readable by non-technical stakeholders. If a stakeholder cannot validate it, the model is too technical or too vague.
- Each lower level may add implementation detail, but it must not remove business meaning.
- When a model starts discussing storage, restore the abstraction boundary instead of pretending the physical choice is a business concept.

## 2. Core Modeling Constructs

### Entities and Identity

| Element | Definition | Test |
|---|---|---|
| Entity | A distinguishable thing the domain tracks | Can stakeholders identify two separate instances? |
| Identity criteria | The rule for deciding whether two references point to the same entity | If names or IDs change, can we still tell sameness? |
| Attribute | A property that describes one entity | Does it make sense without the parent entity? |
| Derived attribute | A value computed from other facts | Can we name the derivation source? |
| Multi-valued attribute | A property with multiple values | Does each value need identity, lifecycle, or metadata? |

Rules:

- Every entity needs identity criteria, not just a label. "Customer" is incomplete until the model says what makes two customer records the same real-world party.
- Attributes belong to the entity whose meaning they describe. If an attribute is shared by many entities, changes independently, or carries its own lifecycle, it is probably a missing entity.
- Derived attributes belong in the conceptual model only when the business names them. Mark them as derived so later layers do not treat them as independent facts.

### Relationships

| Type | When to use | Conceptual risk |
|---|---|---|
| Association | Two entities are meaningfully connected | Vague if unnamed |
| Aggregation | Whole-part where parts can exist independently | Confusing ownership with loose grouping |
| Composition | Whole-part where parts cannot exist without the whole | Overstating deletion/lifecycle semantics |
| Generalization | Subtype inherits from supertype | Creating false IS-A claims |
| Dependency | One concept uses or depends on another without owning it | Hiding an actor, trigger, or instrument role |

Rules:

- Every relationship must have a name or role phrase a stakeholder can read aloud.
- Every relationship must state cardinality and optionality on both ends.
- If a relationship has its own attributes, status, amount, date, actor, lifecycle, or identity, reify it into an entity.
- Use `semantic-relations` when the relation type itself is unclear; use this skill to place that relation inside the full domain model.

### Cardinality and Optionality

| Pattern | Reading | Example |
|---|---|---|
| 1:1 | Exactly one to exactly one | User has one Profile |
| 1:N | One to many | Customer places many Orders |
| M:N | Many to many | Products belong to many Categories |
| 0..1 | Optional one | Order may have zero or one Refund |
| 1..* | One or more | Order has at least one LineItem |

Rules:

- Cardinality is a business decision before it is a database constraint. Validate it with people who know the domain.
- Optionality is not a nullability shortcut. "May have zero" must mean the business permits absence.
- M:N relationships are acceptable in conceptual models. They become junctions later only if the logical/physical layer needs that representation.

## 3. Generalization and Specialization

Use generalization when multiple entities share identity logic or behavior that stakeholders recognize under a common term. Use specialization when a common entity has durable subtype distinctions with different attributes, constraints, or lifecycle rules.

| Constraint | Meaning | Example |
|---|---|---|
| Disjoint | One instance belongs to exactly one subtype | A payment is either CardPayment or BankTransfer, not both. |
| Overlapping | One instance may belong to multiple subtypes | A user may be both Buyer and Seller. |
| Total | Every supertype instance belongs to at least one subtype | Every Product is Physical or Digital. |
| Partial | Some supertype instances may not be specialized | A User may not yet be Buyer or Seller. |

Rules:

- Pick one from disjoint/overlapping and one from total/partial for every specialization.
- Do not model roles as subtypes unless the role changes identity or durable structure. Buyer is often a role in a transaction, not a type of person.
- Subtype models must survive counterexamples. If one valid example breaks the subtype rule, the conceptual model is overstating the domain.

## 4. Abstraction Strategies

| Strategy | Use when | Watch for |
|---|---|---|
| Classification | Grouping instances by stable type | Categories that are really temporary states |
| Aggregation | Modeling wholes composed from parts | Parts that should be independently identifiable |
| Generalization | Finding shared supertypes | False inheritance |
| Association | Connecting independent entities | Unnamed lines with no business purpose |
| Reification | Promoting a relationship to an entity | Losing relationship attributes such as date, amount, status, actor, or sequence |
| Role modeling | Representing how an entity participates in an event | Mistaking a role for an entity subtype |

A clean conceptual model often gets smaller after these strategies. Smaller is not the goal; clearer meaning is. If removal hides a business distinction, it is not cleanup.

## 5. Validating the Model With Stakeholders

| Method | What it catches |
|---|---|
| Walk-through | Read each relationship aloud: "A Customer places one or more Orders." If it sounds wrong, the model is wrong. |
| Scenario testing | Trace a real business scenario through the model. Every step should map to a model element. |
| Negative testing | Try to represent something the business says is impossible. If the model permits it, a constraint is missing. |
| Terminology audit | Every entity and relationship label should match domain language or deliberately record an alias. |
| Conflict interview | Ask two stakeholders to validate the same model and capture where their language diverges. |
| Downstream rehearsal | Ask data, API, ontology, or DDD reviewers what decision they would make from the model; if they infer different things, the model is ambiguous. |

If a stakeholder cannot read the model and recognize the domain, the model is documentation theater. Rework it until the disagreement is explicit.

## 6. Anti-Patterns

| Anti-pattern | Symptom | Fix |
|---|---|---|
| Implementation leakage | Conceptual model mentions tables, columns, UUIDs, indexes, foreign keys, cascade rules, routes, serializers, or framework classes | Strip physical/logical terms and return to entities, attributes, relationships, and constraints |
| Missing entity | An attribute stores a list, compound value, blob, or encoded string | Extract a proper entity with identity, lifecycle, and relationships |
| God entity | One entity carries many unrelated responsibilities | Split by business responsibility and relationship structure |
| Phantom relationship | Two entities are connected but no one can state the business meaning | Remove it or name the real relationship |
| Premature normalization | Conceptual model already looks like 3NF | Move normalization to `entity-relationship-modeling` or `entity-relationship-modeling` |
| Attribute-as-entity | A simple value becomes an entity only because it appears in a diagram | Keep as an attribute or enum unless it has identity, properties, lifecycle, or relationships |
| Unnamed relationship | Lines connect boxes without verbs or role labels | Name every relationship in stakeholder language |
| False generalization | A subtype hierarchy fails real examples | Replace inheritance with roles, states, or associations |
| Over-formalization | The model uses axioms, property domains/ranges, or reasoning assumptions before needed | Route to `ontology-modeling` only when machine-checkable semantics are required |

## 7. From Conceptual Model to Downstream Work

A conceptual model should hand off decisions without pretending to be the downstream artifact.

| Conceptual element | Downstream consumer |
|---|---|
| Entity and identity criteria | Data model, API resource model, ontology class, aggregate candidate |
| Attribute and derived attribute | Data field, computed value, validation shape, API representation |
| Named relationship and cardinality | Foreign key, reference, event relation, ontology property, API link |
| Reified relationship | Junction entity, event, transaction, association object |
| Specialization constraints | Type hierarchy, discriminated union, inheritance mapping, class axioms |
| Composition or aggregation | Lifecycle policy, deletion rule, nesting, ownership semantics |

Do not erase the conceptual model after implementation starts. Keep it as the explanation of why later schema/API/ontology choices mean what they mean.

## Source Notes

- Peter Chen's 1976 ER paper grounds the idea that entities and relationships can model business meaning before storage mechanics dominate the design.
- OMG UML 2.5.1 grounds class, association, aggregation, composition, generalization, multiplicity, and role notation used in many conceptual sketches.
- Open textbook ER modeling material grounds the conceptual/logical/physical ladder and the practical entity/attribute/relationship vocabulary.
- IBM's conceptual data model overview grounds the implementation-neutral purpose of conceptual models as stakeholder-facing representations before logical and physical modeling.

## Verification

- [ ] Every entity has identity criteria: what makes two instances the same.
- [ ] Every relationship has a stakeholder-readable name or role phrase.
- [ ] Cardinality and optionality are specified on every relationship.
- [ ] Aggregation, composition, and plain association are distinguished where lifecycle meaning matters.
- [ ] Generalization/specialization states disjoint or overlapping and total or partial constraints.
- [ ] Relationships with their own attributes, lifecycle, status, amount, date, actor, or sequence are reified.
- [ ] The model is free of implementation leakage: no tables, columns, primary keys, indexes, cascade rules, routes, serializers, framework classes, or OWL axioms.
- [ ] Stakeholders validated the model through scenarios and at least one negative test.
- [ ] Terminology conflicts are recorded instead of silently normalized away.
- [ ] Downstream handoff names which decisions belong to data modeling, ER modeling, ontology modeling, DDD, naming, or code review.

## Do NOT Use When

| Use instead | When |
|---|---|
| `entity-relationship-modeling` | You need logical or physical storage design: keys, constraints, provenance, normalization, denormalization, indexing, or schema tradeoffs. |
| `entity-relationship-modeling` | You need database-oriented ER diagrams, PK/FK decisions, junction tables, inheritance mapping, SQL translation, indexing, or database constraints. |
| `ontology-modeling` | You need OWL/RDFS class axioms, SHACL shapes, property domains/ranges, disjointness constraints for reasoning, or machine-checkable semantics. |
| `semantic-relations` | You only need to decide whether one relation is IS-A, PART-OF, causal, thematic, synonymy, polysemy, symmetric, or transitive. |
| `event-storming` | You need domain events, commands, policies, aggregate candidates, or workflow discovery from the concept inventory. |
| `system-interface-contracts` | You need stable promises across accepted boundaries, services, modules, APIs, events, jobs, or agent tools. |
| `naming-conventions` | The conceptual model is settled and you now need implementation names, casing, suffixes, or rename mechanics. |
| `code-review` | You are reviewing code or schema that already implements the model. |