The Three Verdicts

Three values, two of them decisions

Verdict is declared twice. Once in the portable core and once in the hosted shell, with the same three variants, the same derives, and no re-export between them. The core’s copy carries the asymmetry in its own doc comment:

/// Three-valued outcome of a kernel evaluation step.
///
/// This mirrors `chio_kernel::runtime::Verdict` exactly. The
/// kernel core never emits `PendingApproval` itself; the full `chio-kernel`
/// orchestration shell wraps the core verdict with the human-in-the-loop
/// approval path where needed.
#[derive(Debug, Clone, Copy, PartialEq, Eq)]
pub enum Verdict {
    /// The action is allowed.
    Allow,
    /// The action is denied.
    Deny,
    /// The action is suspended pending a human decision. Only produced by
    /// the full `chio-kernel` shell, never by `chio-kernel-core` directly.
    PendingApproval,
}

A portable core that declines to produce a value still has to name it, because guards, adapters, and wire types all round-trip through the same enum. Declaring it and refusing it is what makes the seam legible: the third value exists in the type on both sides, and exactly one side may construct it on a live evaluation. That costs one enum variant.

Both enums are shipped. The shell path that mints the third value is wired into the async evaluation core, but it is reachable only on a kernel configured for durable admission. Without a qualified admission operation store, a grant carrying a cumulative-approval constraint is a hard deny, not a park. The receipt vocabulary that would record the parked state does not exist and never has; see Guarantees and limits.

Who may construct which value

Two of those rows say Guard and mean different traits. The portable trait returns Result<Verdict, KernelCoreError> and sees a PortableToolCallRequest with no DPoP proof, no governed intent, no approval token, and no model metadata. The shell trait returns Result<GuardDecision, KernelError>, carries GuardEvidence alongside the verdict, and adds the dispatch-revalidation hooks. Every guard in chio-guards implements the shell trait. Nothing outside chio-kernel-core’s own test fixtures implements the portable one: tests/portable_build.rs and the evaluate.rs test module hold the only impl Guard blocks against it in the tree. Every caller that reaches the core passes an empty guard slice: the browser adapter, the mobile FFI, the C++ kernel FFI, the Lambda extension, and the conformance hot-path tests all pass &[]. The shell exposes evaluate_portable_verdict, which takes a portable guard slice, and that entry point also has only test callers. On every one of those paths the third value has nowhere to come from at all.

The core: a pending verdict is a deny, worded as a deny

Step four of finish_verified_evaluation is the whole rule:

for guard in input.guards {
    let evaluation = guard.evaluate(&ctx);
    let step = match &evaluation {
        Ok(verdict) => GuardStep::from(*verdict),
        Err(_) => GuardStep::Error,
    };
    let projected_allows = guard_step_admits(step);
    if guard_projection_allows_continuation(projected_allows, step)
        && matches!(&evaluation, Ok(Verdict::Allow))
    {
        continue;
    }

    match evaluation {
        Ok(_) => {
            // PendingApproval is reserved for the full kernel orchestration
            // layer (chio-kernel::approval::ApprovalGuard); if a sync guard
            // surfaces it here we fail closed.
            let core_err = KernelCoreError::GuardDenied {
                guard: guard.name().to_string(),
            };
            return deny(core_err, Some(matched_grant_index), Some(verified));
        }
        Err(error) => {
            let core_err = KernelCoreError::GuardError {
                guard: guard.name().to_string(),
                reason: error.deny_reason(),
            };
            return deny(core_err, Some(matched_grant_index), Some(verified));
        }
    }
}

Continuation needs two independent yeses. GuardStep::from(Verdict::PendingApproval) is GuardStep::Error, so the pure projection says no: guard_step_admits runs the single step through guard_pipeline_allows, whose kernel is core_authorized && guard_allows with guard_allows true only for GuardStep::Allow. The observed result then has to be Ok(Verdict::Allow) as well. A disagreement between the projection and the observation is fail-closed in both directions, which is what guard_projection_allows_continuation exists to enforce.

