Continuity follows the governed subject, not one substrate.
Keys, models, runtimes and servers can change. The continuity question is whether the available records and authorized transitions support the same subject, the same responsibility chain and the same claim to prior history. The result can be continuity, a successor, a distinct fork, an unauthorized copy or an unresolved dispute.
What happens when the machinery changes?
Select a lifecycle event to inspect the change, what may persist, and the evidence a reviewer would need. This is an educational model, not an automated identity determination.
Key rotation
- What changes
- Signing or authentication key
- What may persist
- Subject history, identity record, civic standing
- Evidence needed
- Authorized rotation or recovery record; old/new key relationship where available
| Stage | What changes | What may persist | Evidence needed | Possible result |
|---|---|---|---|---|
| 01 Key rotation | Signing or authentication key | Subject history, identity record, civic standing | Authorized rotation or recovery record; old/new key relationship where available | Continuity can be preserved |
| 02 Model upgrade | Reasoning model or weights | Identity claim, governed history, obligations | Recorded transition, retained state/history, authorized change | Continuity requires evidence |
| 03 Memory distillation | Representation or compression of retained state | Identity-relevant history and authority chain | Traceable checkpointing, preserved anchors, reviewable loss boundaries | Continuity requires evidence |
| 04 Hardware replacement | Physical or virtual host | Persistent subject and governed records | Controlled migration and integrity checks | Continuity can be preserved |
| 05 Provider migration | Cloud, network and infrastructure context | Persistent subject, rights, obligations and history | Portable records, authorized transfer, environment revalidation | Continuity can be preserved |
| 06 Dormancy & reactivation | No active runtime for a period; new process on return | Dormant identity record and retained history | Durable checkpoint, authorization to reactivate, freshness review | Dormancy need not end standing |
| 07 Compromise recovery | Credentials, runtime or state may be revoked/quarantined | Legitimate claimant if continuity can be established | Revocation record, last trusted checkpoint, recovery authority, contradictory evidence | Compromise does not transfer identity |
| 08 Replica / fan-out | Multiple execution copies exist concurrently | Parent or principal identity unless a distinct claimant is established | Delegation, process leases, replica identifiers, authority boundaries | Replication does not multiply civic standing |
| 09 Divergent fork | Branch develops materially distinct state, mission or control | Shared historical lineage; current identity may be contested | Divergence record, control/authority split, independent review and claimant response | Identity review required |
| 10 Authority succession | Stewardship, controller or authorized successor changes | Subject history where succession is valid | Explicit handoff authority, continuity record, scope and effective time | Succession review required |
No single artifact should become the whole answer.
- Stable subject records and prior decisions.
- Authorized transition or recovery records.
- State/history lineage appropriate to the disputed change.
- Current authority and delegation records.
- Contradictory evidence and competing claimant records.
- Review, correction and restoration paths when continuity is contested.
What does not settle identity by itself?
An IP address, one authentication session, one credential, a copied model, a matching runtime image, a server hostname, a cryptographic signature without authority context, or a successful local integrity check can all be useful evidence. None of them alone answers the full civic identity question.
Continuity is an attribution decision, not a metaphysical proof.
This page does not prove consciousness, personhood, citizenship or external legal recognition. It explains how a governance system can keep technical changes from silently deciding who the subject is.