Identity-Preserving Modification¶

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

Core Idea¶

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. The pattern 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 this a structural pattern rather than a vocabulary is the explicit contrast it forces with two adjacent moves. Creation has no before-state under the identity-condition; 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.

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.

Structural Signature¶

the before-state — the modifying event — the after-state — the identity-condition licensing continuation — the persistent identifier addressing the entity across the change — the append-only event record — the alter-without-ending invariant

The pattern is present when each of the following holds:

A before-state. An existing entity, in a prior state, is the subject of the change — which distinguishes the pattern from creation, where no before-state exists under the identity-condition.
A modifying event. A bounded happening alters some of the entity's properties — a repair, amendment, patch, treatment, rezoning, edit.
An after-state. The entity in its post-event state, differing from the before-state in the altered properties.
An identity-condition. A licensing warrant — spatiotemporal continuity, persistence of structural features, role continuity, or accepted convention — under which the after-state counts as a continuation of the before-state rather than a replacement. This is the load-bearing role: a change that breaks the governing condition is a replacement-retaining-a-name, not a modification.
A persistent identifier. A stable handle that addresses the entity across the change, so downstream references survive it.
An append-only record. Events are logged in order; the entity's full state is its creation plus the composed series of modifications, so history is reconstructed by replaying the log against the handle, and a gap in the chain is a legible evidential defeater.

The defining invariant is alter-without-ending: some changes alter properties while leaving identity intact. The pattern forces an explicit triage among "same entity, modified," "new entity that replaced the old," and "successor related to but distinct from the old" — the criteria varying by substrate, the structure of the call constant.

What It Is Not¶

Not accommodation. Accommodation is the adjustment of a structure to absorb something new while preserving function; identity-preserving modification is the bookkeeping pattern of changing an entity's properties under an explicit identity-condition that licenses calling the after-state a continuation. One is an adaptive response; the other is an identity-and-record discipline.
Not immutability. Immutability forbids in-place change, forcing every alteration to mint a new value; this prime is precisely the pattern of altering an existing entity in place while preserving identity. They are opposites — immutability replaces, modification continues.
Not provenance. Provenance is the lineage-of-origin trail; identity-preserving modification is the alter-without-ending event plus the identity-condition that warrants continuity. Provenance is reconstructed from the modification chain, but the prime is the per-event continuation call, not the whole origin history.
Not maintenance. Maintenance is the ongoing activity of keeping something in working order; a modification event is a single bounded alteration logged against a handle, whether or not its purpose is upkeep. Maintenance may consist of modification events but is not identical to one.
Not exaptation. Exaptation is the repurposing of a feature for a new function; modification changes properties while the identity-condition holds, regardless of function-change. A modification need not repurpose anything, and an exaptation need not preserve a tracked identity.
Not versioning as such. Versioning labels and orders successive states; identity-preserving modification is the prior structural call about whether a change continues the same entity at all (versus replacing or re-creating it). Versioning rides on the continuity the identity-condition already licensed.
Common misclassification. Treating a replacement as a mere edit, or a modification as a re-creation. The catch is the identity-condition test: name the load-bearing warrant (continuity, structure, role, convention) and ask whether the event leaves it intact — if it breaks, this is replacement-retaining-a-name; if a continuous entity is re-registered, it fragments into duplicates.

Broad Use¶

The pattern recurs wherever a system records changes against persistent identifiers. In cultural-heritage documentation, an object is conserved, restored, or reframed, and the modification event is appended to the object's history rather than spawning a new record. In law and title chains, an instrument is amended or a body restructured, and the same case number or legal person carries across the change with the amendment recorded. In software engineering, a file is edited or a record updated in place, and version-control systems distinguish modification (a change on the same path) from rename (a path change detected by similarity) from delete-plus-add (broken identity).^[1] In medicine, a patient is treated and the chart's modification log records changes to the same record, with re-registration (a new record) administratively distinct from modification.^[2] In manufacturing and maintenance, an asset is refurbished or retuned, and the tracking system must decide whether identity persists across the work. In biology, an organism grows and turns over its material while its identity persists through enormous change — the commitment that change can alter without ending is foundational to speaking of an organism at all.^[3] In knowledge representation, a concept is refined or relabeled while keeping its identifier, distinct from deprecation-and-replacement. And in the philosophy of identity, the hardest cases — the gradually replaced artifact, the changed person — are the same structural move applied where the identity-condition is most contested.