The deny that follows is indistinguishable from a real deny. The Ok(_) arm builds KernelCoreError::GuardDenied, whose reason renders as guard "pending-guard" denied the request with no trace of which value the guard actually returned. The core test guard_projection_preserves_deny_and_pending_error_attribution pins that on purpose: a denying guard and a pending guard produce the same string. A proptest in chio-kernel/tests/guard_decision_equivalence.rs goes further and pins the whole fold, generating sequences of up to sixteen verdicts and asserting that guard_pipeline_allows over the projected steps agrees with core_authorized && every verdict is Allow over the raw ones. The bound is the property’s, not the runtime’s: nothing caps the number of guards a pipeline may hold.

The shell: same refusal, different wording

The hosted shell runs its own guard loop and reaches the same conclusion by a different route. evaluate_guards_sequential is shared by the inline path and the spawn_blocking offload, so the two cannot drift:

Verdict::PendingApproval => {
    // The `Guard` trait does not carry the HITL approval flow; that runs via
    // `ApprovalGuard::evaluate`. A `Guard` returning `PendingApproval` is an
    // unsupported state, so fail closed.
    return Err(GuardRunError::new(
        KernelError::GuardDenied(format!(
            "guard \"{}\" returned an unsupported approval verdict",
            guard.name()
        )),
        evidence,
    ));
}

Unlike the core, the shell keeps the distinction in the reason string. An operator reading returned an unsupported approval verdict knows a guard asked for something the pipeline cannot give it. On the core path that information is gone by the time the reason is built.

One guard returns it anyway

content-review is the only guard in chio-guards that emits the third value. On an ExternalApiCall to one of six payment services (stripe, paypal, square, braintree, adyen, plaid) it reads the matched grant for a RequireApprovalAbove { threshold_units } constraint, pulls an amount from amount_units, amountUnits, or amount, falls back to the governed intent’s max_amount, and returns Verdict::PendingApproval when the amount is at or above the threshold. The constraint is named RequireApprovalAbove and the comparison is units >= threshold_units, so a payment landing exactly on the threshold parks. Its module doc says the HITL flow takes over from there. It does not: the runner that invokes the guard maps that value onto a fail-closed deny. The call is blocked either way. What does not happen is an approval request being created, dispatched, or made resumable. The guard is opt-in through the content_review policy key and is not one of the seven default guards.

Three conditions silently skip the monetary check rather than failing it. A context whose matched_grant_index is None has no grant to read constraints off. A matched grant with no RequireApprovalAbove has no threshold. And an amount the guard cannot parse from any of the three argument keys or from the intent leaves it nothing to compare, at which point evaluate_amount_threshold returns Ok(None) with the in-code comment cannot compare; leave the decision to other guards and evaluation falls through to the PII and profanity scan. Nothing in the receipt records that the gate did not fire.

GuardPipeline adds a third reading in between. It treats pending as a sticky escalation: it keeps iterating so a later child can still short-circuit to Deny, and otherwise propagates the pending verdict as its own. Since the pipeline registers as a single Guard, that propagated value lands in evaluate_guards_sequential and is refused under the name guard-pipeline, not under the name of the child that raised it.

The path that legitimately mints it

In the async evaluation core the per-grant order is: governed-admission validation, then the guard pipeline, then the runtime admission hook, then check_and_increment_budget. Only the last of those can return BudgetAdmissionOutcome::PendingApproval, and only when the budget store answers BudgetAuthorizeHoldDecision::ApprovalRequired for a RequireCumulativeApprovalAbove constraint and the request carries no approval_tokens. The third value is therefore minted strictly downstream of the guard pipeline that refuses it and strictly upstream of dispatch. The GuardContext doc comment in chio-kernel still says matched_grant_index is populated by check_and_increment_budget before guards run. That comment is stale: the guard pipeline receives Some(matching.index) from the scope-match loop, and budget admission runs after. The order above is the one in the async evaluation core and the nested-flow path; the sync wrapper is not traced here.

