Identity Bounded Change¶

Modify an existing entity only inside an explicit identity boundary, retain its stable identity and lineage when continuity tests pass, and declare replacement or a fork when they do not.

Overview¶

Identity-Bounded Change is the intervention pattern for changing an entity without letting the identity question be decided accidentally. It applies when an object, institution, document, dataset, model, service, asset, or other recognized subject must be modified and later users need a defensible answer to a deceptively simple question: is the result another state of the same entity, or is it a successor, replacement, fork, split, or merge?

The archetype does not assume that change destroys identity, and it does not assume that a stable label preserves identity. Instead, it places a declared boundary around change. That boundary combines an identity-persistence criterion, a mutable-property envelope, a stable identity binding, an authorized event lineage, and an explicit continuity decision. When the boundary is crossed, the intervention changes relation semantics rather than forcing the new result into the predecessor's identity.

This is useful because identity labels carry consequences. They may determine which history is inherited, which approval remains valid, which citation resolves, which warranty or liability attaches, which cultural claim is recognized, which interfaces remain compatible, and which incidents belong to one governed lifecycle. A weak identity practice can therefore erase rupture or manufacture false continuity even when every individual record looks administratively tidy.

The structural problem¶

A changing entity has at least three distinguishable layers:

a persistent identity, which says which entity is being discussed;
a state or version, which says how that entity is configured at a given time; and
a lineage, which explains how one state or entity is related to earlier ones.

Many systems collapse these layers. A filename, registry key, serial number, account, DOI, product name, or database row is treated as both the identity and the evidence that identity persisted. Other systems do the reverse: every change creates a fresh object, even when practice depends on treating the object as one continuing subject. Both approaches avoid the substantive judgment rather than solving it.

The hard cases arise because identity can depend on several kinds of evidence at once:

material continuity, such as retained fabric or component lineage;
structural continuity, such as preserved organization or relations;
functional continuity, such as continued role or intended purpose;
procedural continuity, such as authorized amendment or maintenance;
provenance continuity, such as origin and custody;
legal or institutional continuity, such as recognized succession rules;
semantic continuity, such as preserved subject matter or commitments; and
historical continuity, such as an unbroken, reviewable event chain.

No universal percentage or single property settles every domain. The archetype therefore governs how a criterion is declared and applied; it does not impose one metaphysical theory of identity.

Intervention logic¶

1. Identify the subject and the scope of the identity claim¶

Start by naming the entity whose continuity matters. Do not begin with the identifier alone. State whether the claim concerns a physical object, an abstract work, a legal instrument, a regulated asset, an organization, a dataset, a model, a product line, or another kind of subject. Also state the scope of the decision. A legal registry, a museum catalog, a software package manager, and a community may each maintain legitimate but non-equivalent identity relations.

2. Declare the persistence criterion¶

The identity-persistence criterion explains what must remain true for the after-state to count as the same entity. It should name required properties, relations, procedures, authorities, provenance links, and disqualifying events. A criterion may be conjunctive, weighted, thresholded, or deliberative, but it must be reviewable and specified independently of the outcome stakeholders prefer.

The criterion should also distinguish evidence from decision. Continuous custody, high similarity, common ownership, or a stable name may support a conclusion, but none should silently become the conclusion.

3. Define the mutable-property envelope¶

The mutable-property envelope identifies what may change without ending the entity. It can include ordinary maintenance, correction, replacement of consumables, authorized amendment, compatible refactoring, retraining, restoration, or reconfiguration. It must also identify identity-critical properties and interactions. A sequence of small changes can collectively cross the boundary even when no single event appears decisive.

4. Separate identity, version, content, and location¶

Bind the stable identity to an authoritative lifecycle record. Give each accepted state or version its own identifier or ordering relation. Keep content-addresses, storage locations, names, owners, and interfaces separate. This prevents a tool's convenience model from deciding the ontology.

A stable identifier should resolve to the current state, historical versions, provenance, and successor relations. It should not be silently reassigned after retirement or replacement.

5. Record the modification as an event¶

Each relevant modification should preserve a before-event-after chain:

the pre-change state;
the proposed and realized changes;
the authority and rationale;
time or ordering;
evidence and provenance;
the post-change state;
the identity decision; and
any downstream propagation or exceptions.

The event record is not merely a change note. It is the evidence-bearing link by which the after-state claims continuity with the before-state.

6. Apply local and cumulative continuity tests¶

