1. Purpose
The Continuity State Schema defines the minimum live state required for a system to determine its current continuity condition.
A Continuity Receipt explains how one accepted state became the successor of another.
The Continuity State Schema answers a different question:
What is the system's continuity position now?
It represents the current operational truth of continuity within a defined scope.
At minimum, a continuity-aware system should be able to expose:
- what state currently governs
- what predecessor that state succeeded
- what authority currently governs
- which invariants currently apply
- what intent is being preserved
- what transition was last accepted
- what evidence supports current continuity
- whether unresolved failures exist
- whether competing successors exist
- what continuity actions are currently permitted
The schema therefore describes continuity state, not system state in general.
2. Core Distinction
System state answers:
What is true now?
Continuity state answers:
Why is this the governing truth now, and under what conditions may it change?
These are related but not equivalent.
3. Continuity State Object
The canonical top-level object is:
continuity_state:
A complete v0.1 state contains:
identity
scope
current
predecessor
authority
invariants
intent
last_transition
evidence
acceptance
lineage
conflicts
failures
constraints
next
status
Not every implementation must persist these fields in one physical record.
They must, however, be resolvable as one coherent continuity state.
4. Identity
The identity section identifies the entity whose continuity is being evaluated.
A continuity object without explicit identity risks proving the continuity of nothing in particular.
5. Scope
The scope section identifies the domain within which the continuity claim applies.
A system may be continuous operationally while discontinuous institutionally.
It may preserve identity while replacing implementation.
It may preserve data while losing authority.
The schema must not collapse these into one undifferentiated boolean.
6. Current State
The current section identifies the accepted state that presently governs.
The current state must be the latest accepted governing state within the specified scope.
It must not refer to the newest created state, newest modified state, newest candidate, unaccepted branch, remembered approximation, or provisional successor unless provisional governance is explicitly permitted.
The current state is a governance claim.
It therefore requires more than recency.
7. Predecessor
The predecessor section identifies the accepted state immediately preceding the current state.
Where the current state is a genesis state, the absence of a predecessor must be explicit.
A missing value and a legitimate genesis are not the same condition.
8. Governing Receipt
The current state should identify the receipt that established its accepted succession.
That receipt provides the compact proof of how the current state became authoritative.
A current non-genesis state without a governing receipt should be treated as continuity-unresolved unless an equivalent proof object exists.
9. Authority
The authority section identifies what currently governs changes within the scope.
Authority state must answer:
- what currently governs
- who currently holds relevant authority
- what scope that authority covers
- whether it remains current
- what, if anything, it superseded
This section is essential for detecting stale authority.
10. Invariants
The invariants section identifies the continuity conditions that currently constrain valid succession.
An invariant whose authority or applicability cannot be resolved should not silently disappear.
It should appear as unresolved.
11. Intent
The intent section identifies the governing purpose continuity is meant to preserve.
Not every low-level system requires a philosophical manifesto stapled to each state transition.
But long-lived systems involving governance, autonomy, institutions, identity, or delegated action require an explicit account of what their continuity is for.
Intent is especially important for detecting drift.
12. Last Accepted Transition
The last_transition section identifies the transition that produced the current state.
This allows the live continuity state to expose its most recent act of succession without requiring traversal of the full history.
13. Evidence
The evidence section identifies the proof currently supporting the continuity claim.
Evidence itself can become stale.
A continuity-aware runtime should therefore distinguish between evidence that once existed and evidence that still supports the current claim.
14. Acceptance
The acceptance section records the acceptance status of the current state.
A live continuity state should never require downstream systems to infer whether current state is truly governing.
Acceptance must be explicit.
15. Lineage
The lineage section summarises the system's ability to reconstruct its continuity chain.
Suggested statuses:
intact
partial
broken
unresolved
A lineage status of broken or unresolved should materially affect overall continuity status.
16. Conflicts
The conflicts section identifies competing continuity claims.
The presence of multiple successor states is not automatically a conflict.
Conflict exists when incompatible successors claim governance over the same relevant scope.
17. Failures
The failures section exposes active continuity failures.
Possible classes include:
orphan_state
authority_break
identity_break
lineage_break
intent_drift
conflicting_succession
unproven_transition
stale_authority
Historical failures should not necessarily remain active.
The schema should distinguish active from resolved failures.
18. Constraints
The constraints section identifies restrictions imposed by the current continuity state.
Possible action policies include:
normal
restricted
read_only
provisional
halted
Continuity status should have operational consequences.
A runtime that detects broken authority and continues behaving identically has not really detected anything useful.
19. Next
The next section identifies what continuity operations are currently legitimate.
It answers:
Given the continuity condition now, what may happen next?
This turns the schema into an operational control surface.
20. Overall Status
The status section summarises the current continuity determination.
Suggested continuity states:
valid
provisional
unresolved
invalid
revoked
Suggested confidence states:
established
partial
weak
unknown
Status is a summary.
It must never replace the underlying reasons.
21. Minimal Schema
continuity_state:
identity:
id: service-alpha
scope:
id: production-runtime
current:
id: STATE-0042
governing_receipt: CR-0042
predecessor:
id: STATE-0041
authority:
source: POLICY-003
status: current
invariants:
active:
- service_identity
- audit_lineage
intent:
governing: maintain reliable public service
last_transition:
id: T-0042
evidence:
status: verified
acceptance:
status: accepted
lineage:
status: intact
conflicts:
active: []
failures:
active: []
constraints:
action_policy: normal
next:
permitted:
- propose_transition
status:
continuity: valid
This is enough for a system to answer the essential continuity questions without traversing its full history.
22. Canonical Full Form
A full implementation may extend the minimal schema with explicit references, digests, authority holders, freshness checks, evidence identifiers, acceptance conditions, chain depth, conflict records, resolved failures, blocked actions and confidence state.
23. State Derivation
Continuity State should be derived from authoritative continuity records, not maintained as an independent competing source of truth.
Conceptually:
ACCEPTED STATES
+
CONTINUITY RECEIPTS
+
CURRENT AUTHORITY
+
ACTIVE INVARIANTS
+
FAILURE / CONFLICT STATE
↓
CONTINUITY STATE
If it becomes another manually maintained authoritative record, the continuity system creates precisely the reconciliation problem it was meant to solve.
The derived state may be cached.
It must remain reproducible from authoritative sources.
24. Freshness
Continuity state is time-sensitive.
Authority can expire.
Evidence can become contradicted.
Conflicts can emerge.
Receipts can be revoked.
Intent can be superseded.
The schema should therefore include a freshness boundary.
A system should distinguish:
valid when checked
from:
guaranteed valid forever
The latter is generally fiction with nicer typography.
25. Invalid State
Invalid continuity does not require unknown state.
The system may know exactly what happened.
It simply knows that the succession was illegitimate.
26. Unresolved State
An unresolved state is different.
It preserves uncertainty rather than manufacturing a decision.
That is a feature.
Not knowing is sometimes the most accurate state available.
27. Provisional State
A provisional continuity state permits bounded operation before full acceptance.
Provisional state must remain visibly different from accepted state.
Temporary convenience must not silently mature into authority.
28. Multiple Scopes
A system may expose multiple continuity states simultaneously.
For example:
operational: valid
identity: valid
authority: unresolved
institutional: valid
The combined system status may then be governed by explicit policy.
Different systems may assign different criticality to different scopes.
The aggregation rules must be explicit.
29. State Transitions
Continuity State changes when a continuity-relevant event occurs.
Examples include:
successor accepted
authority superseded
receipt revoked
invariant changed
evidence contradicted
conflict detected
conflict resolved
intent superseded
lineage reconstructed
failure repaired
The continuity state should therefore be understood as a live projection over the continuity chain.
It is not itself the chain.
30. Query Surface
A continuity-aware runtime should be able to answer at least:
What state currently governs?
What was its predecessor?
What receipt established succession?
What authority currently governs?
Is that authority current?
What invariants must be preserved?
What governing intent applies?
What transition produced the current state?
Is the evidence sufficient?
Is lineage intact?
Are there conflicting successors?
Are there active continuity failures?
What actions are constrained?
What is permitted next?
What is the current continuity status?
These questions constitute the minimum useful operational interface for continuity.
31. Continuity State Invariants
Current means accepted
The newest state is not necessarily the current state.
Authority must be fresh
Previously valid authority is insufficient.
Invariants remain explicit
Required continuity conditions must not be inferred from convention alone.
Failures remain visible
Known continuity failures must not disappear merely because operation continues.
Uncertainty remains explicit
Unknown and unresolved conditions must not be silently converted to valid state.
Constraints follow status
Continuity failure must have operational consequences where relevant.
Derived views do not become accidental authority
Continuity State should remain reproducible from authoritative records.
Scope is mandatory
Continuity claims must state what they apply to.
32. The State Rule
The schema reduces to one requirement:
At any moment, a continuity-aware system should be able to explain what governs now, why it governs, what must remain true, what uncertainty exists, and what may legitimately happen next.
That is the purpose of Continuity State.
The Continuity Model defines legitimate succession.
The Continuity Protocol governs the transition.
The Continuity Receipt proves the accepted succession.
The Continuity State Schema exposes the resulting condition now.
Together, they allow continuity to exist not merely as historical interpretation, but as an active systems property.
Continuity is legitimate succession across change.
