Policy admission

The admission plane normalizes the client's intent into a canonical operation form, then evaluates it against the active policy. A policy evaluation covers: actor identity and role binding, approval chain (was a required co-approver present?), rate and velocity limits, account binding and balance checks, display hash binding (what the approver saw matches the payload), epoch validity, and roster membership. Each field is checked against values committed into the DomainManifest — the policy roots hash those values.

The result is one of three outcomes: POLICY_DENIED with a stable reason code; PendingApproval when a required approval has not yet arrived; or an AdmissionDecision that admits the operation into execution. The AdmissionDecision is signed by the admitting node, carries a policy receipt id, and is stored durably so the kernel can verify it at each secret step.

The DomainManifest does not store policy rules — it stores policy roots: hash commitments to the active policy bundle. The actual rules live in the policy bundle that the admitting node evaluates. The root in the manifest is what the kernel checks at step time: it verifies that the AdmissionDecision was produced under the currently active policy root, not a stale or replaced one.

This separation means the policy plane can evolve rules without touching the kernel. A policy bundle update goes through the authority plane as a governance operation: the new bundle is admitted under the current policy, executed, and published as a PolicyChangeReceipt. Once committed, the new policy root is recorded in the next DomainManifest epoch and takes effect for subsequently admitted operations. In-flight operations carry the root that admitted them.

On the mobile SDK, the DvmPolicyProvider interface is the integration point between the app's business logic and the DVM admission layer. The SDK calls evaluatePolicy(operation) before submitting the operation to the runtime. The provider receives a normalized operation description (type, amount, destination, display hash, actor) and returns a policy decision: approved, denied, or pending approval.

The provider is also where multi-party approval flows live on the client side. If the app requires a second factor, a co-approver signature, or a step-up authentication, the provider implements that logic and returns the resulting approval credentials as part of the decision. The sdk.updatePolicyProvider(_:) method lets the app swap in a higher-privilege provider mid-session (for example, after a biometric authentication that unlocks higher transfer limits) without re-opening the bridge.

A policy root change is a governance operation. It requires the same quorum endorsement and receipt-bearing flow as any other authority transition. The process: draft the new policy bundle offline, submit a GovernanceChangeRequest naming the new bundle hash, collect the required approval signatures, admit and execute the governance operation, and receive a PolicyChangeReceipt that records the old root, the new root, the endorsing quorum, and the transition timestamp.

The new root takes effect in the next epoch. Until that epoch commits, the old root is still active. The transition is atomic from the cluster's perspective: there is no window where some nodes use the new root and others use the old one within the same epoch. A BreakGlassReceipt is available for emergency policy changes that require a higher-threshold quorum and produce a separately labeled, auditable record.

The external admission contour performs the full evaluation — actor checks, approvals, limits, risk scoring, intent normalization — and emits a signed AdmissionDecision. The kernel performs no second policy evaluation. Its local check is scoped to six context fields: the step permit must match the active epoch, the signed decision, this key, this session, this phase, and this slot. It enforces context correctness; policy correctness is established at admission.

This separation is a design rule. The kernel API changes rarely; the policy plane evolves with product requirements. Keeping policy outside the kernel means new admission rules, approval types, and rate limits leave the most security-critical component untouched. The kernel's invariant is stable: it proceeds when the step permit matches the active context, and otherwise rejects with a stable reason code before any secret material is accessed.