Ontology Clarification

Clarify what entities, categories, and relations exist in the problem domain before designing, deciding, measuring, or governing.

Essence

Ontology Clarification is the intervention pattern for situations where people cannot act reliably because they are using different hidden models of what exists. It asks: What are the entities? What categories do we use? What relations connect them? Where does the model apply, and where does it break?

The archetype is not philosophical ontology as a doctrine. It is a practical move: make the domain model explicit enough that design, measurement, automation, policy, research, or coordination can proceed without semantic drift hiding underneath the work.

Compression statement

When confusion arises from unclear categories, entity boundaries, or relation assumptions, Ontology Clarification makes the domain model explicit so people can reason about what exists, how things relate, what distinctions matter, and how the model should change when reality pushes back.

Canonical formula: ambiguous_domain_terms + disputed_entities + unstated_relations -> explicit_domain_ontology + boundary_conditions + revision_rule

When to Use This Archetype

Use Ontology Clarification when repeated confusion points to disagreement at the entity, category, or relation layer. It is especially useful before building a data model, defining a metric, writing eligibility rules, designing a product workflow, integrating knowledge systems, or reconciling multiple stakeholder vocabularies.

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.

Structural Problem

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.

Intervention Logic

The intervention starts by externalizing the candidate ontology. First, list the entities and states the domain must recognize. Then define the categories that group them. Next, specify relations: membership, ownership, sequence, dependency, causation, equivalence, transformation, or whatever else matters. After that, set boundary conditions and edge cases. Finally, record contested assumptions and define how the ontology will be revised.

The critical move is not making a pretty diagram. The critical move is making reality assumptions explicit enough to test against cases and decisions.

Key Components

Ontology Clarification turns an implicit shared model of "what exists" into an inspectable artifact, layer by layer, so that downstream design, measurement, and governance no longer inherit hidden disagreement. The Entity Inventory provisionally lists the things, actors, events, states, or units the domain must recognize — a customer, an account, a household, a case — preventing arguments at the level of nouns from being buried under metric or workflow debates. The Category Definition groups those entities into kinds with stated inclusion logic, exclusion logic, and a reason the distinction matters for action, so categories are not free-floating labels. The Relation Definition specifies the links among entities and categories — membership, dependency, sequence, ownership, equivalence, transformation — recognizing that useful ontologies are not just lists of nouns but maps of how those nouns connect.

Three further components keep the model honest under scope, dispute, and time. The Boundary Condition states where the ontology applies, where it does not, and what edge cases fall outside, preventing local meanings from being silently universalized. The Assumption Reconciliation Record captures disputed assumptions and how they were resolved or preserved as alternatives, protecting against the false consensus that arises when groups agree on terms while privately meaning different things. The Ontology Revision Rule defines how the model is reviewed, versioned, reopened, and changed, keeping it stable enough to use while responsive enough to learn from new evidence, edge cases, or category failures. Optional components — a term source map, evidence anchors, an edge case register, and a translation crosswalk — become important when the ontology spans multiple communities, legacy systems, or contested categories where one group's vocabulary risks being encoded as neutral reality.

Component	Description
Entity Inventory ↗	component: slug: entity_inventory name: Entity Inventory role: Identifies the candidate things, actors, events, states, concepts, resources, or units that the domain model must recognize. notes: This begins as a provisional list. It prevents hidden disagreement about what exists while allowing later merge, split, or retirement of entities.
Category Definition ↗	component: slug: category_definition name: Category Definition role: Defines the kinds or classes used to group entities for reasoning, design, measurement, or governance. notes: A category should state what belongs, what does not, and why the distinction matters for action.
Relation Definition ↗	component: slug: relation_definition name: Relation Definition role: Specifies how entities and categories relate. notes: Useful ontologies are not just lists of nouns. They clarify links such as membership, dependency, sequence, ownership, equivalence, and transformation.
Boundary Condition ↗	component: slug: boundary_condition name: Boundary Condition role: States scope, inclusion rules, exclusion rules, edge cases, and conditions where the ontology should not be applied. notes: Boundary conditions prevent ontology overreach and make local definitions visible as local.
Assumption Reconciliation Record ↗	component: slug: assumption_reconciliation_record name: Assumption Reconciliation Record role: Captures disputed assumptions and records how they were resolved or preserved as alternatives. notes: This protects against false consensus, especially when groups use the same term differently.
Ontology Revision Rule ↗	component: slug: ontology_revision_rule name: Ontology Revision Rule role: Defines how the ontology is reviewed, versioned, reopened, and changed. notes: It keeps the ontology stable enough to use but responsive enough to learn.

