Identity Preservation Checklist¶
Screening checklist — instantiates Carrier-Independent Work Identity Governance
Screens a proposed change against the attributes that define the work — content, structure, function, authorship, interpretation, obligations — to catch, before it ships, whether identity survives or a new work has begun.
The Identity Preservation Checklist is a fast, human-run gate applied to a proposed change: it runs down a fixed list of identity-bearing attributes and asks of each, does this change leave it intact? Its distinguishing move is breadth over depth — a single pass across every dimension that could carry the work's identity (its content, structure, function, authorship, interpretation, and obligations), rather than a deep measurement of any one of them. It converts the abstract question "is it still the same work?" into a concrete, answerable set of yes/no items applied before the change lands, so an identity-breaking change is caught while it can still be stopped or renamed.
Example¶
A state nursing board is moving from paper licences to a digital verifiable credential held in a wallet app. Same licence, new carrier — but is it the same licence? Before the switchover, they run the Identity Preservation Checklist over the change. Items: does the digital credential still name the same issuing authority? Carry the same scope of practice and endorsements? Preserve the licence number as the resolvable identifier? Encode expiry and any disciplinary flags? Bind to the same legal person? Most pass — but one fails. The paper licence displayed board-adjudicated practice restrictions that the first draft of the digital schema silently dropped. The checklist catches it before issuance: dropping a restriction would have produced a credential that looks like the licence but grants more than it should — a different work wearing the same name. They add the field, and the reissue preserves identity rather than quietly widening it.
How it works¶
- It fixes, in advance, the list of identity-bearing attributes for this class of work — the ones whose loss would make it a different work — so the screen is stable across changes and reviewers.
- Each proposed change is run down the full list. The checklist's value is coverage: it is the one screen that looks at authorship, obligations, and structure in the same pass, rather than specializing in a single dimension.
- The output is a gate verdict — pass (ship as the same work), fail on a defining attribute (block or escalate), or change within the allowed-variation zone (ship, note it).
- On a fail it hands off — to a semantic measurement or a fork decision — rather than adjudicating the hard case itself.
Tuning parameters¶
- Attribute-list scope — which attributes count as identity-bearing. Widen it and more changes get flagged (safer, slower); narrow it and the screen is fast but starts missing quiet identity drift.
- Threshold per item — whether each item is hard pass/fail or graded. Pass/fail is auditable; grading catches partial erosion but invites negotiation.
- Escalation trigger — which or how many failures route to a deeper review or a fork decision rather than a simple block.
- Who runs it — self-service by the change author versus an independent reviewer. Author-run is cheap and scales; independent-run resists motivated reasoning.
- Bindingness — advisory note versus a hard gate that blocks release.
When it helps, and when it misleads¶
Its strength is that it makes identity preservation routine and prospective — a cheap, repeatable screen that catches the obvious identity-breakers before they ship, and that forces a team to state, once, what actually defines the work.
Its failure modes follow from being a list. A checklist only sees what it names, so a change that erodes identity through an attribute nobody listed sails through while the clean result lends false assurance. Run as box-ticking it becomes theater — items marked "pass" without thought — and it is the classic tool to run backwards, assembling a list the change already passes to justify a decision already made. The identity question is genuinely a Ship-of-Theseus problem[n1]: no finite list closes it. The discipline is to treat a clean checklist as necessary-not-sufficient, keep the attribute list under revision as new failure modes surface, and route the truly ambiguous case to a semantic review or a fork decision instead of forcing a yes/no.
How it implements the components¶
identity_preservation_criterion— the checklist is the criterion made operational: each item is one clause of "what must survive for this to remain the same work."allowed_variation_zone— its pass/fail lines draw the boundary between changes that are permitted variation and changes that breach identity.
It screens a change but does not measure the precise semantic delta or hold the equivalence test set — that quantification is Semantic Diff Review — nor decide when a failed check becomes a new work, which is the Fork Decision Record's fork-threshold rule.
Related¶
- Instantiates: Carrier-Independent Work Identity Governance — supplies the prospective gate that keeps a change from silently swapping the work.
- Consumes: Work–Expression–Manifestation Matrix to fix the level at which "identity" is being judged.
- Sibling mechanisms: Semantic Diff Review · Work–Expression–Manifestation Matrix · Fork Decision Record · Governed Translation or Adaptation Review · Identity Boundary-Case Table · Abstract Work Register
Editorial Notes¶
Form Classification¶
Form family: Assessment, Review & Assurance
Rationale: The checklist evaluates a proposed change across defining attributes and produces an identity-preserved or new-work finding before release.
Nearest alternative: Decision, Gate & Allocation — The finding can block shipping, but the mechanism's defining output is identity assurance rather than the release disposition.
Review outcome: Adjudicated after independent review; high confidence.
Origin Attribution¶
Primary origin: Philosophy
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Universal
Rationale: A checklist of persistence conditions operationalizes philosophical identity-through-change problems typified by the Ship of Theseus.
Related originating lineages:
- Art & Aesthetics — Content, structure, interpretation, and authorship are especially salient for artistic works.
- Engineering & Design — Configuration management materially supplies invariants and controlled-change checks for artifacts.
- Law & Governance — Legal rights and obligations often turn on whether a modified object remains the same protected work.
- Organizational & Management Science — Mission, culture, and purpose continuity provide an institutional application lineage.
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 mechanism is an applied synthesis around a philosophical problem rather than a standard checklist from one profession.
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.
Notes¶
The checklist screens a single change in isolation. Slow identity drift that accumulates across many individually-passing changes — attribute creep — is exactly what a per-change gate cannot see. Pair it with the Version Lineage Graph or a periodic re-baseline against the original to catch the cumulative drift the gate is blind to.
[n1] The Ship of Theseus — the classical puzzle (recorded by Plutarch) of whether an object whose every part has been replaced is still the same object. It is why an identity checklist can never be provably complete: there is no finite attribute list that settles every case, only one good enough for the changes a community actually cares about. ↩