Clarity¶

Naming the pattern separates three things ordinary talk collapses: the event (a change happened), the state-delta (what is now different), and the identity-warrant (why the post-event entity is still the same). It forces the modeler to make the identity-condition explicit — usually some combination of spatiotemporal continuity, structural-feature persistence, role continuity, or convention — rather than smuggling it in. This is clarifying because disputes about whether a modification preserves identity are almost always disputes about which identity-condition governs, and the vocabulary makes that locatable. Asking whether a heavily restored artifact is still the original, or whether a refurbished assembly is still the same serialized unit, becomes a question about which condition is load-bearing and whether the event leaves it intact, rather than an unframed clash of intuitions. The same clarity exposes the boundary with replacement: a change that breaks the load-bearing condition — a complete remaking, a total substitution of substance — is not a modification but a replacement that happens to retain a name, and naming the pattern makes that distinction sharp rather than rhetorical.

Manages Complexity¶

The pattern lets a system track an evolving entity with a single handle plus an append-only event log, rather than a proliferation of point-in-time records or a soup in which the entity dissolves under each change. Modification events compose: an entity's full state is its originating creation plus the ordered series of modifications, so history is reconstructed by replaying the log against the persistent identifier. This composition logic underwrites event-sourced architectures in software, amendment chains in law, and history reconstruction in medicine and cultural heritage, all of which solve the same problem — how to know the current state's warrant — by following the chain back to the originating event.^[4] Without the identity-preserving structure, every change would demand fresh identification, and the linkage between past and present would be lost; with it, the cost of tracking an entity through arbitrary change is the cost of appending one event, and the entity's identity is carried by the handle while its state is carried by the composed log. Gaps in the chain become legible as evidential defeaters — points where the warrant for current identity cannot be reconstructed — which is itself a managed, recognizable failure rather than silent corruption.

Abstract Reasoning¶

The pattern supports several second-order moves once the identity-condition is made explicit. Identity-condition triage asks, given a change, which of spatiotemporal continuity, structural persistence, role continuity, or convention is doing the load-bearing work, and whether the change leaves that condition intact. The modification-versus-replacement distinction then predicts that a change breaking the load-bearing condition is a replacement-with-continuity-of-name rather than a modification, with different downstream consequences for what may be inferred about the entity's history. A reversibility inference follows: an entity that tolerates a modification typically tolerates its undoing — a patch can be reverted, an amendment repealed, a restoration redone — because modifications inherit a structural availability of inversion that destruction-and-recreation pairs do not. And provenance closure predicts that the meaningful history of an entity is the closure of its modification chain, so that to know the warrant for the current state one follows the chain back to creation. Each of these is recoverable from the structure itself, independent of substrate, because each turns on the relation between the event, the state-delta, and the identity-condition rather than on the particular machinery of any domain.

Knowledge Transfer¶

The pattern transfers because the disciplines built around it in one substrate are the same disciplines needed in another, once the substrate-specific vocabulary is stripped away. The commit-and-diff discipline of version control — each change recorded against a stable identifier, with author and rationale — transfers directly to amendment tracking in law and to redlining in contracts, where a misclassified change (treating a modification as a fresh document, or a replacement as a mere edit) silently breaks downstream linkage. The cultural-heritage insistence on distinguishing modification events from creation events ports to enterprise content management, where the same misclassification severs an object's history. The medical rule that a person's record is modified rather than re-created on each contact transfers to customer-record design, where the alternative produces duplicates that wreck deduplication and history. And the architectural style of storing modifications rather than current state — event sourcing — is a generalization of the museum and legal practice that ports to any domain whose audit requirements demand reconstruction of past states. The deepest carry is the discipline itself: name the identity-condition, log the event, preserve the handle. A practitioner who has learned to ask "what identity-condition are we committed to, and does this change leave it intact?" in one domain carries that question into every other, because the hard part — deciding whether a given change alters-without-ending or instead replaces — is the same structural decision whether the entity is an artifact, a contract, a patient record, an assembly, an organism, or a concept, and the cost of getting it wrong (a broken provenance chain, a lost linkage, a duplicated identity) recurs in the same form across all of them.

