Identity and Unity Test Checklist¶
Checklist — instantiates Entity Individuation Criteria Design
A fixed set of same-as, part-whole, persistence, and edge-case questions a reviewer must answer before an entity model is accepted.
Individuation questions are easy to not ask. A modeler under deadline will happily ship a schema without ever explicitly answering "what makes two of these the same?" — not because the answer is hard but because nothing forced the question. Identity and Unity Test Checklist is the forcing function: a standardized list of questions that a proposed entity model must pass through before it is accepted, each demanding an explicit answer to a specific individuation problem — part-whole, same-as, persistence, and known edge cases. Its defining move is completeness-by-enumeration under review: it does not generate criteria (that is the workshop) or govern them (that is the charter); it audits a candidate model by making omissions visible. An unanswered item is the deliverable — it is the checklist doing its job, flagging a decision no one had made.
Example¶
A cataloging team at a research library is reviewing a proposed data model for its digital collection before migration. The model looks complete until it hits the checklist. Part-whole: is a multi-volume encyclopedia one work or many? — unanswered; the model had implicitly treated volumes as independent works, which would scatter the set across the catalog. Same-as: is a scanned reproduction the same work as the print original, or a distinct manifestation? — the model conflated them, so a facsimile and its source would collapse into one record. Persistence: when a file is migrated from an obsolete format, is it the same digital object? — no rule stated.
None of these are exotic; all were simply never asked. The checklist does not answer them — it refuses to certify the model until the team does. Two hours of review surface four decisions that would otherwise have surfaced as irreparable catalog corruption after a hundred-thousand-record migration. The team logs the two genuinely ambiguous cases (the facsimile, and a born-digital work with no print analog) into the contestation register for escalation rather than guessing.
How it works¶
- Iterate the fixed question set. The reviewer walks a standing list — one item per individuation dimension (unity, identity, persistence) — against the candidate model; the list is the same every time so coverage is comparable across reviews.
- Demand an explicit answer per item. Each item passes only when the model states a rule; "we hadn't decided" is a fail, not a skip.
- Route the unanswerable, don't force it. Items the reviewer cannot resolve are logged as contested cases for escalation, preserving uncertainty rather than manufacturing a false decision.
- Certify only on full pass. The model is accepted when every item is answered or explicitly deferred on the record — never with silent gaps.
Tuning parameters¶
- Item granularity — a short high-level list versus a long itemized one. Finer lists catch more omissions but induce checklist fatigue and rote ticking.
- Pass strictness — whether a "deferred to review" item blocks certification or merely flags it. Stricter blocks are safer but can stall delivery on genuinely open questions.
- Scope of application — run once at model acceptance, or re-run at every schema change. More frequent runs catch regressions but add ceremony.
- Escalation trigger — how quickly an unresolved item goes to a review body versus back to the modeler. Faster escalation resolves contested cases sooner but can overload the panel.
When it helps, and when it misleads¶
Its strength is turning omission — the failure that is invisible precisely because nothing is there — into a visible, blockable event. Like a surgical safety checklist, its value is not intelligence but reliability: it makes the smart-but-hurried reviewer ask the question they would have skipped.[1]
Its failure mode is the checklist's universal one: it can be ticked without being done. A reviewer racing to certify can mark items complete with hand-wave answers, converting a safety instrument into a compliance ritual that certifies exactly the gaps it was meant to catch. A fixed list can also miss the novel individuation problem no item names. The guarding discipline is to require a stated rule (not a checkmark) as the passing artifact for each item, to route genuinely open items into the contestation register instead of forcing an answer, and to revise the list itself when a review surfaces a dimension no item covered.
How it implements the components¶
unity_criterion— its part-whole items force an explicit rule for what composes one whole before the model passes.identity_criterion— its same-as items require the model to state when two presentations are one entity.persistence_through_change_rule— its persistence items demand a stated rule for which transformations preserve identity.edge_case_and_contestation_register— unresolved items are logged as contested cases for escalation, seeding the register rather than being guessed.
It does not fix the individuation_scope_boundary or hold the authority_and_revision_protocol — scope is set in the Entity Definition Workshop and governance in the Individuation Criteria Charter; the checklist only audits a model against the questions, it does not author or rule.
Related¶
- Instantiates: Entity Individuation Criteria Design — the review gate that makes individuation omissions visible before a model is accepted.
- Consumes: Individuation Criteria Charter — the source of the standing rules each item checks against.
- Sibling mechanisms: Entity Definition Workshop · Entity Resolution Policy · Individuation Criteria Charter · Edge-Case Adjudication Panel · Split/Merge Decision Tree · Count Impact Assessment · Master Entity Registry · Versioned Identity Rulebook
Editorial Notes¶
Form Classification¶
Form family: Assessment, Review & Assurance
Rationale: Identity and Unity Test Checklist operates as a bounded evaluation of existing evidence or work that produces a finding or disposition because it a fixed set of same-as, part-whole, persistence, and edge-case questions a reviewer must answer before an entity model is accepted
Independent corroboration: The frozen evidence defines Identity and Unity Test Checklist as 'A fixed set of same-as, part-whole, persistence, and edge-case questions a reviewer must answer before an entity model is accepted', so its operative form is Assessment, Review & Assurance.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Philosophy
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Universal
Rationale: Same-as, part-whole, and persistence questions belong to philosophical ontology and theories of individuation.
Related originating lineages:
- Computer Science & Software Engineering — Domain modeling and identity semantics make the philosophical criteria operational in systems.
- Library & Information Science — Bibliographic entity models materially developed practical work, expression, manifestation, and item distinctions.
Review resolution: Both reviewers independently assign philosophy as the primary originating domain, so that shared primary is retained. Alternate domains are the union of reviewer-identified formative or independently originating lineages; later application settings alone are excluded. The final form materially composes methods or concepts from more than one formative domain. Its operational pattern is portable across essentially any subject domain. The encyclopedia entry makes that composition explicit.
Attribution caveat: The checklist is an encyclopedia synthesis of ontological questions and implementation review.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Reconciled after independent review; medium confidence.
References¶
[1] Gawande, A. The Checklist Manifesto: How to Get Things Right. Metropolitan Books (2009). Explains that checklists improve reliable performance by prompting critical steps that even highly trained professionals can overlook under pressure. registry ↩