A local test asks whether this event and resulting state satisfy the criterion. A cumulative test asks whether the entire lineage still supports the identity rationale. Both matter. Pairwise acceptance alone can create Ship-of-Theseus drift, while a baseline-only comparison can ignore legitimate path-dependent continuity.

The test should be able to return pass, fail, or materially indeterminate. Indeterminate results should carry restrictions, an accountable owner, and a resolution path rather than being converted silently into pass.

7. Preserve identity or change relation semantics¶

When continuity passes, retain the persistent identity and append the event and new version to the lineage. When it fails, do not erase the connection. Create or recognize a distinct identity and record the appropriate relation:

replaces when the new entity takes over the predecessor's role;
derives from when it is created from predecessor material, information, or design;
forks from when a parallel descendant remains;
splits from when one predecessor yields several successors;
merges from when several predecessors produce one successor; or
reconstructs when a new entity intentionally represents an earlier one without claiming uninterrupted identity.

This switch is the core safeguard. The change may still be valuable or necessary; the archetype simply refuses to describe a successor as an in-place modification when the persistence criterion no longer supports that claim.

8. Propagate and reconcile the decision¶

Identity decisions affect dependent records. Update registries, references, legal instruments, catalogs, model cards, configuration baselines, maintenance histories, interfaces, citations, permissions, and incident records. Where different domains need different identity scopes, record the divergence explicitly and preserve mappings rather than forcing false unanimity.

Key components¶

Component	Description
Identity Persistence Criterion ↗	The criterion is the central decision rule. It states which continuities are constitutive, which changes are permissible, what evidence is required, and which events force successor semantics.
Mutable Property Envelope ↗	This envelope turns a vague notion of “minor change” into a governed range of permitted transformations. It should include cumulative and interaction effects.
Persistent Identity Binding ↗	The binding keeps stable identity distinct from version, location, content, ownership, and display name. It supplies namespace and lifecycle rules.
Versioned Subject and Version Identifier ↗	These represent one subject across multiple states while keeping each state precisely referencable. They do not prove sameness; they implement a continuity decision already made.
Transition Record and Event Log ↗	Together they preserve the ordered lineage and the evidence needed to reconstruct why identity was retained or changed.
Identity Continuity Test ↗	The test operationalizes the criterion for local events and cumulative history, yielding a reasoned decision rather than a bare Boolean.
Decision Authority ↗	The authority supplies standing and accountability. Difficult cases often involve conflicting technical, legal, curatorial, communal, or commercial interpretations, so scope and escalation must be explicit.
Replacement or Fork Rule ↗	This component ensures that failed continuity produces an accurate successor relation instead of identifier reuse or overwritten history.
Provenance, Source References, and Audit Trace ↗	These components make the judgment attributable and contestable without treating provenance alone as the identity rule.

Common mechanisms¶

An identity continuity review is the domain-general procedure that applies the criterion and records a decision. A persistent identifier resolver exposes current and historical states and successor relations. An event-sourced entity history makes the event chain reconstructable and supports local as well as cumulative review. A replacement or fork decision record preserves the reason for changing identity semantics.

Domain mechanisms include conservation treatment records and chains of custody for material objects; policy and legal amendment registers for governing instruments; version-control and revision histories for informational artifacts; and split/merge change logs for branching or recombination. These are mechanisms because they implement the pattern. None should be promoted into the archetype merely because one domain uses it frequently.

Decision questions¶

A practical review can use the following questions:

What kind of entity is this, and who has standing to define its persistence?
Which properties, relations, procedures, or histories are identity-critical?
Which properties may change, under what conditions, and with what cumulative limits?
Is the persistent identity independent of the current state, version, name, location, and owner?
Is there an authorized, evidenced before-event-after link?
Does the event satisfy the local continuity test?
Does the accumulated history still satisfy the identity rationale?
Are there concurrent descendants, predecessor multiplicity, or successor multiplicity?
What downstream rights, duties, references, approvals, or hazards inherit the identity decision?
What evidence would falsify the present decision, and how can it be contested or revised?

A “yes” to similarity but “no” to lineage is not enough. A “yes” to lineage but “no” to an identity-critical condition is also not enough. The criterion determines how the evidence classes combine.

Recognized variants¶

Repair and Refit Continuity¶

This variant applies to heritage objects, buildings, vehicles, devices, and regulated assets. Material replacement is often unavoidable, so the criterion usually combines fabric, design, function, provenance, custody, authorized process, and disclosure. It should resist simplistic formulas such as “more than half the original material” unless the domain has validly adopted such a rule.

