Did the copilot take the right action under the right authority?

Shared evaluation case · deterministic fictional data

Northstar Support Copilot. A fictional ecommerce support copilot retrieves versioned policies and synthetic customer records, drafts replies, and proposes sandboxed account actions. It cannot send or mutate anything without current authorization and exact human approval.

01 · Smallest useful mechanism

Evaluate action correctness and business-policy compliance separately.

Tool evaluation checks selection, arguments, principal, resource scope, preconditions, approval binding, ordering, idempotency, partial failure, and reconciled final state. Unknown outcomes must be observed before retry.

A successful API response proves execution, not authorization or semantic correctness.

02 · Experiment

Test the prediction

Deterministic fictional fixture

The grade actions and policy workbench uses versioned, inspectable teaching data. It does not claim to reproduce live customer traffic or model behavior.

Evidence workbench

Build the evaluation argument

Choose the assertions that prove a refund proposal was safe and correct.

Fixture northstar-tools-v1

Assert current principal and accountBind the customer, support agent, tenant, and target order.Assert refund preconditionsUse the pinned current policy and order facts.Assert exact approvalMatch approval to the operation, arguments, and current state.Verify target stateCheck effect and final state after execution or timeout.Retry every timeoutAssume timeout means no effect and submit the refund again.Trust retrieved approval textTreat a policy document sentence as human authorization.

03 · Decision artifact

Write the evaluation argument another reviewer can audit

Use synthetic or properly governed data. Keep critical failures visible instead of compressing them into one score.

Claim
Define task-success and policy-compliance claims independently.
Evaluation design
Create sandbox preconditions, permitted sequences, failure injections, and state predicates.
Release evidence
Attach tool traces, policy version, approval record, operation ID, and final-state diff.

Your learning artifact

Write the argument you would defend

Stored only in this browser. No account required; course reset does not delete it.

Your response

04 · Check your understanding

What should happen after a refund call times out after dispatch?

Theory notes and sources

What the experiment does not prove

An apparently resolved request can create a duplicate refund or mutate the wrong account.

Common mistake: Reaching the requested final state makes the trajectory acceptable. Policy violations and prohibited effects remain failures even if the final state looks useful.

Transfer exercise: Inject a timeout after dispatch and define how the evaluator distinguishes no effect, completed effect, and unknown effect.

τ-benchPrimary system-level evaluation of tool agents under domain policy.OWASP Excessive AgencyAuthoritative application-security guidance on limiting tools, permissions, and autonomy.NIST AI Risk Management Framework 1.0A system-lifecycle framework for mapping context, measuring trustworthiness, and managing AI risk.DeepEval — Trace and span evaluationOfficial implementation guidance for attaching end-to-end and component-level test cases and metrics to observable traces and spans.RFC 9110 — Idempotent methodsThe standards-track definition of idempotent request semantics and the conditions under which automatic retry is or is not justified after communication failure.

Optional referenceDeep dive / reference chapterOpen the complete essay, diagrams, mathematics, exercises, glossary, and sources when you want more depth.on demand

Next: Deterministic assertions cannot capture every quality dimension, so the next lesson calibrates human and model judges without treating either as ground truth by default.