Skip to main content

ToolEvaluator

Trait ToolEvaluator 

Source
pub trait ToolEvaluator: Send + Sync {
    // Required method
    async fn evaluate(
        &self,
        kernel: &ChioKernel,
        request: &ToolCallRequest,
    ) -> Result<ToolCallResponse, KernelError>;

    // Provided methods
    async fn evaluate_with_metadata(
        &self,
        kernel: &ChioKernel,
        request: &ToolCallRequest,
        extra_metadata: Option<Value>,
    ) -> Result<ToolCallResponse, KernelError> { ... }
    async fn validate_capability(
        &self,
        kernel: &ChioKernel,
        request: &ToolCallRequest,
    ) -> Result<Verdict, KernelError> { ... }
    async fn run_guards(
        &self,
        kernel: &ChioKernel,
        request: &ToolCallRequest,
    ) -> Result<Verdict, KernelError> { ... }
    async fn dispatch(
        &self,
        kernel: &ChioKernel,
        request: &ToolCallRequest,
        has_monetary_grant: bool,
    ) -> Result<(ToolServerOutput, Option<ToolInvocationCost>), KernelError> { ... }
    async fn sign_receipt(
        &self,
        kernel: &ChioKernel,
        body: ChioReceiptBody,
        canonical_content: Vec<u8>,
    ) -> Result<ChioReceipt, KernelError> { ... }
}
Expand description

The four logical phases of a tool-call evaluation, surfaced as an async-capable trait so each phase can be replaced with an async-native implementation without re-shaping the public surface.

The default [BlockingToolEvaluator] preserves the semantics of ChioKernel::evaluate_tool_call_sync_inner by delegating to the evaluate_tool_call_sync shim. The four step methods (validate_capability, run_guards, dispatch, sign_receipt) default to forwarding through the full synchronous pipeline; override them to swap in async-native step bodies.

Required Methods§

Source

async fn evaluate( &self, kernel: &ChioKernel, request: &ToolCallRequest, ) -> Result<ToolCallResponse, KernelError>

Run the full evaluation pipeline for request against kernel and return the resulting ToolCallResponse.

Provided Methods§

Source

async fn evaluate_with_metadata( &self, kernel: &ChioKernel, request: &ToolCallRequest, extra_metadata: Option<Value>, ) -> Result<ToolCallResponse, KernelError>

Run the full evaluation pipeline with additional receipt metadata.

Source

async fn validate_capability( &self, kernel: &ChioKernel, request: &ToolCallRequest, ) -> Result<Verdict, KernelError>

Validate the capability token attached to request.

Source

async fn run_guards( &self, kernel: &ChioKernel, request: &ToolCallRequest, ) -> Result<Verdict, KernelError>

Run the registered guard pipeline against request.

Source

async fn dispatch( &self, kernel: &ChioKernel, request: &ToolCallRequest, has_monetary_grant: bool, ) -> Result<(ToolServerOutput, Option<ToolInvocationCost>), KernelError>

Direct phase dispatch is unavailable because it cannot retain the admission operation, compensation, outcome, and receipt as one durable lifecycle. Use ToolEvaluator::evaluate instead.

This default denies every direct dispatch, not only monetary ones. Implementors that override dispatch are unaffected; those that relied on the default should read docs/migrations/kernel-embedder-surface.md.

Source

async fn sign_receipt( &self, kernel: &ChioKernel, body: ChioReceiptBody, canonical_content: Vec<u8>, ) -> Result<ChioReceipt, KernelError>

Sign the receipt for the (allow or deny) outcome of a tool call.

Accepts a fully-constructed ChioReceiptBody plus the exact byte preimage its content_hash was derived from, and returns the signed ChioReceipt. The default body routes through kernel.sign_receipt_via_channel (the mpsc-backed signing task); producers wait on bounded backpressure, never on a receipt-log mutex. The signed receipt is byte-identical to the inline build_and_sign_receipt path, and equally fail-closed: both delegate to chio_kernel_core::sign_receipt_with_handle, which recomputes content_hash over canonical_content and refuses to sign on mismatch (WYSIWYS).

Dyn Compatibility§

This trait is not dyn compatible.

In older versions of Rust, dyn compatibility was called "object safety".

Implementors§