Skip to content

Entity Individuation Criteria Design

Make entity identity explicit by defining unity, same-as, persistence, split/merge, and countability rules before records, identifiers, rights, measurements, or decisions depend on them.

Essence

Make entity identity explicit by defining unity, same-as, persistence, split/merge, and countability rules before records, identifiers, rights, measurements, or decisions depend on them.

This archetype is for moments when the most important design decision is not how to label an entity, but what is allowed to count as one entity in the first place. It makes identity criteria explicit before the system builds records, identifiers, registries, measurements, responsibilities, rights, or automated decisions on top of them.

Compression statement

Entity Individuation Criteria Design is a governance and representation archetype for situations where a system must decide what its countable individuals are. It turns implicit assumptions about entities into reviewable criteria: which kinds exist, when parts compose one whole, when two presentations are the same entity, which changes preserve identity, when division or combination creates new individuals, and who may revise the rules. The output is not merely a taxonomy, identifier, or deduplication rule; it is the rule-system that makes counting, reference, persistence, responsibility, and reconciliation coherent.

Canonical formula: scope + identity_providing_kind + unity_test + same_as_test + persistence_rule + split_merge_rule + authority -> governed_inventory_of_countable_individuals

Why this is not just ontology or classification

Ontology clarification asks what entities, categories, and relations are present. Canonical classification asks how already-individuated things should be sorted. Entity Individuation Criteria Design sits one layer deeper: it asks what makes something one thing, what makes two presentations the same thing, and what changes a thing can survive while remaining itself. A taxonomy can be perfectly tidy while still counting the wrong unit. A registry can use stable identifiers while still binding those identifiers to unstable or contested entities.

Core components

ComponentDescription
Individuation Scope Boundary The scope boundary states where the criteria apply. A person, household, legal person, record, organism, work, or account may be individuated differently across contexts. Without scope, one system's valid entity rule can be misapplied as if it were universal.
Entity-Kind Catalog The catalog lists the kinds that can supply persistence criteria. It distinguishes identity-providing kinds from temporary descriptions, roles, states, and labels. For example, “patient,” “account holder,” “guardian,” and “employee” may be roles, while a legal person, natural person, account, or case file may be the entity kind relevant to a particular process.
Unity Criterion The unity criterion decides when parts compose one whole. It is the rule behind questions such as whether a colony is one organism, whether modules compose one system, whether a case file includes an attachment, or whether a household remains one unit after a member moves.
Identity Criterion The identity criterion decides when two presentations are the same entity. It governs record linkage, entity resolution, alias handling, provenance, authentication boundaries, legal continuity, and cross-system matching. It should not collapse into a matching score or shared identifier without an explicit warrant.
Persistence-Through-Change Rule Persistence rules say what changes an entity can survive. Repair, migration, renaming, ownership transfer, file conversion, organizational restructuring, growth, replacement, and role change may preserve identity in one scheme and create a successor in another.
Split, Merge, and Succession Rule Transitions are where hidden identity assumptions cause the most damage. The split/merge rule records when an entity forks, branches, combines, inherits continuity, supersedes another entity, or becomes multiple countable individuals.
Countable Inventory Register The register shows the resulting inventory of individuals and the rule basis for each count. It is not merely a list; it is an auditable consequence of the criteria.
Edge-Case and Contestation Register The edge-case register prevents exceptional decisions from becoming hidden precedent. It records uncertainty, disputed cases, review rationale, appeal paths, and unresolved cases.
Authority and Revision Protocol Because identity rules allocate rights, responsibilities, counts, eligibility, and evidence, they need governance. This component defines who can interpret, revise, override, appeal, and migrate the criteria.
Downstream Consequence Audit Changing individuation changes denominators, eligibility, exposure, liability, privacy, resource allocation, and accountability. A consequence audit makes those effects visible before a rule is accepted.

Common mechanisms

An Individuation Criteria Charter records the governing rules. An Entity Definition Workshop surfaces tacit assumptions before implementation. An Identity and Unity Test Checklist makes same-as and part-whole decisions repeatable. A Split/Merge Decision Tree handles transitions. A Master Entity Registry stores accepted entities and rule bases. An Entity Resolution Policy operationalizes same-as decisions. A Versioned Identity Rulebook preserves comparability across rule changes. An Edge-Case Adjudication Panel handles contested cases. A Count Impact Assessment estimates how proposed rules alter denominators and downstream outcomes.

These mechanisms are not the archetype. They are ways to implement the broader pattern: explicit governance of what counts as one entity.

Parameters to tune

  • Granularity: how fine or coarse the entity unit should be.
  • Persistence strictness: which changes preserve identity and which create successors.
  • Evidence threshold: how strong the same-as evidence must be before merging presentations.
  • Transition semantics: how splits, merges, forks, replacements, and successions are represented.
  • Contestability: who can challenge an identity decision and by what process.
  • Versioning depth: how much historical rule migration must be preserved.
  • Consequence sensitivity: how heavily rights, privacy, rates, liability, and resource allocation shape the rule.

Invariants to preserve

The scheme should preserve traceability from count to criterion, keep identifiers downstream of identity rules, make edge cases visible, state the identity-providing kind, specify transition semantics, and keep criteria versioned. It should also preserve uncertainty where evidence does not justify a hard same-as or one-many decision.

Neighbor distinctions

Examples

In healthcare, person, patient, encounter, specimen, caregiver role, and account must be individuated differently for consent, care continuity, billing, and analytics. In ecology, modular organisms and clonal colonies force explicit unity criteria before counts are meaningful. In libraries, abstract works, editions, translations, copies, and migrated files require persistence rules. In corporate law, mergers, subsidiaries, renamings, and successor offices require continuity and succession criteria. In software, a user, credential, profile, tenant, organization, and role may be separate entities or aspects of deeper identity objects.