Common Mechanisms

mechanism: slug: domain_model
name: Domain Model
mechanism_type: artifact
role: Represents the clarified entities, categories, relations, and constraints of a problem domain.

A domain model is often the most practical mechanism when design or implementation needs a shared map.

mechanism: slug: ontology_map
name: Ontology Map
mechanism_type: artifact
role: Shows entities, types, relations, and boundaries visually or structurally.

An ontology map helps participants see where their assumptions differ. It should not be mistaken for the archetype itself.

mechanism: slug: taxonomy
name: Taxonomy
mechanism_type: artifact
role: Organizes categories hierarchically or by controlled grouping.

A taxonomy can implement part of ontology clarification, but a taxonomy alone is usually too thin. It may omit relations, scope, edge cases, and revision rules.

mechanism: slug: data_model
name: Data Model
mechanism_type: artifact
role: Translates ontology decisions into fields, identifiers, objects, tables, or constraints.

A data model is valuable when the ontology must become operational in software or analytics. The risk is implementation capture: the system schema starts defining reality without review.

mechanism: slug: glossary
name: Glossary
mechanism_type: document
role: Provides shared definitions for terms.

A glossary is useful for vocabulary alignment, but it must be connected to entities, relations, edge cases, and revision governance to fully instantiate the archetype.

mechanism: slug: concept_map
name: Concept Map
mechanism_type: artifact
role: Sketches concept relationships before the ontology is formalized.

A concept map is often useful early, when ambiguity is still being discovered.

mechanism: slug: semantic_schema
name: Semantic Schema
mechanism_type: artifact
role: Encodes meaning-bearing categories and relations for retrieval, reasoning, integration, or machine-readable representation.

A semantic schema is appropriate when ontology clarification needs to support AI, knowledge graphs, search, integration, or automation.

mechanism: slug: ontology_review_workshop
name: Ontology Review Workshop
mechanism_type: ritual
role: Brings relevant actors together to compare assumptions, examples, edge cases, and revision rules.

A workshop is a mechanism for eliciting and reconciling the ontology. It is not itself the archetype.

• 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

Parameter / Tuning Dimensions

Granularity asks how finely entities and categories should be split. Too little granularity hides meaningful differences; too much produces an unusable model.

Formality asks whether the ontology should be a lightweight shared vocabulary, a diagram, a formal schema, or a machine-readable semantic model. More formal mechanisms support automation but cost more to maintain.

Consensus level asks which definitions must be shared and which can remain scoped. In plural domains, a forced single vocabulary may erase important local meanings.

Revision cadence asks when the ontology is reopened. It may be revised after incidents, data-integration failures, release gates, policy changes, or accumulating edge cases.

Stakeholder breadth asks whose distinctions count. This is especially important when categories affect access, identity, eligibility, rights, responsibility, or harm.

Evidence threshold asks what is enough to add, split, merge, or retire a category. Good ontology work is grounded in cases, examples, observations, and decision consequences.

Invariants to Preserve

Entity clarity must be preserved: users should know what objects and states the model recognizes.

Category accountability must be preserved: categories should have purpose, inclusion logic, exclusion logic, and limits.

Relation explicitness must be preserved: important links should be named rather than assumed.

Boundary humility must be preserved: the ontology should state where it applies, where it does not, and what remains unresolved.

Revision governance must be preserved: the model should be able to change through a defined process rather than drift silently.

Target Outcomes

A successful Ontology Clarification reduces semantic confusion, improves design and measurement, supports interoperability, prevents boundary failures, and creates controlled ontology evolution.

In practice, this means fewer meetings where people agree in words but implement different things. It also means data, policy, and product artifacts can trace their definitions back to explicit domain assumptions.

Tradeoffs

The main tradeoff is clarity versus complexity. More distinctions can improve precision, but each distinction adds maintenance burden.

Another tradeoff is shared vocabulary versus local nuance. A shared ontology supports coordination, but a single vocabulary can be harmful if it erases meaningful differences between communities.

There is also a tradeoff between stability and learning. A stable ontology enables implementation, but reality may reveal new entities, relations, or edge cases.

Finally, there is a tradeoff between speed and legitimacy. Fast ontology work may be enough for low-stakes internal modeling. High-stakes categories require broader review.

Failure Modes

