Governance continuity

Concept

Governance continuity

Disaster recovery answers "are the machines back?". Continuity answers a different question: can governance continue, and can you show it? A restored host that cannot evaluate policy, cannot resolve authority, and cannot extend its receipt chain is not recovered — it is merely running.

The Recovery Point

A Recovery Point records the governance state a workspace can resume from. It names five things:

  • the policy bundle in force
  • the authority frame version
  • the identity version
  • the head of the receipt chain
  • a digest of locally-resolvable governance configuration

It is derived state. It identifies those artifacts and contains none of them — no policy text, no key material, no receipt bodies. Deleting every Recovery Point you hold loses no governance and destroys no evidence; you can mint a fresh one from the workspace at any time. That is also why a Recovery Point is safe to email to an auditor or ship into your own SIEM.

Each point carries a deterministic identity digest over the five references, and a signed envelope with the timestamp, provenance, and the device key that observed it. Two captures of an unchanged workspace produce the same identity digest, so a long capture history collapses to a short list of distinct states.

Trust Recovery

Verification returns a state, never a score. Either recoverability is Complete, or it is Incomplete and every unverified component is named. There is no percentage and no grade, because a governance system that is 80% recoverable is not 80% governed — it is ungoverned in a way you have not located yet.

Restore is all-or-nothing for the same reason: every component must verify before governance resumes. Run the check in the app under Operations → Continuity, or offline against an exported file:

aarmos grp create
aarmos grp list
aarmos restore --from recovery-point-<digest>.json

When points are captured

You can capture one by hand at any time. Aarmos also captures one immediately before and immediately after every applied Change Set, so each governance transition is bracketed by the state on either side of it. Capture failures never block a change — a Recovery Point is an observation, not a gate.

You own the backup

Continuity does not depend on our cloud. Export a single point as JSON, or the whole history as newline-delimited JSON, and keep it wherever you keep operational records. Recovery Points also appear in the audit export stream as continuity events, so a workspace already forwarding audit data to a SIEM gets continuity history there with no extra configuration.

Honest limits

  • A Recovery Point proves a state was observed and signed. It does not store the artifacts, so restoring still requires the policy bundle, keys, and receipts you kept.
  • The configuration digest covers locally-resolvable governance configuration only. Anything resolved from an external system at run time is outside it.
  • Replay determinism is asserted against the same verified receipt chain — a chain that verifies can be re-executed step for step. We claim nothing beyond that.

Related: evidence and receipts · SIEM export