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.”
When This Archetype Applies¶
No catalog groundingNone of the structural conditions is currently represented by an accepted prime or domain-specific abstraction.
Diagnostic problem
Actors use different assumptions about what the key entities are, how those entities are categorized, what relationships count, and where the domain boundary sits. Because the ontology remains implicit, later design, measurement, automation, or governance inherits hidden disagreement.
What this problem means
The structural problem is hidden ontology mismatch. People proceed as though the domain’s objects are obvious, but their assumptions differ. One person treats a customer as a payer, another as an end user, another as an account, and another as an organization. One system treats a case as a record, another as a household, another as an unresolved need.
When this layer remains implicit, downstream artifacts inherit confusion. Metrics count the wrong object. Policies exclude edge cases. Data schemas cannot integrate. Product teams optimize workflows around entities that users do not recognize. Governance decisions look technical even when they depend on contested categories.
Show the applicability expression
Applicability expression4 distinct conditions
groundedpartly groundedopen
4 conditions, all required.
4At least one of theselettered A–D
Any single one of these completes the pattern.
One term, multiple entities · open
The same word is used for different entities or states.
A good signal is the sentence, “We are using the same word, but we do not mean the same thing.” Another signal is the opposite: two teams use different words but are actually referring to the same object, state, or relation. The narrower requirement in this condition set is: The same word is used for different entities or states.
Cross-system category disagreement · open
Different systems or teams assign the same case to different categories.
The source archetype describes the situation as follows: Different systems or teams classify the same case differently. The normalized requirement above isolates the load-bearing portion used in this condition set.
Unclear category boundaries · open
Metrics, policies, or workflows rely on categories whose membership boundaries are unclear.
The source archetype describes the situation as follows: Metrics, policies, or workflows depend on categories whose boundaries are unclear. The normalized requirement above isolates the load-bearing portion used in this condition set.
Edge cases expose stakes · open
Edge cases reveal that vocabulary is carrying hidden normative or operational consequences.
The source archetype describes the situation as follows: Edge cases reveal that the current vocabulary is doing hidden normative or operational work. The normalized requirement above isolates the load-bearing portion used in this condition set.
Other requirements and context (1)
Why these sit outside the expression
Application gate — it governs whether applying the archetype is appropriate or material, rather than defining the structural problem itself.
Application gateA planned system needs a stable model before implementation.
Action requires a stable enough model of what exists, but complex domains contain contested categories, evolving entities, and multiple valid perspectives. In this archetype, the relevant application gate is: A planned system needs a stable model before implementation. It narrows when choosing or applying the archetype is warranted or decision-relevant.
Coverage
0 of 4 conditions grounded · 4 open.
None of the 4 open conditions sit in the shared core — each falls inside one alternative branch, so grounding any one of them closes only that branch.
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: Translates ontology decisions into tables, objects, fields, identifiers, or constraints used by information systems.
- Domain Model: Represents the clarified entities, categories, relations, and constraints of a problem domain in a form that teams can inspect and use.
- 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: Brings relevant actors together to compare entity assumptions, category meanings, relation claims, edge cases, and revision rules.
- Semantic Schema: Encodes meaning-bearing categories and relations for retrieval, reasoning, integration, or machine-readable knowledge representation.
- 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.
Editorial Notes¶
Problem Classification¶
Classification: Representation, Classification & Model Misfit → Ontology, Identity, State & Part–Whole Modeling
Problem kernel: implicit entity and relation assumptions block shared design
Rationale: Earliest causal condition: Actors use different assumptions about what the key entities are, how those entities are categorized, what relationships count, and where the domain boundary sits. Because the ontology remains implicit, later design, measurement, automation, or governance inherits hidden disagreement.
Independent corroboration: The earliest necessary condition in the frozen evidence is: Actors use different assumptions about what the key entities are, how those entities are categorized, what relationships count, and where the domain boundary sits. That is a ontology identity state and part whole modeling problem because The representation lacks explicit entities, aspects, states, proposition modes, or unity rules needed to say what exists and what the model is about.
Review outcome: Independent reviewer agreement; high confidence.