DVM governance plane

The two DVM layers are scoped differently and should not be collapsed. A DVM execution session is execution_id-scoped: it records one cryptographic computation with a trace root and terminates. DVM governance is cluster_id / key_epoch-scoped: it answers which key, roster, policy epoch, and recovery authority are allowed to exist before and after that session.

The DVM governance plane is event-sourced rather than a single state machine. Cluster state is four orthogonal projections — epoch, key lineage, roster health, incident — each derived independently from the same hash-linked event log. A cluster can hold an Active key, a Degraded roster, and no incident at once; enumerating that as one FSM would be intractable.

• DVM execution is scoped to execution_id and milliseconds; DVM governance to cluster_id/key_epoch and months.
• Cluster state is a derived projection of a typed event log.
• Removing the L3 event log does not change any DVM execution trace.

DKG completion and key activation are two distinct committed facts, separated by the publication barrier. The DVM keygen session terminates at publish_pubkey, producing a key_ready_cid and a publication receipt; the DVM governance plane records KeyObjectPublished — the key now exists as a cryptographic fact. Activation is a separate governance decision: KeyActivated is written only after a quorum signs off, and only then is the key the signing authority.

Generated is cryptographic; Activated is governance. Merging them would let a key silently become the signing authority as a side effect of DKG completing, with no explicit governance action.

• Generated is cryptographic. Activated is governance.
• KeyActivated must reference a key_ready_cid from DVM publish_pubkey.
• DvmWorkflowStarted → PublishedArtifactBound → KeyObjectPublished → KeyActivated.

Heartbeat loss, equivocation reports, and incident signals are observations, not authority decisions. An ObservationRecorded event is a committed input to the reducer — it does not by itself change key, roster, epoch, or incident state. A separate policy-gated transition decides whether an observation warrants freezing a node, declaring Degraded, or entering an emergency.

This separation keeps the authority state clean: an attacker who can forge or flood observations still cannot move the cluster's authority state without passing the governance policy that consumes those observations.

• ObservationRecorded is committed input to the reducer; a separate policy-gated transition changes authority state.
• NodeHeartbeatTimeout and NodeEquivocation are observations until governance acts on them.
• Degraded and Compromised are derived projections of the event log.

Every cluster event carries two independent signatures that answer different questions. A TransitionAuthorization (typically a GovernanceDecision from the PolicyAuthoritySet) answers 'is this transition allowed?'. An AppendCertificate answers 'is this event the next canonical fact in the log?'. A valid authorization to rotate does not by itself make a given event the canonical next entry — and a fork in the log is a different failure than an unauthorized transition.

The event body is hashed and signed separately from the envelope, so event_root never has to reference itself. Two valid AppendCertificates for the same log position produce ForkEvidence — conflict creates a durable artifact rather than a silent last-writer-wins.

• TransitionAuthorization: why the transition is allowed (GovernanceDecision).
• AppendCertificate: why this is the next canonical event (log quorum / committer).
• Conflicting append certificates create ForkEvidence.

The DVM governance plane cannot manufacture cryptographic truth. For every event that changes externally visible cryptographic authority, there must exist a DVM/publication artifact it references, and the event cannot create a stronger public observation than that artifact permits. DVM governance can authorize, sequence, and journal — it cannot publish.

This is the L3 Conservativity invariant, and it is what keeps the layer from becoming an ambiguous super-authority above DVM. The audit trail is anchored externally: after each committed transition, a checkpoint is written and anchored to WORM storage — a cloud immutable object store in SaaS, a hardware WORM appliance or self-hosted transparency log on-prem — so an auditor can verify any event independently.

• Forbidden: KeyActivated without KeyReady + publication receipt.
• Forbidden: SignaturePublished without publish_sig; XPubPublished without publish_xpub.
• Checkpoints are WORM-anchored for independent external audit (cloud immutable store in SaaS; hardware WORM appliance or private Rekor on-prem).