Semantic planes

A plane is a unit of responsibility — a class of decision rather than a process or a server. It owns one class of decision — admission, a secret-dependent transition, disclosure, recovery — and it names the normative artifacts that record that decision. Because every plane is verifiable from its own inputs and artifacts, every denied or failed operation is attributable to the plane that decided, the reason code it emitted, and the artifact that records the decision.

The line between the external execution contour and the secret kernel is at once an engineering interface and a formal trust boundary. The secret-execution plane runs a local step only after canonical-context and admission checks pass; admission, choreography, transport, and publication stay auditable on the outer side.

Level 1 — cryptographic execution: the secret-execution plane (shares, nonces, presign, permits, secret log), the DVM-execution plane (distributed trace, phases, slots, PendingRemote, replay-safe merge), the network plane (envelope admissibility, replay defense, equivocation evidence), and the crypto-profile plane (protocol form, provider ABI, backend limits, test vectors).

Level 2 — the v1 control core: configuration & epochs (DomainManifest, active epoch, policy and profile roots), policy & admission (normalized intent to AdmissionDecision), recovery (resume after fault, Poisoned and conflict handling), publication (Executed to Published behind a gate), and audit & evidence (a proof shape for every transition).

Level 3 — operation closure and external effect: authority and permission administration, assumptions-and-controls, display & approval binding, external publication to a rail, settlement & verification, and the trust / continuity / operational-risk planes (key provenance, software identity, DR, safe mode).

Two planes run across the others. The Audit & Evidence plane records every transition, denial, recovery, equivocation, and publication as a proof artifact and a SIEM export; evidence is emitted as each transition commits. Assumptions & Controls maps each formal security assumption to a concrete detecting control, so monitoring and alerting become a cross-plane function, and operational risk lifts backpressure, limits, presign-pool depletion, and safe-mode into explicit operational decisions.

Because each material transition has exactly one owning plane, API status gains precise meaning: PendingRemote is the network plane waiting on a peer fact, PUBLICATION_DENIED is the publication plane rejecting a disclosure, STEP_PERMIT_REUSED is the secret plane refusing a replayed permit. Each status routes to its owning plane.

Because transitions are pure (Sans-I/O), the same plane decomposition is traceable: an operator can step one operation plane-by-plane in the debugger, with execution and publication kept as separate states that carry their own receipts.

DVM uses two plane decompositions, and they answer different questions. The fifteen responsibility planes on this page partition operational ownership: who owns a class of decision, and which artifact records it. The eleven effect planes in the instruction-semantics model partition what a single bytecode instruction touches: every instruction site declares which planes it reads and writes, with preconditions, postconditions, visibility, and audit obligations per plane.

The two views are linked, not redundant. A responsibility plane is operated by people and policy over months; an effect plane is crossed by an instruction in milliseconds. The mapping is fixed: the policy & admission responsibility plane governs what instructions see on the policy and resource effect planes; the publication responsibility plane owns the publication and artifact effect planes; audit & evidence owns the evidence and audit effect planes; configuration & epochs and authority govern the governance effect plane. When a review question is 'who decided', use the responsibility planes; when it is 'what can this instruction do', use the effect planes.