conceptual-modeling
Conceptual Modeling
Coverage
Methodology for abstracting a real-world domain into a structured representation before any database table, API endpoint, or aggregate boundary is named. Identifies entities (distinguishable things the business tracks), attributes (properties that describe an entity), and relationships (meaningful connections between entities). Specifies cardinality (1:1, 1:N, M:N, 0..1, 1..*); distinguishes association from aggregation from composition; uses generalization / specialization with disjoint / overlapping and total / partial constraints; recognizes when an associative relationship needs to be reified into its own entity (e.g. an enrollment between Student and Course that carries grade and date). Walks the conceptual → logical → physical abstraction ladder. Validates models against business stakeholders' mental models via walk-through, scenario testing, negative testing, and terminology audit. Names the seven anti-patterns: implementation leakage, missing entity, god entity, phantom relationship, premature normalization, attribute-as-entity, unnamed relationship.
Philosophy
Every software system is a model of some real-world domain. The quality of that model determines whether the system helps or hinders its users. Without explicit conceptual modeling, the team jumps directly from requirements to code — encoding implicit assumptions that surface later as architectural debt. A requirement like "users can place orders" hides dozens of decisions: is a cart an order? can an order have multiple shipments? is a refund a new entity or a state of a payment? Conceptual modeling forces those decisions to the surface before code exists, so rework happens on a whiteboard rather than across a migration.
The discipline is anti-rigid in a specific way. Conceptual modeling stays one layer above logical modeling (tables, foreign keys, normalization) and one layer above DDD tactical design (aggregates, bounded contexts, anti-corruption layers). The moment the model speaks of UUIDs, indexes, or cascade behavior, it has fallen into logical modeling. The moment it prescribes aggregates or anti-corruption layers, it has crossed into DDD. Conceptual modeling's job is earlier and narrower: capture the domain structure clearly enough that those later design layers can proceed without guessing about the business.
1. The Three-Level Architecture
| Level | Purpose | Audience | Notation |
|---|---|---|---|
| Conceptual | What exists in the business domain | Business stakeholders, product managers | Simplified UML class diagrams, entity lists, relationship maps |
| Logical | How the data is structured, platform-independent | Architects, senior developers | Normalized schemas, interface contracts, type hierarchies |
| Physical | How the data is stored and accessed | Database engineers, backend developers | SQL DDL, index strategies, partition schemes |
More from jacob-balslev/skill-graph
a11y
Use when building or reviewing interactive UI, forms, navigation, or dynamic content. Covers semantic HTML, keyboard access, focus management, labeling, state-change announcement, and reduced-motion / high-contrast preferences. Do NOT use for color-palette creation, visual branding, feedback-state staging, or prose reading-level accessibility - those belong to `visual-design-foundations`, `interaction-feedback`, and documentation respectively.
7intent-recognition
Use BEFORE any tool call that could modify state, touch sensitive targets, rewrite history, install dependencies, publish packages, or expose credentials/environment data. Classifies intent into Passive/Read, Reconnaissance, Modification, or Destructive/Irreversible using operation type plus target sensitivity, then runs Identify / Confirm / Verify before action. Do NOT use for deciding what code to write, executing already-classified work, reactive post-execution guardrails, or defining upstream governance policy.
6dependency-architecture
Use when designing or auditing dependency structure: package boundaries, runtime vs build dependencies, adapter layers, duplicate-purpose libraries, supply-chain risk, upgrade policy, lock-in, and dependency graph health. Do NOT use for choosing a major framework (use `framework-fit-analysis`), vulnerability-only review (use `owasp-security`), or routine refactoring without dependency boundary changes (use `refactor`).
6information-architecture
Use when structuring information for findability: navigation, page hierarchy, docs architecture, sitemap shape, labeling systems, wayfinding, and content grouping. Do NOT use for formal category-governance work (use `taxonomy-design`), responsive page composition (use `layout-composition`), component/token architecture (use `design-system-architecture`), or sentence-level UI text (use `microcopy`).
6design-thinking
Use when orchestrating a full human-centered design process across discovery, definition, ideation, prototyping, and testing — when uncertain which stage of the arc a team is in, when deciding whether to loop back, or when routing to the right stage-specific sibling skill. Do NOT use for single-stage execution (go directly to problem-framing, user-research, research-synthesis, journey-mapping, ideation, prototyping, or usability-testing) or for engineering domain discovery (use event-storming).
6knowledge-modeling
Use when deciding *which representation paradigm* fits a piece of domain knowledge — knowledge graph vs frames vs production rules vs semantic network vs concept map vs procedural ontology vs hybrid — when designing AI-agent context systems, building a knowledge base, structuring a skill or reference library, or planning a GraphRAG retrieval pipeline. Covers the seven paradigms with structure / best-for / weakness tables, the tacit-to-explicit knowledge acquisition pipeline (elicitation → articulation → formalization → validation → encoding), knowledge graph design principles (reify when needed, separate schema from instance, label precisely, bidirectional naming, minimal redundancy), the four knowledge-validation types (completeness / consistency / relevance / currency) plus expert walkthrough, the seven-phase knowledge lifecycle (Create / Validate / Publish / Use / Monitor / Update / Retire), the application to AI-agent systems (skills as frames, routing as rules, memory as graph), and a full GraphRAG section covering the five patterns (entity-anchored retrieval, relationship-aware context, path-based reasoning, subgraph summarization, hybrid vector+graph) with rules for when graph-grounded retrieval beats plain RAG. Do NOT use for the *human-readable* domain analysis layer (use `conceptual-modeling`), for the database / ER design layer (a logical-modeling skill), for pure classification hierarchies (a taxonomy skill), for formal ontology axioms (an ontology skill), or for the live skill-library tooling that consumes modeled knowledge (use `skill-infrastructure`).
6