Failure modes

The most common failure is identifier substitution: a key or name is mistaken for the entity criterion. Other failures include false merges, false splits, unity overreach, persistence overclaim, edge-case precedent drift, denominator manipulation, and cross-context identity collision. The mitigation is not simply more data; it is better governed criteria and explicit review of consequences.

Review note

This draft is merge-sensitive with ontology, classification, equivalence, and reconciliation archetypes. It should remain distinct if reviewers value the combined package of unity criteria, same-as criteria, persistence rules, split/merge handling, countable inventory, authority, and consequence audit.

Common Mechanisms

  • Count Impact Assessment
  • Edge-Case Adjudication Panel
  • Entity Definition Workshop
  • Entity Resolution Policy
  • Identity and Unity Test Checklist
  • Individuation Criteria Charter
  • Master Entity Registry
  • Split/Merge Decision Tree
  • Versioned Identity Rulebook

Abstractions this archetype builds on — directly (a source ingredient) or as a related pattern. Links follow the typed catalog namespace.

Built directly on (7)

  • Criteria of Individuation: The rules a system fixes for what makes something one entity — when parts compose a single whole, when two presentations are the same entity, and which kind supplies a thing's persistence — together constituting its inventory of countable individuals.
  • Equivalence Relation: Groups elements into equivalence classes.
  • Identity Test: The rule that decides, in a given system, when two presentations refer to the same entity.
  • Identity-Providing Kind: A category whose membership fixes what it takes for an instance to remain the same instance over time, supplying persistence criteria rather than a temporary description.
  • Ontology: What exists and how entities relate.
  • Set and Membership: Groups and categorizes elements.
  • Unity Test: The rule that decides, in a given system, when a collection of parts counts as one whole rather than many.

Also references 23 related abstractions

  • Abstract Work: A content identity that persists across its concrete carriers, with an explicit criterion for which instance-variations preserve the work and which fork a new one.
  • Appellation: A stable opaque token is bound by an authoritative act to an entity and thereafter used to refer to it across contexts, decoupling reference from description.
  • Aspectual Individual: Treating a single underlying entity, under a fixed role or aspect, as a distinct derived bearer of properties with its own narrower existence conditions.
  • Bijectivity: A correspondence that is exactly one-to-one and onto — no collisions, no gaps — so it is reversible and the two collections have equal size and information content.
  • Boundary: Defines system limits.
  • Cardinality: Size of sets.
  • Category: Describe a system by its arrows and their composition, not by what its objects are.
  • Classification: Sorting entities into discrete categories by explicit rules, turning unbounded variation into a finite, reusable map for downstream reasoning and action.
  • Composition: Arranges components into a cohesive whole.
  • Continuity: Smooth change without jumps.

Variants

Narrower or domain-specific specializations that share this archetype's core structure. Recognized variants are established; candidate variants are provisional.

Identity Test Design · subtype · recognized

A subtype focused on deciding whether two presentations, records, references, or observations denote the same entity.

  • Distinct from parent: The parent covers the whole individuation rule system; this variant covers one test inside that system.
  • Use when: Duplicate records, aliases, observations, or references may or may not point to the same underlying entity; Downstream action requires a same-as decision rather than only category membership; The system must preserve uncertainty or appeal paths for ambiguous matches.
  • Typical domains: data governance, law governance, forensics, healthcare records
  • Common mechanisms: entity resolution policy, identity and unity test checklist, master entity registry

Unity Test Design · subtype · recognized

A subtype focused on deciding when parts, members, events, components, or attributes compose one whole rather than many.

  • Distinct from parent: The parent also covers sameness across presentations and persistence through change.
  • Use when: The issue is whether a collection should be treated as a single whole, aggregate, system, artifact, organism, team, case, or work; Different part-whole boundaries change counts, responsibility, maintenance, rights, or measurement; The same parts can be grouped in multiple plausible ways.
  • Typical domains: biology, systems engineering, organizational design, legal boundary setting
  • Common mechanisms: identity and unity test checklist, entity definition workshop, count impact assessment

Persistence-Kind Criteria Design · subtype · candidate

A subtype focused on choosing which kind supplies the persistence conditions for an entity across change.

  • Distinct from parent: The parent includes unity and same-as tests; this variant focuses on persistence across change.
  • Use when: The same thing can be described under several roles or categories, but only one kind should govern whether it remains the same entity; A change of state, role, owner, location, medium, version, or representation might or might not create a new entity; Rights, responsibilities, provenance, or continuity depend on the chosen identity-providing kind.
  • Typical domains: law governance, digital preservation, biology, product lifecycle management
  • Common mechanisms: individuation criteria charter, versioned identity rulebook, split merge decision tree

Countable Inventory Design · implementation variant · candidate

A variant focused on converting individuation criteria into a governed list of countable individuals and denominator rules.

  • Distinct from parent: The parent establishes the full criteria; this variant operationalizes the resulting inventory.
  • Use when: The main decision consequence is how many individuals, units, cases, works, accounts, parcels, organisms, or assets exist; Counts, rates, eligibility thresholds, inventories, or resource allocation depend on the individuation rule; Auditors need to trace why an item appears as one countable unit.
  • Typical domains: statistics, public administration, ecology, asset management
  • Common mechanisms: master entity registry, count impact assessment, versioned identity rulebook

Near names: Individuation Criteria, Principles of Individuation, Entity Identity Rules, Unity and Identity Criteria, Countable Entity Framework, Persistence Criteria Design, Entity Resolution Criteria.