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

1. The Three-Level Architecture

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

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

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

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.

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

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

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

7. From Conceptual Model to Downstream Work

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

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

Skill Graph context

<!-- skill-graph-context:start (generated — do not edit by hand) -->

Classification

• Subject: software-architecture
• Public: true
• Domain: engineering/modeling
• Scope: Translating messy business requirements, stakeholder language, and early product ideas into an implementation-neutral domain model before schemas, endpoints, or DDD aggregates are named — entities, attributes, named relationships, cardinality, identity criteria, specialization/generalization, aggregation/composition, reification, abstraction-level control, stakeholder validation, and modeling anti-patterns. Portable across any domain-modeling effort; principle-grounded, not repo-bound. Excludes database ER diagrams with keys and normalization (entity-relationship-modeling), formal ontology axioms in OWL/RDFS (ontology-modeling), and downstream DDD or interface-boundary design handled by event-storming and system-interface-contracts.

When to use

• a stakeholder says users place orders that ship in multiple boxes -- how do I capture this as a model before naming tables?
• is a refund its own entity or just a payment status -- what conceptual test decides that?
• two business stakeholders disagree on whether a cart and an order are the same thing -- how should the conceptual model resolve that?
• our domain diagram already mentions UUIDs and cascade-delete -- what anti-pattern is that and how do I pull it back?
• this relationship has a date, an amount, and a status -- should it stay as a line between entities or become its own entity?
• should this attribute live on Customer or Order -- what is the rule?
• we have Physical, Digital, and Subscription products -- how do I model that as specialization without lying about totality?

Not for

• give me the physical table design with PKs, FKs, and normalization forms
• turn this model into SQL migrations and index definitions
• I need OWL class axioms and reasoning constraints for these concepts
• build the DDD aggregate boundaries and anti-corruption layer
• what hypernymy or meronymy labels apply between these two terms
• review this ORM model class for code correctness
• name the entities and fields once we agree on the conceptual model

Related skills

• Verify with: semantic-relations, entity-relationship-modeling, ontology-modeling
• Related: taxonomy-design, entity-relationship-modeling, semantic-relations, ontology-modeling, event-storming, system-interface-contracts, naming-conventions, code-review

Concept

• Mental model: |
• Purpose: |
• Boundary: |
• Analogy: 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.
• Common misconception: |

Grounding

• Mode: universal
• Truth sources: https://doi.org/10.1145/320434.320440, https://www.omg.org/spec/UML/2.5.1/PDF, https://opentextbc.ca/dbdesign01/chapter/chapter-8-entity-relationship-model/, https://www.ibm.com/think/topics/conceptual-data-model

Keywords

• conceptual model, conceptual modeling methodology, domain abstraction, implementation neutral model, business model to system model, stakeholder validation, entity identity criteria, named relationship, relationship cardinality, reified relationship

<!-- skill-graph-context:end -->