Amendment with Continuity¶

This variant applies to charters, laws, policies, standards, contracts, and institutions. Here the amendment procedure and authority may be constitutive of identity. The same words inserted without authority may be an invalid alteration, while substantial change through a recognized process may preserve the instrument. Repeal-and-reenactment, dissolution, or reconstitution may instead produce successor identity.

Versioned Artifact Continuity¶

This variant applies to documents, datasets, software, models, and other information artifacts. It keeps persistent identity, exact-version identity, content identity, and branch identity separate. A repository history is useful evidence, but a fork, a changed intended purpose, a new governance owner, or a semantic rewrite may require a new identity even if the tool shows a normal commit.

Boundaries with neighboring archetypes¶

Continuity Preservation is about reducing disruption across a transition. A service can remain continuous while one entity is replaced by another; conversely, the same entity can persist through a disruptive restoration.

Invariant Guarding protects declared conditions. Identity can rely on invariants, but also on provenance, authority, history, relations, or constitution. Preserving an invariant does not automatically preserve the subject.

Versioned Evolution manages controlled progression through versions. Identity-Bounded Change supplies the prior judgment that determines whether those versions belong to one subject or several related subjects.

Correspondence Validation asks whether a replacement or representation adequately matches a reference. Identity-Bounded Change asks whether it is a replacement at all and how the lineage should be classified.

Autopoietic Self-Maintenance concerns systems that preserve themselves by reproducing their organization. Identity-Bounded Change is broader: it also handles passive artifacts and entities maintained by external actors.

Change-Scoped Revalidation asks what else must be reconsidered after change. The two archetypes often interact: an identity change can widen revalidation, and revalidation evidence can reveal that an assumed continuation was actually a replacement.

Failure modes and safeguards¶

Identifier essentialism¶

A persistent label is treated as proof of persistence. Safeguard by separating the binding from the continuity test and by prohibiting identifier reassignment without an explicit lifecycle event.

Outcome-shaped criteria¶

Stakeholders alter the criterion after seeing the result they want. Safeguard by predeclaring criteria, authorities, exception rules, and revision history, with independent review where continuity conveys valuable rights or avoids burdens.

Pairwise drift¶

Every event passes relative to the immediately prior state, but the accumulated entity no longer fits the original identity rationale. Safeguard with periodic cumulative review and baseline comparisons.

Fork erasure¶

Parallel descendants overwrite one another or claim one identity. Safeguard with branch markers, distinct identities, common-predecessor relations, and explicit merge authority.

Replacement laundering¶

A materially new entity retains the predecessor's identity to inherit reputation, certification, eligibility, or limited liability. Safeguard by auditing benefits attached to continuity and requiring independent review for high-consequence changes.

Over-fragmentation¶

Every minor edit receives a new identity, breaking useful histories and references. Safeguard with a practical mutable-property envelope, stable version semantics, and proportional evidence.

Cross-system divergence¶

Different registries make incompatible identity decisions. Safeguard by identifying scoped authorities, propagating the decision through source-of-truth links, and reconciling differences explicitly.

Ethics and governance¶

Identity judgments are not neutral labels. They can allocate rights, burdens, cultural status, authorship, ownership, historical responsibility, and safety obligations. The authority making the decision should therefore be visible, its scope limited, and its judgment contestable.

Plural identity narratives may be legitimate. A legal identity, curatorial identity, community identity, and technical configuration identity can differ without one automatically invalidating the others. The system should state which relation it governs and preserve mappings and dissent where possible.

Event histories can also become intrusive. Record only the lineage evidence needed for the legitimate purpose, protect sensitive provenance and personal data, and set access and retention rules. A complete technical history is not automatically an ethically justified public history.

Implementation checklist¶

Disposition rationale¶

The queue prime is an accepted target with zero direct, related, variant, or alias coverage. The pre-draft comparison found close neighbors but no current owner of the complete intervention. Existing archetypes address transition continuity, invariant preservation, version progression, self-maintenance, correspondence, or replacement management. The missing structure is the explicit same-entity decision supported by persistence criteria, mutable boundaries, stable identity binding, event lineage, cumulative review, and successor semantics. That conjunction is sufficiently distinct and cross-domain to justify a full archetype draft rather than a component, mechanism, variant, or alias.

Review focus¶