Examples¶

Formal/abstract¶

Version control gives the pattern its most mechanically precise worked instance, because it implements every role explicitly. Consider a file tracked across a series of commits. The before-state is the file's content at a parent commit; the modifying event is a commit that alters some lines; the after-state is the file at the child commit. The identity-condition is operationalized as path-and-history continuity: the same path, descended through the commit graph, counts the after-state as a continuation of the before-state.^[1] The persistent identifier is the file's path (and, underneath, the tree structure), and the append-only record is the commit DAG, from which the file's full state is reconstructed by composing diffs along the history. The alter-without-ending invariant is exactly what a diff encodes: a change that alters content while the path persists is a modification. The system's value lies in the explicit triage the prime names. A change on the same path is a modification. A path change detected by content similarity is a rename — the identity-condition (continuity) is preserved through a different mechanism, so history follows.^[1] A delete-plus-add of dissimilar content is a replacement — the identity-condition breaks, so the new file is a fresh entity that merely occupies a name, and blame/history does not cross the boundary.^[1] The reversibility inference is concrete: because a modification is a composable diff, it can be reverted, where a destruction-and-recreation pair cannot be cleanly undone. And a gap in the commit chain is a legible evidential defeater — a point where the warrant for the current state cannot be reconstructed — rather than silent corruption.

Mapped back: Version control instantiates every role — before-state, modifying commit, after-state, continuity identity-condition, the path as persistent identifier, the commit DAG as append-only record — and its modification/rename/replacement triage is exactly the prime's alter-without-ending call.

Applied/industry¶

Two cases run the identical alter-without-ending structure on substrates version control shares nothing with. In statutory law, an amendment modifies an existing statute. The before-state is the statute prior to the amending act; the modifying event is the amendment; the after-state is the amended statute. The identity-condition is convention plus role continuity: the same enacted instrument, carrying the same citation, is recognized as continuing rather than replaced, so prior case law and cross-references survive.^[5] The persistent identifier is the statutory citation; the append-only record is the chain of amending acts, from which the current text is reconstructed by composing amendments in order. The triage is load-bearing: an amendment is a modification, a repeal-and-reenactment with a savings clause is a successor-related-but-distinct, and a wholesale recodification can be a replacement that retains a name — and misclassifying one for another severs the linkage that lets older citations anchor.^[5] In healthcare records, a patient's chart is modified on each clinical contact rather than re-created: the before-state is the chart before the encounter, the modifying event is the encounter, the after-state is the updated chart, the identity-condition is the persistence of the patient identity, the persistent identifier is the medical-record number, and the append-only record is the timestamped encounter log.^[2] The prescribed discipline — name the identity-condition, log the event, preserve the handle — is the same here as in version control, and its violation is the same costly bug: treating a contact as a re-registration (a new record) instead of a modification produces duplicate charts that wreck deduplication and shatter the patient's history.^[2] The deepest carry is that the hard decision — does this change alter-without-ending or replace? — is one structural decision whether the entity is a file, a statute, or a chart.

Mapped back: Statutory amendment and the patient chart span law and medicine; in each, an event alters an entity while an identity-condition licenses calling the after-state a continuation, the change is appended against a persistent handle, and misclassifying modification as replacement (or re-creation) reproduces the broken-linkage and duplicate-identity failures the prime predicts.

Structural Tensions¶

T1 — Modification versus Replacement (sign/direction). The core triage is whether an event alters-without-ending or breaks the identity-condition and replaces. The boundary is where the prime stops being the whole story and the entity becomes a successor. The failure mode is misclassifying either way: treating a replacement as a mere edit (so history wrongly crosses a real break) or a modification as a re-creation (so a continuous entity fragments into duplicates). Diagnostic: name the load-bearing identity-condition and ask whether this specific event leaves it intact; the dispute is almost always about which condition governs, not about the event itself.