Taxonomy substitution occurs when a hierarchy of labels replaces deeper entity, relation, boundary, and revision work. The mitigation is to require every category to include purpose, relations, edge cases, and revision triggers.

Frozen ontology occurs when the first model becomes authoritative despite new evidence. The mitigation is versioning and a revision rule.

False consensus occurs when people accept shared terms while retaining different meanings. The mitigation is testing definitions against concrete cases and decisions.

Over-ontologizing occurs when a team creates distinctions that do not change action. The mitigation is a decision-relevance test.

Power-coded categories occur when one group’s vocabulary is encoded as neutral reality. The mitigation is stakeholder review, edge-case capture, and explicit scoped definitions.

Implementation capture occurs when data models or software schemas dictate what the domain is allowed to be. The mitigation is to separate conceptual ontology review from implementation design before mapping between them.

Neighbor Distinctions

Ontology Clarification is distinct from Representation Fit Selection. Representation Fit Selection asks what form best represents the situation; Ontology Clarification asks what the representation must mean.

It is distinct from Schema Update Protocol. Schema Update Protocol revises an existing schema after mismatch; Ontology Clarification may be needed before a stable schema exists.

It is distinct from Meta-Symbolic Rule Reflection. Meta-Symbolic Rule Reflection inspects the symbol or rule system itself; Ontology Clarification focuses on the domain entities, categories, and relations being modeled.

It is distinct from Category Boundary Audit. Category Boundary Audit focuses on one category’s inclusion and exclusion boundary; Ontology Clarification maps the broader entity-category-relation system.

It is distinct from Canonical Classification. Canonical Classification stabilizes authoritative class assignment; Ontology Clarification decides what the classes and relations mean in the first place.

Cross-Domain Examples

In product analytics, a team clarifies whether retention applies to a person, account, organization, subscription, seat, or workspace before defining retention metrics.

In public benefits policy, an agency clarifies applicant, household, dependent, case, income, benefit unit, and residency before automating eligibility.

In healthcare coordination, clinical, billing, patient, and social-service systems reconcile meanings for patient, encounter, episode, referral, need, and outcome.

In research synthesis, reviewers clarify constructs, populations, interventions, outcomes, and relations before combining evidence across studies.

In incident response, a safety team clarifies event, cause, contributing factor, control failure, impact, and corrective action before comparing incidents.

Non-Examples

A standalone glossary is not Ontology Clarification unless it also settles decision-relevant entities, categories, relations, boundaries, and revision rules.

A taxonomy is not the archetype. It is a mechanism that may support the archetype.

A graph database choice is not Ontology Clarification unless the main work is clarifying what the nodes and edges mean.

A single category fairness review is usually Category Boundary Audit, not Ontology Clarification, unless the broader domain ontology is also unclear.

A philosophical essay about what exists is not this archetype unless it becomes an operational intervention for shared domain modeling.

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.

• Distinct from parent: The parent covers ontology clarification broadly; this variant emphasizes a bounded domain model as the working artifact.
• Use when: A team must agree on what exists in a bounded problem domain before designing, measuring, automating, or governing it; Existing terms are overloaded, vague, or inherited from different disciplines.
• Typical domains: product design, policy design, knowledge management
• Common mechanisms: Domain Model, Glossary

Cross-Stakeholder Ontology Reconciliation · governance variant · candidate

Reconciles entity and category assumptions across communities, disciplines, departments, or data systems that use partially incompatible meanings.

• Distinct from parent: The parent can be done within one team or model; this variant requires explicit reconciliation across groups with different authority, incentives, or lived categories.
• Use when: Multiple stakeholder groups use the same terms differently or use different terms for the same practical entity; A shared decision, policy, product, or dataset requires a common meaning layer without erasing legitimate local distinctions.
• Typical domains: interdisciplinary research, data governance, public service delivery
• Common mechanisms: Ontology Review Workshop, Semantic Schema

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.

• Distinct from parent: The parent clarifies domain entities generally; this variant clarifies the entity and relation assumptions embedded in measurement.
• Use when: A metric is being treated as if its object were obvious; Teams disagree about whether a data field represents a real-world object, a proxy, a state, an event, or an administrative artifact.
• Typical domains: analytics, research, performance management
• Common mechanisms: Data Dictionary, Semantic Schema

Near names: Domain Ontology, Ontology Design, Domain Modeling, Conceptual Modeling, Shared Vocabulary Creation, Entity-Relationship Modeling.