# Continuity State Schema v0.1 **Sean Manouge** **22 September 2026** ## 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: ```yaml continuity_state: ``` A complete v0.1 state contains: ```text 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: ```text 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: ```text 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: ```text 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: ```text valid provisional unresolved invalid revoked ``` Suggested confidence states: ```text established partial weak unknown ``` Status is a summary. It must never replace the underlying reasons. --- # 21. Minimal Schema ```yaml 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: ```text 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: ```text valid when checked ``` from: ```text 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: ```text 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: ```text 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: ```text 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.**