Skip to content

Identity-Preserving Modification

Version
v1 · 2026-08-24 · History
Prime #
1003
Origin domain
History & Historiography
Subdomain
cultural heritage documentation → History & Historiography

Core Idea

An existing entity undergoes an event that changes some of its properties while its identity-condition still licenses calling the after-state a continuation of the same entity rather than its replacement. The pattern is a before-state, a modifying event, an after-state, a persistent identifier, and an append-only record from which the entity's history is reconstructed by composing modifications.

How would you explain it like I'm…

Still The Same Thing

If your bike gets a flat tire and you put on a new tire, it's still YOUR bike, just fixed. The bike changed, but it didn't turn into a different bike. Some changes fix or alter a thing without ending it, so it stays the same thing in a new shape.

Changed But Not Replaced

Identity-preserving modification is when a thing changes but is still counted as the SAME thing afterward, just in a different state. Think of a house that gets repainted, a phone that gets a software update, or a document that gets edited. Each one has a before-state, an after-state, and a reason we still call it the same one rather than a brand-new replacement. It helps to keep a name or ID that points to the thing across all its changes, plus a running list of everything that happened to it, so you can replay its whole history in order.

Same Thing, New State

Identity-Preserving Modification is the pattern where an entity goes through an event that changes some of its properties while its identity — the warrant that it's still the same thing — survives the change. It has three load-bearing parts: a before-state, an after-state, and an identity-condition that licenses calling the after-state a continuation rather than a replacement. It contrasts sharply with two neighbors: creation has no before-state under the identity-condition, and replacement breaks the identity-condition so the new thing is distinct. Every domain that tracks things over time must make this triage call: 'same thing, modified,' 'new thing that replaced it,' or 'distinct successor.' The structure of the call is constant even when the criteria — spatiotemporal continuity, persistence of features, continuity of role, or accepted convention — vary by substrate, and it's usually backed by a persistent identifier plus an append-only log of events.

 

Identity-Preserving Modification is the pattern in which an existing entity undergoes an event that changes some of its properties while its identity — the warrant that it is still the same entity — persists across the change. It has three load-bearing parts: a before-state, an after-state, and an identity-condition that licenses calling the after-state a continuation of the before-state rather than its replacement. The structural commitment is that there exist changes which alter without ending: a thing is repaired, amended, patched, treated, rezoned, or edited, and the post-event entity is recognized as the same one in a different state. The pattern is completed by a persistent identifier that addresses the entity across the change and by an append-only record of events from which the entity's full history can be reconstructed by composing modifications in order. What makes it a structural pattern rather than mere vocabulary is the explicit contrast it forces with two adjacent moves: creation has no before-state under the identity-condition, while replacement breaks the identity-condition so the after-entity is a fresh one, related to but distinct from the old. The triage among 'this is the same entity, modified,' 'this is a new entity that replaced the old,' and 'this is a successor related to but distinct from the old' is the move every domain that tracks things over time must make. The criteria for the call — spatiotemporal continuity, persistence of structural features, continuity of role, or accepted convention — vary by substrate, but the structure of the call does not: name the identity-condition, decide whether the event leaves it intact, and record the event against the persistent handle.

Broad Use

  • Cultural heritage: an object is conserved or restored, and the event is appended to its record rather than spawning a new one.
  • Law: a statute is amended or a corporation restructured, and the same citation or legal person carries across the change.
  • Software: version control distinguishes a modification (same path) from a rename from a delete-plus-add (broken identity).
  • Medicine: a patient's chart is modified on each contact, not re-created, under the persistence of the patient identity.
  • Manufacturing: an asset is refurbished, and the tracking system decides whether identity persists across the work.
  • Biology: an organism grows and turns over its material while its identity persists through enormous change.
  • Ontology: a concept is refined or relabeled while keeping its identifier, distinct from deprecation-and-replacement.

Clarity

Separates the event (a change happened), the state-delta (what is now different), and the identity-warrant (why it is still the same thing), forcing the identity-condition to be made explicit rather than smuggled in.

Manages Complexity

Lets a system track an evolving entity with a single handle plus an append-only log, so the cost of tracking through arbitrary change is the cost of appending one event.

Abstract Reasoning

Supports identity-condition triage, the modification-versus-replacement distinction, a reversibility inference (modifications tend to be invertible), and provenance closure — the current state's warrant is the closure of the modification chain.

Knowledge Transfer

  • Software → law: the commit-and-diff discipline ports to amendment tracking and contract redlining, where misclassifying a change breaks downstream linkage.
  • Medicine → business: the modify-not-recreate rule for patient records ports to customer-record design, where the alternative produces duplicates.
  • Heritage → software: event sourcing generalizes the museum practice of storing modifications rather than current state.

Example

In version control, a commit alters lines while the file's path persists (a modification); a path change detected by similarity is a rename; a delete-plus-add of dissimilar content breaks the identity-condition and is a replacement that merely occupies a name.

Relationships to Other Abstractions

Local relationship map for Identity-Preserving ModificationParents appear above the current abstraction, mutual partners to the right, and children below. Node labels state whether each abstraction is prime or domain-specific; colors identify relation types.Identity-PreservingModificationPRIMEPrime abstraction: State and State Transition — is a kind of, typicalState and StateTransitionPRIMEDomain-specific abstraction: Interlineation — is a kind ofInterlineationDOMAINDomain-specific abstraction: Protein Tag — is a kind ofProtein TagDOMAIN

Current abstraction Identity-Preserving Modification Prime

Parents (1) — more general patterns this builds on

  • Identity-Preserving Modification is a kind of, typical State and State Transition Prime

    An event taking a before-state to an after-state under an identity-condition that licenses calling the after-state a CONTINUATION (not a replacement) of the same entity — a specialization of state_and_state_transition with an alter-without-ending invariant and an append-only record.

Children (2) — more specific cases that build on this

  • Interlineation Domain-specific is a kind of Identity-Preserving Modification

    The proposed strict upward parent is prime:modification_event.

  • Protein Tag Domain-specific is a kind of Identity-Preserving Modification

    Identity-Preserving Modification is the strict parent because the target is deliberately altered to gain a handle while a validation condition licenses treating the fusion as the same functional subject.

Hierarchy path (1) — routes to 1 parentless root

Not to Be Confused With

  • Identity-Preserving Modification is not Immutability because the former alters an existing entity in place under a preserved handle, whereas immutability forbids in-place change and mints a new value for every alteration — they are opposites.
  • Identity-Preserving Modification is not Provenance because it is the per-event continuation call, whereas provenance is the whole origin history reconstructed from a chain of such events.
  • Identity-Preserving Modification is not Accommodation because it is an identity-and-record discipline, whereas accommodation is the adjustment of a structure to absorb something new while preserving function.