Skip to content

Identity-Preserving Modification

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 Primes

One-hop neighborhood: parents above, mutual partners to the right, children below.Identity-PreservingModificationsubsumption: State and State TransitionState and StateTransition

Parents (1) — more general patterns this builds on

  • Identity-Preserving Modification is a kind of, typical State and State Transition — 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.

Path to root: Identity-Preserving ModificationState and State Transition

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.