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
Changed But Not Replaced
Same Thing, New State
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¶
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 Modification → State 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.