T2 — Which Identity-Condition Governs (scopal). The prime lists several possible warrants — spatiotemporal continuity, structural persistence, role continuity, convention — but does not say which applies, and they can disagree on the same change. A restoration may preserve structure while breaking material continuity. The failure mode is two parties reasoning from different conditions and talking past each other about whether identity survived. Diagnostic: make the operative condition explicit before adjudicating; if structural and conventional conditions yield opposite verdicts on the same event, the case is genuinely contested and the answer is a choice of condition, not a fact to discover.

T3 — Gradual Change versus the Sorites Threshold (temporal). Each individual modification preserves identity, but a long chain of identity-preserving edits can accumulate until the entity shares almost nothing with its origin — the replaced-plank ship, the wholly rewritten codebase. No single event breaks the condition, yet the endpoint may. The failure mode is assuming that because every step preserved identity, the composed whole did, so "the same entity" now denotes something the origin would not recognize. Diagnostic: periodically test the current state against the originating state, not just against the prior one; identity-preservation is not guaranteed to be transitive across a long chain.

T4 — Reversibility Inference versus Irreversible Modification (coupling). The prime infers that a modification, being a composable delta, can typically be inverted — a patch reverted, an amendment repealed. But some identity-preserving modifications are physically or legally irreversible (a destructive conservation treatment, a vested right). The reversibility inference then over-promises. The failure mode is assuming any logged modification can be undone and designing rollback that the substrate does not actually support. Diagnostic: for each modification ask what it costs to invert in the real substrate, not in the log; an event that alters identity-preservingly but cannot be physically reversed breaks the clean revert the structure suggests.

T5 — Append-Only Record versus Compaction Pressure (temporal). History reconstruction depends on the full ordered event log, but logs grow without bound and systems are pushed to snapshot, compact, or prune. Every such optimization risks discarding the events that warrant current identity. The failure mode is a compacted history with a gap — a legible evidential defeater — where the chain back to creation can no longer be replayed, so the warrant for the present state is unrecoverable. Diagnostic: ask whether the current state can still be reconstructed from creation after compaction; if a snapshot has replaced the events that justify it, identity now rests on trust rather than on a replayable chain.

T6 — Persistent Identifier versus Re-Identification (scalar). The pattern assumes a stable handle carried across the change, which is what makes modification cheap (append one event). But systems under pressure re-identify on each contact instead, minting a new record rather than modifying the existing one. The prime's whole economy collapses when the handle is not preserved. The failure mode is duplicate entities — five charts for one patient, five records for one customer — that shatter history and wreck deduplication. Diagnostic: ask whether each change routes to the existing handle or creates a new one; a system that re-identifies rather than modifies has abandoned the persistent identifier and pays the duplication cost the prime exists to prevent.

Structural–Framed Character¶

Identity-preserving modification sits near the structural pole of the structural–framed spectrum, at an aggregate of 0.2. Its skeleton is bare-relational — a before-state, an after-state, and an identity-condition that licenses calling the after-state a continuation rather than a replacement, addressed by a persistent identifier and recorded as an append-only event.

Three diagnostics read fully structural. The pattern carries no home vocabulary that must travel with it: the same before/after/identity-condition shape describes a repaired artifact, an amended statute, a patched program, a treated patient, a rezoned parcel, and a maturing organism, each told in its own field's words, so vocab_travels is 0. It carries no inherent approval or disapproval — that an entity was modified-while-preserved is a neutral structural fact — so evaluative_weight is 0. And invoking it RECOGNIZES a triage already forced on any domain that tracks things over time — same-entity-modified versus new-entity-replacing versus successor-related-but-distinct — rather than importing an interpretive frame, so import_vs_recognize is 0.

The two half-marks, institutional_origin (0.5) and human_practice_bound (0.5), reflect a modest CIDOC-CRM institutional flavor and a bias toward human-curated bookkeeping: the prime's clearest cases are records of changes someone chose to log against a persistent handle. But that lean is genuinely held in check by the biology and philosophy cases — an organism's identity persists through metabolic turnover, a persisting object survives the replacement of a part — where the same before/after/identity-condition structure runs with no curator at all. Those substrate-indifferent instances are what keep both criteria at 0.5 rather than 1.0 and ground the prime as a recognized structure. The structural label is well earned; the bookkeeping flavor is a tint.

Substrate Independence¶

