Ontology Clarification¶
Clarify what entities, categories, and relations exist in the problem domain before designing, deciding, measuring, or governing.
The Diagnostic Story¶
Symptom: The same word is used by different teams to mean different things, producing confident agreement in meetings and incompatible implementations afterward. Policies fail at edge cases because the category boundary was never pinned down. Data fields cannot be interpreted consistently across systems that all claim to use the same standard. The glossary and the diagram exist but do not settle the decisions that keep coming back.
Pivot: Make the domain ontology explicit: name the entities, define the categories and their boundaries, specify the relations, reconcile the conflicting assumptions, and establish a rule for how future mismatches will be resolved rather than leaving revision to informal negotiation.
Resolution: Semantic confusion decreases because category choices are visible and accountable rather than implicit. Systems and teams that were using the same vocabulary to mean different things can now interoperate. Edge cases that previously broke the policy become legible as boundary questions with an explicit place to go.
Reach for this when you hear…¶
[data engineering] “Finance defines 'customer' as anyone who has paid us; product defines it as anyone with an account — until we fix that, no dashboard number means the same thing twice.”
[regulatory compliance] “The law uses 'employee' and 'contractor' but our actual workforce has five categories that don't map cleanly to either — we needed the ontology before we could even read the regulation.”
[ecological classification] “Three monitoring agencies were measuring 'wetland' and none of them agreed on where wetland begins, so ten years of data couldn't be compared.”
Mechanisms / Implementations¶
- Concept Map: An informal node-and-link sketch that surfaces the concepts in a domain, the labelled relationships between them, and the connections still missing — before any formal structure is fixed.
- Data Model
- Domain Model
- Glossary
- Ontology Map: A structured picture of a domain's entities, their types, and the boundaries between them — drawn so that definitional disagreements become visible and negotiable.
- Ontology Review Workshop
- Semantic Schema
- Taxonomy
Related Abstractions¶
Abstractions this archetype builds on — directly (a source ingredient) or as a related pattern. Links follow the typed catalog namespace.
Built directly on (3)
- Ontology: What exists and how entities relate.
- Representation: Model complex ideas.
- Schema: Structured knowledge framework.
Also references 4 related abstractions
- Abstraction: Focus on core elements.
- Boundary: Defines system limits.
- Mental Model: Internal system representation.
- Relation: Describes associations or dependencies.
Variants¶
Narrower or domain-specific specializations that share this archetype's core structure. Recognized variants are established; candidate variants are provisional.
Domain Ontology Clarification · subtype · recognized
Clarifies the entity, category, and relation model for a bounded domain such as healthcare access, product analytics, curriculum design, or incident response.
Cross-Stakeholder Ontology Reconciliation · governance variant · candidate
Reconciles entity and category assumptions across communities, disciplines, departments, or data systems that use partially incompatible meanings.
Measurement Ontology Clarification · implementation variant · recognized
Clarifies what a metric, observation, or data field is actually measuring before it is used for evaluation or control.