1. Purpose
The Continuity Protocol defines a minimum procedure for establishing whether a proposed successor state may legitimately become the governing continuation of an accepted predecessor state.
It operationalises the Continuity Model.
The protocol is designed around one rule:
No successor becomes governing state unless its succession from the accepted predecessor can be justified through authority, invariants, effects, evidence and acceptance.
The protocol does not assume that every transition will succeed.
It assumes that every consequential transition should leave enough structure behind to determine:
- what changed
- why it changed
- who or what authorised it
- what had to remain true
- what effects actually occurred
- what evidence supports those effects
- whether the result was accepted
- whether continuity remains valid
The protocol therefore governs not merely change, but legitimate succession through change.
2. Protocol Overview
A continuity transition proceeds through seven stages:
Observe → Resolve → Propose → Act → Prove → Accept → Link
OBSERVE
↓
RESOLVE
↓
PROPOSE
↓
ACT
↓
PROVE
↓
ACCEPT
↓
LINK
Each stage answers a different question.
Observe — What is the current accepted state?
Resolve — What authority, scope and invariants govern this transition?
Propose — What is intended to change?
Act — What transition is actually performed?
Prove — What effects occurred, and what evidence supports them?
Accept — May the resulting state become governing?
Link — How is the successor connected to the predecessor in the continuity chain?
A system may implement these stages manually, automatically, or through a combination of both.
The sequence matters more than the implementation.
3. Protocol Preconditions
A continuity transition should not begin until the system can establish, at minimum:
current predecessor
current scope
current governing authority
applicable invariants
proposed actor
proposed intent
If any of these are unknown, the transition enters an unresolved continuity state.
That does not always require all activity to stop.
It does require the uncertainty to remain explicit.
The protocol must never convert unknown continuity conditions into assumed validity merely to preserve operational momentum.
Convenience is not evidence.
4. Stage One: Observe
The first stage establishes the actual current condition of the system.
The system identifies:
- the accepted predecessor
- the current state within scope
- known outstanding transitions
- relevant historical context
- active continuity warnings
- unresolved conflicts
- current external conditions that materially affect the transition
The governing question is:
What is true before anything changes?
The observation stage must distinguish between:
claimed state
observed state
accepted state
These may differ.
If no valid predecessor can be established, the protocol detects an orphan state or lineage break before proceeding.
5. Stage Two: Resolve
The resolution stage determines what governs the proposed transition.
It identifies:
- authority source
- actor
- scope
- permissions
- limitations
- applicable invariants
- precedence relationships
- superseded authority
- unresolved authority conflicts
The governing question is:
What rules this change?
Authority must be resolved against the actual proposed transition.
If authority is insufficient, the transition must not silently proceed.
If authority is ambiguous, continuity remains unresolved.
This stage prevents stale authority and authority breaks from being disguised as ordinary execution.
6. Stage Three: Propose
The proposal stage states what is intended to change before the change occurs.
The proposal must identify:
- predecessor
- actor
- intent
- scope
- proposed operations
- expected effects
- affected invariants
- acceptance requirements
- verification requirements
The governing question is:
What successor are we attempting to create?
The proposal should be explicit enough that success and failure can later be distinguished.
A vague proposal produces weak continuity because the system cannot later determine whether the intended transition occurred.
7. Stage Four: Act
The action stage performs the authorised transition.
The governing question is:
What was actually done?
The protocol records:
- operation performed
- actor or process
- execution time
- execution environment
- parameters
- intermediate failures
- retries
- external systems affected
- deviations from proposal
The action record must distinguish between:
attempted
executed
completed
The action stage does not determine whether the successor is valid.
It records execution.
Acceptance comes later.
This distinction prevents action from granting itself authority.
8. Stage Five: Prove
The proof stage determines what actually changed.
It compares:
expected effects
vs
observed effects
The governing question is:
What evidence establishes the resulting state?
The system collects evidence appropriate to each relevant claim.
The protocol must not treat the execution record as sufficient proof unless the execution itself establishes the relevant claim.
A command invocation proves invocation.
A write acknowledgment proves acknowledgment.
A health check proves only what that health check actually observes.
Evidence should be matched to the claim it supports.
Proof states
A transition may be:
proved
partially proved
unproved
contradicted
A partially proved transition must not be promoted as fully established.
9. Stage Six: Accept
Acceptance determines whether the candidate successor becomes governing state.
The governing question is:
May this state now replace the predecessor?
Acceptance evaluates:
- authority validity
- invariant preservation
- observed effects
- evidence sufficiency
- unresolved deviations
- competing successors
- acceptance authority
- transition scope
Possible outcomes include:
accepted
accepted_with_conditions
rejected
provisional
unresolved
Only accepted state becomes the default governing predecessor for subsequent transitions within the same scope.
A provisional state may be used under explicitly constrained conditions but must not silently become canonical.
A rejected state remains historical evidence of an attempted transition.
It does not become part of the accepted continuity chain.
10. Stage Seven: Link
The final stage records the accepted succession relationship.
The governing question is:
How does the successor inherit from the predecessor?
The protocol creates an explicit lineage link:
P → T → S
along with references to:
authority
invariants
effects
evidence
acceptance
Once linked, the successor becomes the accepted predecessor for the next relevant transition.
The previous state remains historically valid.
It simply no longer governs where succession has occurred.
11. The Continuity Gate
The protocol may be expressed as a continuity gate.
A successor passes the gate only when:
predecessor valid
AND
authority sufficient
AND
invariants preserved
AND
effects observed
AND
evidence sufficient
AND
acceptance valid
The gate need not always block execution.
Some systems may permit speculative or provisional work.
But the gate must control promotion into governing state.
That is the critical distinction.
12. Protocol Outcomes
Every transition should terminate in an explicit continuity outcome.
Valid
The successor is accepted and continuity is preserved.
Invalid
The transition violates continuity requirements.
Unresolved
Continuity cannot yet be established.
Provisional
The state may be used temporarily under explicit constraints.
The protocol should prefer an honest unresolved state over manufactured certainty.
13. Failure Handling
When a continuity failure is detected, the protocol should classify it before attempting repair.
Initial failure classes:
ORPHAN STATE
AUTHORITY BREAK
IDENTITY BREAK
LINEAGE BREAK
INTENT DRIFT
CONFLICTING SUCCESSION
UNPROVEN TRANSITION
STALE AUTHORITY
The stage at which the failure appears is useful diagnostic information.
A failure should be repaired at the layer where it occurred.
14. Repair Procedure
Repair is itself a continuity transition.
The system must not repair continuity by bypassing continuity.
A repair therefore follows the same protocol:
observe failure
resolve repair authority
propose repair
act
prove repair
accept repaired state
link repaired succession
Possible repairs include:
- restoring a valid predecessor
- reconstructing lineage
- obtaining valid authority
- ratifying an otherwise legitimate state
- revoking an invalid successor
- re-running verification
- resolving conflicting branches
- reasserting governing intent
- creating a new genesis state where continuity cannot be restored
A new genesis state should be used only when legitimate succession cannot reasonably be reconstructed.
It represents reconstitution, not repair.
15. Conflicting Succession
Where multiple candidate successors exist, none should silently dominate merely because it arrived first.
The protocol should identify:
common predecessor
candidate successors
scope overlap
authority of each candidate
acceptance status
merge compatibility
Possible resolutions include:
select
merge
scope
fork
reject
escalate
The resolution itself must be authorised and recorded as a continuity event.
16. Authority Freshness
Because authority changes over time, authority resolution must include freshness.
A valid protocol implementation should ask:
Was this authority ever valid?
Is it valid now?
Has it been superseded?
Has it expired?
Has it been revoked?
Does it apply to this scope?
An authority reference without temporal validity is incomplete.
This prevents historical legitimacy from being mistaken for current authority.
17. Invariant Handling
Before action, each relevant invariant should be classified as:
must preserve
may modify with authority
not applicable
After action, it should be evaluated as:
preserved
modified legitimately
violated
unresolved
A successor cannot be accepted if a mandatory invariant is violated unless the invariant itself has first been legitimately superseded.
18. Intent Check
Before acceptance, the protocol should compare the resulting state against governing intent.
The governing question is:
Did this transition preserve the purpose that justified it?
This check is deliberately separate from invariant checking.
A transition can satisfy every formal invariant and still contribute to intent drift.
Intent should be superseded explicitly, never by accumulation of convenience.
19. Continuity Receipt
Every accepted transition should produce a Continuity Receipt.
The receipt provides a compact representation of legitimate succession.
The receipt is not the full history.
It is a portable proof of the relationship between predecessor and successor.
20. Minimal Implementation
A minimal continuity implementation requires only four durable records:
STATE
TRANSITION
AUTHORITY
RECEIPT
with references sufficient to reconstruct:
predecessor
→ authorised transition
→ observed effects
→ evidence
→ acceptance
→ successor
This can be implemented in files, a relational database, an append-only log, a version-control system, an event store, a cryptographic ledger, or a distributed system.
The storage mechanism does not define continuity.
The relationships do.
21. Protocol Invariants
The protocol itself should preserve several invariants.
No silent promotion
A candidate successor must not become governing state merely because it exists.
No silent authority
Capability, access or execution must not be interpreted as authority.
No silent success
Attempted action must not be interpreted as proved effect.
No silent supersession
Historical state must not lose or gain authority without an explicit transition.
No silent certainty
Unknown continuity conditions must remain visible as unresolved.
No silent identity replacement
A successor that violates identity-defining invariants must not claim continuity without explicit reconstitution.
These invariants protect the continuity system from becoming another source of continuity failure.
22. Reference Procedure
The full protocol can be expressed as:
1. OBSERVE
Establish accepted predecessor and actual current state.
2. RESOLVE
Establish governing authority, scope and invariants.
3. PROPOSE
Define intended transition and expected effects.
4. ACT
Perform the authorised transition.
5. PROVE
Observe actual effects and collect sufficient evidence.
6. ACCEPT
Determine whether the candidate successor may govern.
7. LINK
Record successor lineage and issue continuity receipt.
Or more compactly:
Observe what is. Resolve what governs. Propose what changes. Act within authority. Prove what happened. Accept what may govern. Link what follows.
That is the Continuity Protocol.
It converts continuity from assumption into procedure.
It does not guarantee that systems remain unchanged.
It guarantees something more useful:
that change can be examined as succession.
that authority can be distinguished from capability.
that action can be distinguished from effect.
that state can be distinguished from legitimacy.
that history can be distinguished from lineage.
and that the thing which exists now can explain why it is entitled to follow from the thing that existed before.
Continuity is legitimate succession across change.