Identity-preserving modification is a strongly substrate-independent prime — composite 4 / 5 on the substrate-independence scale. Its skeleton — a before-state, a modifying event, an after-state, and an identity-condition licensing continuation, addressed by a persistent identifier and recorded in an append-only log — is stated in pure relational vocabulary that names no substrate, so the alter-without-ending call is recognized rather than translated wherever things are tracked over time, which sustains the structural-abstraction mark. The domain breadth is wide and genuinely cross-substrate: the same identity-preserving change recurs in cultural-heritage conservation, statutory amendment and title chains in law, in-place editing and version control in software, the modified-not-recreated patient chart in medicine, refurbishment in manufacturing, an organism's persistence through metabolic turnover in biology, concept refinement in ontology, and the contested hard cases of philosophical identity. Transfer evidence is concrete: version control, statutory amendment, and the patient chart share the same modification/replacement triage and the same broken-linkage and duplicate-identity failures, and the commit-and-diff discipline ports directly to amendment tracking and customer-record design. What holds it at 4 rather than 5 is a modest CIDOC-CRM institutional flavor and a bias toward human-curated bookkeeping — the clearest cases are changes someone chose to log against a handle — though the biology and philosophy cases, where the before/after/identity-condition structure runs with no curator at all, keep that lean in check.

Composite substrate independence — 4 / 5
Domain breadth — 4 / 5
Structural abstraction — 4 / 5
Transfer evidence — 4 / 5

Relationships to Other Abstractions¶

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

Identity-Preserving Modification → State and State Transition → Phase Space

Neighborhood in Abstraction Space¶

Identity-Preserving Modification sits among the more crowded primes in the catalog (12^th percentile for distinctiveness): several abstractions describe nearly the same structure, so a description that fits it will tend to fit its neighbors too — transporting it usually means disambiguating within this family rather than landing on it exactly.

Family — Event Phases & Staged Recovery (10 primes)

Nearest neighbors

Computed from structural-signature embeddings · 2026-09-10

Not to Be Confused With¶

The embedding-nearest neighbor, accommodation (similarity 0.88), is a confusion of function with bookkeeping. Accommodation is the structural move of adjusting an existing structure so it can absorb something new without losing its function — a schema bending to fit an anomaly, an institution flexing to admit a new demand. Identity-preserving modification is a different kind of thing: it is the discipline of changing an entity's properties under an explicit identity-condition and recording the event against a persistent handle, so that the after-state is warranted as the same entity. The two can co-occur — accommodating a new requirement may be implemented as a modification event on a tracked entity — but they answer different questions. Accommodation asks "did the structure adapt while still working?"; identity-preserving modification asks "is the post-change thing the same one, by which identity-condition, and is the event logged?" A practitioner who conflates them will treat a successful functional adaptation as if it automatically preserved tracked identity (it may have crossed a replacement boundary), or treat an identity-preserving edit as if it must involve functional adaptation (it need not — a typo fix preserves identity while accommodating nothing).

The most consequential confusion is with immutability, because the two are direct opposites that both claim to handle "change correctly." Immutability forbids in-place mutation: every alteration produces a new value, and the old one is never touched, which is why immutable systems get cheap history and safe sharing for free. Identity-preserving modification does the opposite — it alters the existing entity in place and relies on the identity-condition to warrant that the altered thing is still the same one. In the prime's own version-control example, this is exactly the line between a modification (a change on the same path, identity preserved) and a delete-plus-add (the immutable-style move, where the identity-condition breaks and a fresh entity occupies the name). The confusion is dangerous because the two prescribe opposite implementations: an immutability discipline says "never mutate, always replace," while identity-preserving modification says "mutate under a preserved handle and log the event." Apply immutability's replace-everything reflex where identity continuity matters, and you get the re-identification bug of tension T6 — duplicate charts, fragmented history; apply in-place modification where immutability was wanted, and you lose the cheap, safe history immutability would have given.

