Versioned Identity Rulebook¶
Document — instantiates Entity Individuation Criteria Design
A change-controlled ledger of successive individuation-rule versions and the migration mappings that keep entities defined under old rules interpretable.
Individuation rules change — and every change silently reinterprets the entities already recorded under the old rule, unless someone keeps the history. Versioned Identity Rulebook is that record: the change-controlled document that stores each successive version of the individuation criteria and the migration mappings that say how an entity individuated under version N maps forward into version N+1. Its defining feature is that it speaks in the past-and-transition tense — it is a ledger of how the rules evolved and how counts and entities translate across a rule change, so that a figure computed three revisions ago remains interpretable today. It does not declare the current authoritative rule or name who owns it (that is the charter's role); it preserves comparability across versions, answering "under which rule was this entity created, and what does it become under the new one?"
Example¶
A national statistics office revises how it individuates a "household" for its long-running population survey — moving from a shared-dwelling definition to a shared-budget definition. The change is defensible, but it silently breaks a fifty-year time series: households counted under the old rule are not the same units as those under the new one, so year-over-year comparisons become apples-to-oranges unless the discontinuity is documented and bridged. The Versioned Identity Rulebook records both rule versions with effective dates, and — crucially — the migration mapping: a shared-dwelling multi-family household under v3 splits into two shared-budget households under v4, with a documented conversion factor for the affected strata.
An analyst comparing 1998 and 2025 figures consults the rulebook, sees that the two years sit under different individuation versions, and applies the recorded crosswalk to restate the old counts on the new basis before comparing. The rulebook does not decide which household definition is right today — it makes the transition between definitions traceable so history is not silently rewritten.
How it works¶
- Version every rule change. Each revision of the criteria is stored as a numbered, dated version, so any entity or count can be tied to the rule in force when it was made.
- Record the transition, not just the endpoints. For each version bump, document what changed and how prior entities are affected — which persist unchanged, which split, merge, or become successors under the new rule.
- Publish migration mappings. Provide the crosswalk that restates old-rule entities and counts on the new-rule basis (and back), so cross-version comparison is principled rather than assumed.
- Preserve, don't overwrite. Superseded versions stay in the ledger; the rulebook grows by appending history, never by erasing it.
Tuning parameters¶
- Versioning granularity — whether every clarification bumps a version or only substantive rule changes do. Finer versioning is precise but noisy; coarser risks bundling a breaking change with cosmetic ones.
- Migration completeness — whether every version transition ships a full crosswalk or only breaking ones do. Full crosswalks maximize comparability but are costly to build and maintain.
- Retention horizon — how far back versions and mappings are kept. Longer horizons protect long time series but grow the ledger indefinitely.
- Backward-mapping support — whether mappings run only forward or both ways. Bidirectional mappings let old and new analyses meet in the middle, at extra maintenance cost.
When it helps, and when it misleads¶
Its strength is protecting comparability across time: it is what stops a rule change from silently invalidating every count and reference made under the prior rule, and what lets a long-running series survive an honest redefinition. It is the memory the charter deliberately lacks.
Its failure mode is that migration mappings imply a precision they may not have — a "grandfather" provision that keeps old-rule entities valid can quietly accumulate two incompatible populations living under one label, and a conversion factor between household definitions can be treated as exact when it is a modeled approximation.[n1] A rulebook can also lull users into trusting a crosswalk that flattens genuinely incommensurable units. The guarding discipline is to document the uncertainty of each migration mapping alongside the mapping itself, mark which cross-version comparisons are principled and which are merely bridged, and keep the rulebook strictly a record of transitions — never letting it drift into re-asserting what the current rule should be.
How it implements the components¶
persistence_through_change_rule— across a version bump it records which prior entities persist unchanged versus become successors under the new criteria, applying persistence at the level of the rules' own evolution.split_merge_and_succession_rule— its migration mappings encode how old-rule entities split, merge, or are superseded when re-expressed under a new version.cross_context_identity_crosswalk— the version-to-version mappings are a crosswalk across the temporal contexts of successive rule regimes, restating entities and counts between them.
It does not declare the current individuation_scope_boundary, entity_kind_catalog, or hold the authority_and_revision_protocol — those present-tense governing declarations belong to its hazard-twin, the Individuation Criteria Charter; the rulebook records the history and migration of the rules, not who currently owns them.
Related¶
- Instantiates: Entity Individuation Criteria Design — the version ledger that preserves comparability when the criteria change.
- Consumes: Individuation Criteria Charter — each charter revision is the source version the rulebook records and bridges.
- Sibling mechanisms: Individuation Criteria Charter · Split/Merge Decision Tree · Master Entity Registry · Entity Resolution Policy · Count Impact Assessment · Entity Definition Workshop · Identity and Unity Test Checklist · Edge-Case Adjudication Panel
Editorial Notes¶
Form Classification¶
Form family: Record, Log & Register
Rationale: Versioned Identity Rulebook operates as a persistent ledger, log, register, or case record that preserves history and traceability because it a change-controlled ledger of successive individuation-rule versions and the migration mappings that keep entities defined under old rules interpretable.
Independent corroboration: The frozen evidence defines Versioned Identity Rulebook as 'A change-controlled ledger of successive individuation-rule versions and the migration mappings that keep entities defined under old rules interpretable', so its operative form is Record, Log & Register.
Nearest alternative: Rule, Policy & Commitment — Versioned Identity Rulebook includes features of a standing rule, threshold, contractual commitment, or policy constraint governing future conduct, but its defining operation is a persistent ledger, log, register, or case record that preserves history and traceability.
Review outcome: Independent reviewer agreement; medium confidence.
Origin Attribution¶
Primary origin: Library & Information Science
Origin pattern: Single lineage
Present-day reach: Universal
Rationale: Dublin Core Metadata Initiative, DCMI Metadata Terms documents that information science distinguishes versions, provenance, identifiers, spatial coverage, and relations so records remain interpretable through change. This is direct, mechanism-specific evidence for library information science as the best-evidenced historical home of the operation—A change-controlled ledger of successive individuation-rule versions and the migration mappings that keep entities defined under old rules interpretable.—rather than evidence merely that the operation is useful there. The retained alternates record genuine adjacent lineages; later portability is represented separately by domain_reach=universal.
Related originating lineages:
- Computer Science & Software Engineering — Computer Science supplies a historically relevant adjacent lineage or formative practice for the operation—A change-controlled ledger of successive individuation-rule versions and the migration mappings that keep entities defined under old rules interpretable.—but the adjudicated evidence more directly locates the defining lineage in library information science.
- Data Science & Analytics — Data science's modeling, validation, and monitoring tradition contributes a separate formative lineage to the mechanism's versioned identity rulebook logic.
- Law & Governance — Legal doctrine, regulatory governance, and procedural accountability supplies a parallel or contributing lineage for the mechanism's defining operation: a change-controlled ledger of successive individuation-rule versions and the migration mappings that keep entities defined under old rules interpretable.
Review resolution: The blind reviewers disagree on primary lineage (computer_science versus library_information_science). The defining operation is: A change-controlled ledger of successive individuation-rule versions and the migration mappings that keep entities defined under old rules interpretable. The researched Dublin Core Metadata Initiative, DCMI Metadata Terms establishes that information science distinguishes versions, provenance, identifiers, spatial coverage, and relations so records remain interpretable through change. That source therefore supports library information science as the historical origin. computer science remains in the uncapped alternates where it contributes a formative practice, but application or governance is not itself proof of origin. origin_mode=single_lineage records lineage construction; domain_reach=universal separately records later applicability.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Researched adjudication after independent review; high confidence.
Sources consulted:
Notes¶
The rulebook and the Individuation Criteria Charter are both documents about the criteria and are the most easily confused pair here. The distinction to hold: the charter is the present constitution (what the rules are now, and who owns them); the rulebook is the version-control ledger (the succession of rules over time and how to migrate between them). A change lands in the charter as a new authoritative statement, and lands in the rulebook as a new version plus a migration mapping — the charter governs, the rulebook remembers.
[n1] A grandfather clause exempts entities established under an old rule from a new one, letting them persist unchanged. In individuation it is a quiet hazard: over time it produces two populations — old-rule and new-rule entities — coexisting under a single label, which is exactly the incommensurability the rulebook's migration mappings must make explicit rather than paper over. ↩