Assurance board
Operational invariants
The assurance claim is the invariant set. These are the irreducible invariants — properties no deployment profile is allowed to weaken. Each one names a prohibited failure class, the plane responsible for detecting it, the reason code it raises, and the artifact that records it. The board below is the consolidated assurance surface, cross-referencing every claim to its proof.
BINDING_MISMATCH / REPLAY_OR_CONFLICTsigned envelope + binding hashnew frame onlyno observable type carries a secretopaque handles + secret logdesign invariantSTEP_PERMIT_REUSEDpermit event + poisoned artifact refabort or quarantineSPLIT_BRAIN_FENCEDfencing record + node passportrebind after fenceEQUIVOCATIONequivocation evidence + Abortoperator reviewREMOTE_TIMEOUTpending event + deadlinepoll, resume, or retry transportPUBLICATION_DENIEDPublicationReceipt / denial evidenceafter policy changeSTALE_EPOCHDomainManifest + epoch evidencerebind operationexplicit ingress / egress eventsevent trace + statusn/ano TransitionAuthorized without threshold-signed GovernanceDecisionGovernanceDecision CID in cluster eventceremony + quorum re-signKeyActivated requires prior KeyObjectPublished with key_ready_cidartifact_refs binding in ClusterEventDKG must complete and publish before activationPolicyReceipt never appears in cluster event logGovernanceDecision used externally; PolicyReceipt stays localdesign invariantThe irreducible invariants
Nine invariants hold across every layer and profile. One owner per node and a single active instance — a node_id binds one secret kernel, and concurrent instances or split-brain are protocol violations. Secrets stay local — shares, nonces, presign, and private inputs never leave the kernel in any observable type. Ingress is validated before it becomes a DVM fact, and step permits are one-shot.
PendingRemote is an explicit, normal state. Inter-node exchange is always observable as ingress/egress events. Conflict produces verifiable evidence and does not trigger last-writer-wins recovery. Publication status arises only after a separate, verifiable publication step. Node-set, threshold, policy, and crypto-profile change only through a gated epoch transition.
What the invariants forbid
The invariant set is the complement of the threat model. Five events are categorically forbidden: a leak of key shares or one-shot secret artifacts, tampering with active policy, a break in the integrity of the transition log, an admission bypass at result publication, and the loss of verifiability of an operation's terminal outcome. Every invariant exists to make one of these detectable and attributable rather than silent.
The peer is split into two components for the same reason. The secret kernel keeps a minimal, heavily audited API that changes rarely; the DVM runtime — which affects liveness rather than secret confidentiality — evolves more often while the trust boundary holds.
What evidence proves
Each terminal receipt points to the invariant that mattered for that closing state. A publication denial proves the no-silent-publication invariant; a reused permit proves the one-shot step-permit invariant; an equivocation record proves the conflict-creates-evidence invariant. Review becomes concrete: invariant, owning plane, recording artifact, and reason code — every row of the board is a claim with a receipt behind it.