Reaching that outcome at all takes more configuration than the sentence above implies. A matched grant carrying a cumulative constraint forces the structured admission path in begin_durable_tool_admission, and each of the following is a hard deny rather than a park:

• The kernel’s durable admission mode does not cover the request’s effect class: aggregate, cumulative, and supplemental authorization requires durable admission coverage.
• No durable admission runtime is attached: no qualified admission operation store is configured.
• The matched grant carries more than one cumulative constraint: a matching grant must contain exactly one cumulative approval constraint.
• The negotiated peer profile does not advertise cumulative_approval_budget: cumulative approval budgets were not negotiated. The kernel’s own local profile turns that feature on; a request arriving with a federated_origin_kernel_id uses the pinned peer profile instead, which must advertise it.

Monetary calls add one more gate: durable monetary admission requires a qualified payment adapter with a recoverable rail identity. The pending verdict is therefore not a property of the guard runtime. It is a property of a node wired for durable admission, and on any other node the same capability denies.

The kernel also checks that it can afford to park before it parks. It runs release_runtime_admission_reservations_for_pre_dispatch_denial and requires the release to be confirmed. A retained lease converts the pending outcome into a fail-closed deny reading durable admission failed: runtime admission reservation retained on pending approval, because telling a caller to go collect a human signature for an operation whose lease was never released would leak the reservation for the length of the approval window.

Every field of the response it builds is pinned. The verdict is PendingApproval; the output is the serialized ThresholdApprovalProposal, so the caller receives the artifact it must get signed; the reason is None; the terminal state is Incomplete { reason: "approval_required" }; no execution nonce is issued. The signed receipt records Decision::Deny { reason: "cumulative approval required", guard: "kernel" } plus a threshold_approval metadata block carrying the proposal id, hash, deadline, and the state string approval_required.

The capability feature that produces the third value in the shell is one the core refuses outright. A scope with a cumulative-approval constraint is denied on the full-floor path (evaluate_with_full_floor and evaluate_with_full_floor_and_root) with capability feature unsupported on this runtime: cumulative approval enforcement rather than admitted unenforced. The plain evaluate and evaluate_with_crypto_floor entry points do not carry that check, but they do not admit the grant either: portable scope matching in chio-kernel-core/src/scope.rs treats both RequireApprovalAbove and RequireCumulativeApprovalAbove as unevaluable and fails the whole resolution with portable kernel cannot safely evaluate require_approval_above. Either way the core declines the token instead of guessing. No approval constraint of any kind is enforceable in the portable core.

Nothing on this path writes an ApprovalStore row. ApprovalGuard::evaluate is the component that would, and it has no non-test caller in crates/. Its module doc points callers at ChioKernel::evaluate_tool_call_with_hitl, which does not exist in the tree. In the shipped sidecar, pending records are created by an explicit POST /approvals/submit from the caller, and the resume flow (resume_with_decision, the single-use replay registry, and ten /approvals/* routes behind the require_sidecar_control_middleware gate) works against records created that way. The Python LangGraph SDK ships its own approval node that reuses the name ApprovalGuard in a deny payload; it does not call the Rust type.

What each consumer does with it

The A2A and ACP protocol edges each expose a project_pending_approval_for_test helper that overwrites a completed response with the pending verdict. Both are #[cfg(test)]. No protocol edge mints the value in production; they only project one handed to them.

Guarantees and limits

Next steps

• Core & Shell · the eight-item exclusion list this asymmetry belongs to, and the rest of the Kernel-to-Node seam
• Approval & HITL · the request record, the signed token, the binding checks, and the resume flow
• Approval Store · where a pending record and its consumed-token registry live on one node’s disk
• Portable Kernel Core · the three FFI adapters and how each maps a verdict onto its wire
• Fail-Closed Semantics · the wider rule the third verdict is one instance of
• Budget Store · the cumulative-approval accounting that decides when a call is parked