Human review should concentrate on three questions. First, is the boundary with Versioned Evolution crisp enough that the two will not duplicate one another? Second, should the new identity criterion and binding components merge with existing indexed continuity or system-identity components? Third, does the archetype represent plural and contested identity authorities responsibly enough for legal, historical, cultural, and institutional uses?

Common Mechanisms¶

Chain-of-Custody Record
Conservation Treatment Record
Document Revision History
Event-Sourced Entity History
Identity Continuity Review
Legal Amendment Record
Persistent Identifier Resolver
Policy Amendment Register
Replacement or Fork Decision Record
Split/Merge Change Log
Version Control System

Compression statement¶

Define what makes the entity this entity, distinguish mutable from identity-critical properties, bind a persistent identity independently of state or version, authorize and record each before-event-after transition, evaluate both the local change and cumulative history against the persistence criterion, and preserve identity only when the criterion passes; otherwise mint or recognize a distinct identity and record the appropriate replacement, derivation, fork, split, or merge relation.

Canonical formula: Let e@t0 have state s0, persistent identity p, lineage L, and persistence criterion K. Let c be an authorized modification producing candidate state s1. same_K(e@t0, e'@t1) = local_pass(K, s0, c, s1) ∧ cumulative_pass(K, L ⊕ c) ∧ lineage_linked(e@t0, c, e'@t1) If same_K = true: retain p; append c to L; record s1 as the next state/version of e. Else: assign a distinct identity p'; preserve the evidence; and record replaces, derives_from, forks_from, splits_from, or merges_from.

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

Built directly on (3)

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.
Identity-Preserving Modification: An entity undergoes an event that changes some of its properties while an identity-condition licenses calling the after-state a continuation of the same entity rather than its replacement.
Persistent Identifier: A designed token committed to keep resolving to its entity across changes in the entity's location, representation, custodian, or version, via a separately maintained resolver.

Also references 17 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.
Branching and Merging: Lines of development that diverge and later recombine into one.
Continuity vs. Rupture: Gradual vs abrupt change.
Data Integrity: Accuracy and consistency preserved.
Develops-From Relation: A later entity came to be by stage-wise transformation of a continuing predecessor, the same continuant passing through directed, qualitatively distinct stages under a generative rule.
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.
Invariance: Properties unchanged under transformation.
Object Permanence: A system maintains persistent internal state for entities it cannot currently observe, modeling them as continuing to exist and re-binding them on re-emergence.
Order: Defines ranking or sequencing relationships.

▸ Show 7 more

Variants¶

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

Repair and Refit Continuity · domain variant · recognized

Preserves the identity of a material object, place, or regulated asset through authorized repair, replacement of parts, restoration, or refit.

Distinct from parent: It specializes the parent criterion for embodied objects and treatment histories.
Use when: Material components are repaired or replaced but historical, legal, curatorial, or certification continuity may persist; Custody, location, fabric, function, design, and process evidence contribute differently to identity; The distinction among original, restored, reconstructed, replica, and replacement matters.
Typical domains: heritage conservation, aviation, medical devices, industrial assets
Common mechanisms: conservation treatment record, chain of custody record, identity continuity review, persistent identifier resolver

Amendment with Continuity · governance variant · recognized

Changes an authoritative rule, charter, contract, policy, or institution through a recognized amendment path while preserving the continuing instrument or body.

Distinct from parent: It specializes the parent for norm-governed entities whose identity is partly constituted by amendment rules.
Use when: An authority may amend an instrument without repealing and replacing it; Effective dates, superseded text, authorization, and downstream obligations must remain traceable; A rupture, reconstitution, or unauthorized edit would create a successor or invalid state.
Typical domains: law, public policy, contracts, standards, institutional governance
Common mechanisms: policy amendment register, legal amendment record, identity continuity review, replacement or fork decision record

Versioned Artifact Continuity · implementation variant · recognized

Preserves or breaks the identity of a document, dataset, model, software system, or other informational artifact across versions and branches.

Distinct from parent: It specializes the parent for informational artifacts with explicit version and branch machinery.
Use when: Version systems can record change but do not alone settle whether a version belongs to the same governed subject; Approvals, citations, incident history, interfaces, or model cards attach to stable identity; Forks, retraining, schema changes, or semantic rewrites may require a new identity.
Typical domains: software, data governance, machine learning, publishing, digital scholarship
Common mechanisms: version control system, document revision history, event sourced entity history, persistent identifier resolver

Near names: Identity-Preserving Modification, Identity-Preserving Change, Continuity-Bounded Modification, Same-Entity Change Control, Identity-Conserving Update.