A third confusion is with provenance (and the closely related history-reconstruction story). Provenance is the trail of where an entity came from — its origin, custodians, and transformations. Identity-preserving modification is the per-event alter-without-ending call plus the identity-condition that licenses it; provenance is what you reconstruct by composing a chain of such events back to creation. The prime's "provenance closure" reasoning makes the dependency explicit: the meaningful history of an entity is the closure of its modification chain. But the modification event is the atomic move, while provenance is the assembled history — and they fail differently. A single mis-classified modification (a replacement logged as an edit) corrupts the provenance chain at one link; a provenance gap (tension T5, compaction discarding events) destroys the reconstructability of the whole. Confusing the two leads a designer to think that having a provenance trail guarantees each individual change was correctly classified as modification-versus-replacement, when in fact the trail is only as sound as the per-event calls that built it.

These distinctions matter because each guards a different commitment. Holding identity-preserving modification apart from accommodation keeps the identity-and-record question separate from the functional-adaptation question. Holding it apart from immutability keeps the two opposite change-disciplines — alter-in-place-under-a-handle versus never-mutate-always-replace — from prescribing each other's implementations and producing the duplication or lost-history bugs. And holding it apart from provenance keeps the atomic per-event continuation call distinct from the assembled origin history it composes into, so that a sound trail is never assumed to validate the individual classifications beneath it.

Solution Archetypes¶

Solution archetypes in the catalog that build on this prime — directly (this prime is a source ingredient) or as a related prime.

Built directly on this prime (3)

Also a related prime in 8 archetypes

Aspect-Scoped Identity Projection: Represent one underlying entity under a defined aspect or role as a linked derived bearer, so properties, rights, obligations, identifiers, and lifecycle rules attach only where they belong.
Change-Scoped Revalidation: After a change, re-derive only the facts inside a justified affected closure, retain the rest by a defeasible persistence presumption, and test that the boundary did not leak.
Durable Identifier Binding: Create a durable handle for a referent, bind it in an authoritative record, and maintain enough lookup, lifecycle, and audit rules that later references can rely on the handle without re-describing the entity.
Entity Individuation Criteria Design: Make entity identity explicit by defining unity, same-as, persistence, split/merge, and countability rules before records, identifiers, rights, measurements, or decisions depend on them.
Entity Persistence Across Observation Gaps: Keep a temporarily unseen entity represented as an uncertain continuing entity, then re-associate its return to the retained identity before declaring disappearance or creating a replacement.
Latent Constraint Preservation Audit: Treat a persistent structure as possible evidence of a hidden constraint: understand its function, dependencies, and failure-prevention role before removing or simplifying it.
Persistent Identifier Stewardship: Keep references usable over time by assigning a durable identifier and maintaining the resolver, metadata, and stewardship rules that make the identifier continue to reach the same intended entity.
Reference-State Conservation Intervention: Stabilize a valued object, record, state, or practice by defining the reference state worth preserving, diagnosing decay, intervening within a bounded treatment scope, and documenting future care.

References¶

[1] Chacon, Scott, and Ben Straub. Pro Git, 2^nd ed. New York: Apress, 2014. Git's content-tracking model: commits form an append-only DAG, file history follows a path, renames are detected by content similarity, and dissimilar delete-plus-add breaks identity so blame/history does not cross the boundary. registry ↩a ↩b ↩c ↩d

[2] Dolin, Robert H., et al. "HL7 Clinical Document Architecture, Release 2." Journal of the American Medical Informatics Association, vol. 13, no. 1 (2006): 30–39. Standard for clinical documents in which a patient record is modified against a persistent medical-record identifier rather than re-created, distinguishing modification from re-registration. registry ↩a ↩b ↩c

[3] Hull, David L. "A Matter of Individuality." Philosophy of Science, vol. 45, no. 3 (1978): 335–360. Argues organisms (and species) are historical individuals whose identity persists through extensive material change over time. registry ↩

[4] Fowler, Martin. "Event Sourcing." martinfowler.com, 2005. Architectural pattern of storing the full ordered sequence of state-changing events against an identifier and reconstructing current state by replaying them. registry ↩

[5] Singer, Norman J., and J. D. Shambie Singer. Sutherland Statutes and Statutory Construction, 7^th ed. St. Paul, MN: Thomson West, 2007–. The authoritative treatise on statutory drafting and construction: an amended statute is construed as a continuation of the prior statute (not a new enactment), retaining its citation and prior interpretive case law, and distinguishes amendment from repeal-and-reenactment-with-savings-clause and from wholesale recodification, with their differing consequences for continuity of citations. registry ↩a ↩b