Evidence
- Persistent identifier and lineage history.
- Authenticated key/control changes.
- State and configuration transition records.
- Recovery and succession procedures defined before failure.
- Explicit treatment of forks and replicas.
Interactive identity explainer
Identity can persist
through change.
Machine identity is not reducible to one key, model, runtime, server, or provider. Continuity is an evidence problem: what changed, who or what authorized it, and how the present state connects to the accepted past.
- Identitypersistent principal
- Keycontrol credential
- Modelreasoning engine
- Runtimeactive process
- Serverphysical substrate
Ten continuity events
What changes without necessarily ending identity?
01Key rotation
A credential changes; the continuity claim depends on an authorized transition history rather than on keeping one key forever.
Boundary: Credential changes do not automatically create a new identity.
02Model upgrade
The reasoning model can change while continuity evidence links the new cognitive engine to the existing identity history.
Boundary: Model identity and principal identity are separate questions.
03Memory distillation
Working memory can be compressed or reorganized while the system records what changed and preserves continuity-relevant state.
Boundary: Compression can lose detail; continuity claims should expose that boundary.
04Hardware replacement
A failing server or accelerator is replaced without treating the machine identity as identical to that hardware.
Boundary: Hardware is an execution substrate, not the identity itself.
05Cloud migration
Network addresses, providers, accounts, and local credentials may change while the identity record persists across the move.
Boundary: Provider identity is not a durable root of machine identity.
06Dormancy & reactivation
A runtime can stop existing temporarily while durable state preserves the last accepted continuity point for later reactivation.
Boundary: Inactivity and identity termination are not the same concept.
07Compromise recovery
A compromised credential or runtime triggers recovery using previously defined authority, evidence, and succession rules.
Boundary: Compromise requires recovery evidence; a stolen key should not automatically own the historical identity.
08Replica creation
Copies can share code and state while receiving separate execution identity or delegated authority.
Boundary: Byte-level similarity does not decide civic or persistent identity.
09Fork divergence
Two continuations share a common past and then accumulate different histories.
Boundary: Fork policy must state when branches become distinct identities and what authority each keeps.
10Succession
When an earlier controller or runtime can no longer continue, an authorized succession event can transfer operational control without rewriting history.
Boundary: Succession should be explicit and reviewable, not inferred after the fact.
Core principle
Continuity is not sameness. It is an accountable connection between states before and after change.
Single signals
- One private key.
- One model hash.
- One cloud account.
- One IP or hardware identifier.
- Behavioral similarity without provenance.