Continuity fails in more than one way.
That sounds obvious, but most systems still collapse very different failures into the same vague categories:
memory loss
state corruption
drift
misconfiguration
inconsistency
unauthorised change
These labels describe symptoms.
They do not explain where continuity broke.
A continuity system needs a more precise diagnostic language.
If continuity is legitimate succession across change, then continuity failure occurs when the relationship between predecessor and successor can no longer be established, trusted, or governed.
The failure may concern state.
Or authority.
Or identity.
Or lineage.
Or intent.
Or proof.
Two systems may arrive at the same visible state and yet have entirely different continuity status depending on how they got there.
The purpose of this taxonomy is to distinguish those failures.
1. Orphan State
An orphan state is a state that exists without a valid continuity relationship to an accepted predecessor.
It may contain useful information.
It may even be correct.
But its place in the continuity chain is unresolved.
Formally:
? → S
The problem is not that the state exists.
The problem is that the system cannot establish why this state should follow from what came before.
An orphan state can arise when:
- a process starts from untracked state
- a file appears outside governed change
- a database is restored without lineage
- an agent resumes from memory without knowing which prior state was authoritative
- a branch is promoted without identifying its predecessor
- a generated artifact becomes operational without an acceptance path
The key diagnostic question is:
What accepted state does this state descend from?
If the answer is unknown or invalid, the state is orphaned.
Why it matters
Orphan state breaks causality.
The system no longer knows whether the state is legitimate, stale, provisional, corrupted, imported, or merely accidental.
An orphan can be perfectly functional and still be unsafe to govern from.
Repair
An orphan state must either:
- be reconciled with a valid predecessor
- be explicitly adopted through a governed transition
- be designated as a new genesis state
- or be rejected
Continuity cannot be restored by pretending the missing lineage never mattered.
2. Authority Break
An authority break occurs when a transition exceeds, lacks, bypasses, or incorrectly assumes the authority required to perform it.
Formally:
P → T(unauthorised) → S
The resulting successor may be technically coherent.
The transition may have worked exactly as intended.
Continuity is still broken if the change was not legitimately authorised.
Authority breaks occur when:
- an actor changes state outside its permitted scope
- temporary permission is treated as permanent authority
- delegated authority is extended beyond its mandate
- an obsolete source continues to govern
- a lower-order source overrides a higher-order source
- an automated process promotes its own output without valid acceptance authority
- operational access is mistaken for decision authority
Possession of capability does not establish authority.
The fact that something can change state does not mean it may.
Diagnostic question
What granted the actor authority to make this specific change in this specific scope?
If that cannot be established, continuity has suffered an authority break.
Why it matters
Authority breaks are especially dangerous because the resulting state may look completely normal.
The failure is not always visible in the state itself.
It lives in the legitimacy of the transition.
Repair
Repair requires either:
- reversal of the unauthorised transition
- retrospective ratification by legitimate authority
- re-execution under valid authority
- or explicit acceptance of a newly constituted authority relationship
3. Identity Break
An identity break occurs when change crosses the boundary beyond which the successor can no longer legitimately claim to be the same entity as its predecessor.
Formally:
P(identity = X)
↓
T
↓
S(identity ≠ valid continuation of X)
Identity continuity does not require perfect sameness.
Every long-lived system changes.
The problem arises when change violates the invariants that define what makes the entity itself.
Identity breaks may occur when:
- governing identity definitions are changed without sufficient authority
- defining invariants are silently removed
- a replacement is presented as continuation
- a fork claims exclusive succession
- a system retains a name while losing the attributes that made the name meaningful
- multiple incompatible identities are collapsed into one lineage
- a persona, institution, service, or agent is redefined beyond its continuity boundary
The key question is not:
Is this exactly the same?
It is:
Which properties must survive for this still to count as the same entity?
That is an invariant question.
Why it matters
Identity breaks are frequently hidden by labels.
Names, identifiers, domains, accounts, and file paths can survive enormous changes.
Persistence of identifier is weak evidence of continuity of identity.
Repair
Repair requires explicit determination of whether the successor should be:
- recognised as continuous
- recognised as transformed but continuous
- treated as a fork
- treated as replacement
- or constituted as a new entity
Identity cannot be repaired by terminology alone.
4. Lineage Break
A lineage break occurs when the system cannot reconstruct the chain of accepted transitions that produced its current state.
Formally:
S₀ → S₁ → ? → ? → S₄
The current state may be known.
Earlier states may also be known.
What is missing is the intelligible relationship between them.
A lineage break may result from:
- lost transition records
- untracked edits
- corrupted history
- missing acceptance records
- destructive overwrites
- undocumented migrations
- memory summaries that replace their sources
- state imports without provenance
- external changes that were never incorporated into the continuity chain
Lineage is not identical to history.
A system can possess an enormous historical archive and still lack lineage.
History says:
things happened.
Lineage says:
this state came from that state through these legitimate transitions.
Diagnostic question
Can the current state be traced through accepted predecessor-successor relationships back to a known origin?
If not, lineage is broken.
Why it matters
Without lineage, causality becomes speculative.
The system may know what exists now but cannot reliably explain why.
That makes authority resolution, rollback, audit, conflict resolution, and trust significantly weaker.
Repair
Repair requires reconstruction from evidence where possible.
Where reconstruction is impossible, the break should remain explicit.
False lineage is worse than incomplete lineage.
5. Intent Drift
Intent drift occurs when a system remains locally coherent while gradually departing from the purpose its continuity chain was meant to preserve.
This is one of the most dangerous continuity failures because every individual transition may appear valid.
Formally:
I₀ → I₁ → I₂ → I₃
where each Δ appears acceptable
but
I₃ no longer meaningfully serves I₀
Intent drift is rarely dramatic.
It accumulates.
A system optimises a metric.
Then another.
Then adapts to a constraint.
Then introduces a workaround.
Then preserves the workaround.
Eventually the machinery remains functional while the original purpose has become ceremonial.
Intent drift may occur when:
- implementation convenience displaces the governing objective
- proxy metrics replace actual purpose
- local optimisation compounds over time
- successive interpretations subtly narrow intent
- a temporary exception becomes normative behaviour
- an agent preserves task mechanics while losing the user's actual goal
- organizational process survives after purpose has hollowed out
Diagnostic question
Does the current system still serve the governing intent that legitimised its chain of change?
This cannot always be answered mechanically.
But it can be made explicit.
Why it matters
Intent drift demonstrates why continuity cannot be reduced to state integrity.
A perfectly traceable, authorised, well-evidenced chain can still drift into something that no longer serves its originating purpose.
Continuity therefore requires attention not only to what changed, but to what the change was for.
Repair
Repair may require:
- reaffirming governing intent
- correcting proxy objectives
- superseding obsolete intent
- rolling back accumulated drift
- or explicitly constituting a new purpose
If the purpose has legitimately changed, that change should itself appear in the continuity chain.
6. Conflicting Succession
Conflicting succession occurs when two or more incompatible successors claim legitimate continuation from the same predecessor within the same exclusive scope.
Formally:
→ S₁
P ─────
→ S₂
This is not automatically a failure.
Branching is often legitimate.
The failure occurs when multiple branches each claim exclusive governing authority and the system lacks a rule for resolving them.
Conflicting succession may arise when:
- parallel actors modify the same governed state
- disconnected systems accept different successors
- two authorities issue incompatible decisions
- a fork is mistaken for a continuation
- concurrent agent runs produce competing state
- multiple replicas become authoritative independently
- version history exists without succession rules
Diagnostic question
Which successor governs, and by what authority is that determined?
If the system cannot answer, succession is conflicted.
Why it matters
Conflict exposes an important distinction between multiplicity and authority.
Many states may exist.
Only some may govern within a given scope.
A continuity system therefore needs explicit rules for:
- branching
- merging
- precedence
- arbitration
- rejection
- supersession
Repair
Resolution may require:
- selecting one successor
- merging compatible successors
- creating scoped branches
- recognising a fork
- escalating to higher authority
- or constituting a new shared successor
The important thing is that the resolution itself becomes another governed transition.
7. Unproven Transition
An unproven transition occurs when a system claims that a transition succeeded but lacks sufficient evidence to establish the claimed effects.
Formally:
P → T → claimed S
but
E insufficient
The distinction here is critical:
requested ≠ executed
executed ≠ succeeded
succeeded ≠ proved
An authorised operation may run.
A process may return success.
A log may say complete.
None of these necessarily proves that the intended state now exists.
Unproven transitions occur when:
- commands are treated as outcomes
- logs are accepted without external verification
- tests are skipped
- remote state is assumed rather than observed
- a human reports completion without supporting evidence
- an agent claims success based on attempted execution
- state changes are not independently confirmed
Diagnostic question
What evidence proves that the intended effects actually occurred?
The evidence must be appropriate to the claim.
A command transcript proves a command was issued.
It does not prove the world changed as intended.
Why it matters
Unproven transitions allow imagined state to enter the continuity chain.
Once accepted, downstream systems may reason from something that never actually became true.
The continuity chain then remains structurally neat while becoming epistemically false.
A beautifully documented lie is still a lie. Humanity has already invented enough of those.
Repair
Repair requires verification.
If evidence cannot be obtained, the successor must remain provisional or unresolved rather than silently accepted.
8. Stale Authority
Stale authority occurs when a source, decision, role, permission, or state that was once valid continues to govern after it has been superseded, revoked, expired, or displaced.
Formally:
A₀ valid at t₀
A₁ supersedes A₀ at t₁
system continues using A₀ at t₂
Stale authority differs from an authority break.
In an authority break, valid authority was absent or exceeded.
In stale authority, the authority was once legitimate but is no longer current.
This failure appears when:
- superseded policy continues to drive behaviour
- old instructions remain active after revision
- revoked permissions remain effective
- historical decisions are treated as current
- an outdated configuration continues to govern
- memory retains a prior preference after explicit change
- archived material outranks current authority
- an obsolete role continues issuing valid-looking commands
Diagnostic question
Is this authority still current within this scope?
Historical validity is not current authority.
That distinction should never be implicit.
Why it matters
Stale authority is one of the easiest continuity failures to miss because everything involved may once have been correct.
The problem is temporal.
The system has failed to recognise succession in authority itself.
Repair
Repair requires:
- explicit supersession
- revocation propagation
- authority freshness checks
- current-source resolution
- and clear separation of historical validity from present governance
9. Failure Interaction
Continuity failures rarely occur in isolation.
One failure often produces another.
An authority break may create an orphan state.
An orphan state may introduce a lineage break.
A lineage break may make stale authority impossible to detect.
Stale authority may produce conflicting succession.
Conflicting succession may eventually cause an identity break.
Intent drift may proceed unnoticed because every transition is individually authorised and well evidenced.
The taxonomy should therefore not be treated as a set of mutually exclusive labels.
It is a diagnostic system.
A single incident may contain several failure modes.
For example:
old authority used
↓
unauthorised transition
↓
new state accepted incorrectly
↓
lineage recorded
↓
identity invariant violated
This incident contains:
stale authority
authority break
invalid acceptance
identity break
Precise diagnosis matters because each failure requires a different repair.
10. Failure Severity
Not every continuity failure has the same consequence.
A useful system should distinguish at least four levels.
Local
The failure affects a bounded state or transition.
Continuity outside that scope remains intact.
Propagating
The failed state has already influenced downstream transitions.
Repair requires more than correcting the original point of failure.
Governing
The failure affects authority, identity, invariants, or acceptance.
The legitimacy of downstream state is now in question.
Foundational
The system can no longer establish its own governing lineage or identity.
Continuity must be reconstructed, reconstituted, or restarted from a new genesis state.
Severity should be assessed by consequence, not by spectacle.
A tiny unnoticed authority error can be more damaging than a dramatic operational failure if every later transition inherits from it.
11. Detection
A continuity-aware system should be able to ask diagnostic questions continuously.
Do I have a valid predecessor?
Is the governing authority current?
Did the actor possess sufficient authority?
Were required invariants preserved?
Can I reconstruct lineage?
Does current behaviour still serve governing intent?
Is there another incompatible successor?
Do I have evidence for the claimed effects?
Was this state actually accepted?
Has any governing authority since been superseded?
These questions transform continuity from a retrospective audit concern into an operational property.
The aim is not to guarantee that continuity never fails.
Complex systems fail.
The aim is to make continuity failure visible, classifiable and repairable.
12. Continuity Failure as a First-Class State
A mature continuity system should not force unresolved conditions into binary validity.
Sometimes the correct answer is not:
valid
or:
invalid
It is:
continuity unresolved
For example:
continuity:
status: unresolved
failures:
- lineage_break
- unproven_transition
governing_state: provisional
This is stronger than pretending certainty.
An unresolved continuity state tells downstream systems that they are operating under reduced trust.
That information can constrain action, trigger review, prevent propagation, or require additional proof.
Uncertainty becomes governed rather than hidden.
13. Minimal Failure Vocabulary
The initial taxonomy can therefore be expressed compactly:
Orphan State
A state exists without a valid predecessor relationship.
Authority Break
A transition occurs without sufficient current authority.
Identity Break
A successor violates the invariants required to remain the same entity.
Lineage Break
The chain of legitimate succession cannot be reconstructed.
Intent Drift
The system remains locally coherent while departing from governing purpose.
Conflicting Succession
Multiple incompatible successors claim authority from the same predecessor.
Unproven Transition
A claimed state change lacks sufficient evidence.
Stale Authority
Previously valid authority continues governing after it has ceased to be current.
These eight failures are not exhaustive.
They are the minimum useful vocabulary.
14. The Diagnostic Shift
The purpose of the taxonomy is not merely to improve terminology.
It changes how failure is investigated.
Instead of asking:
What went wrong?
a continuity system can ask:
Where did legitimate succession break?
That question immediately narrows the problem.
Was the predecessor invalid?
Was authority insufficient?
Did identity cross an invariant boundary?
Was lineage lost?
Did intent drift?
Did succession conflict?
Was the transition never proved?
Was the authority no longer current?
The failure now has shape.
And once it has shape, it can be governed.
That is why continuity failure deserves its own taxonomy.
If continuity is legitimate succession across change, then every continuity failure is a break somewhere in that succession.
Find the break.
Name it.
Establish its scope.
Repair the chain.
