# A Taxonomy of Continuity Failure **Sean Manouge** **22 September 2026** 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: ```text ? → 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: ```text 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: ```text 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: ```text 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: ```text 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: ```text → 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: ```text P → T → claimed S but E insufficient ``` The distinction here is critical: ```text 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: ```text 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: ```text old authority used ↓ unauthorised transition ↓ new state accepted incorrectly ↓ lineage recorded ↓ identity invariant violated ``` This incident contains: ```text 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. ```text 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: ```text valid ``` or: ```text invalid ``` It is: ```text continuity unresolved ``` For example: ```yaml 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.