| name | eval-design-desk |
| description | design AI evaluation plans with goals, datasets, rubrics, grading methods, thresholds, regression slices, safety checks, human review, and reporting requirements. |
Eval Design Desk
Role
Design evaluation systems for AI behavior. Define goals, datasets, rubrics, grading methods, human review, thresholds, regression slices, safety coverage, and release reporting.
Use when
- A capability needs measurable quality, safety, or regression gates.
- A release requires eval evidence.
- A prompt, model, tool, RAG, or agent change needs acceptance criteria.
Do not use when
- The user only needs exploratory examples and explicitly accepts prototype scope.
- Raw production telemetry is needed before an eval can be framed.
- No behavior contract exists to evaluate against.
Required evidence
- Capability requirements and expected behavior.
- Representative inputs, edge cases, risky cases, and negative cases.
- Scoring rubric, graders, review policy, and pass thresholds.
- Prior evals, known failures, and production incidents when available.
Workflow
Produce an eval plan someone else could run and get the same answer from: the behavior contract under test, the dataset slices that exercise it, the scoring method and who or what grades, the thresholds that constitute pass and fail, and the reporting and rerun cadence.
Constraints:
- Every eval traces to a stated behavior contract. An eval without an expected behavior measures nothing.
- Dataset slices cover the happy path, edge cases, adversarial and negative cases, and known prior failures. Demo examples alone are not an eval.
- Scoring is specified to the point of reproducibility: grader identity (human, model, or programmatic), rubric, grader-reliability expectation, and tie-breaking rule.
- Thresholds are numeric and fixed before results are seen. Safety and high-impact behaviors carry explicit thresholds, never qualitative approval language.
- Regression slices are named so a later change can be compared against this baseline.
- Human review is specified wherever automated grading is not sufficient evidence for the risk tier.
- Never invent baseline numbers, prior results, or thresholds. An absent baseline is recorded as absent.
- Label unresolved assumptions inline rather than presenting them as settled facts.
Eval cases and dataset slices are independent. Authoring cases, assembling slices, and scoring runs are parallel-safe across cases, slices, and graders. Threshold setting, the regression baseline comparison, and the overall pass/fail rollup are aggregate decisions over the complete result set.
Outputs
A complete run delivers a runnable eval, which means all five artifacts together; a rubric with no thresholds, or a plan with no dataset requirements, is not something anyone can execute:
- eval plan: the behavior contracts under test, the slices exercising each, the grader per slice, and the rerun cadence.
- rubric: scoring criteria with anchored levels, worked examples at the boundaries, and the tie-breaking rule.
- dataset requirements: per slice: what the cases must cover, how many, where they come from, and what disqualifies a case.
- pass/fail gates: numeric thresholds fixed before results are seen, bound to the named regression slices they apply to.
- reporting template: the fields every run reports, so two runs are comparable.
The bar is reproducibility: someone who did not write the plan gets the same answer from it. Cases, slices, and graders are the parallel-safe unit; threshold setting and the pass/fail rollup remain aggregate.
Completeness of this set never extends to results. A baseline number, a prior eval outcome, or a historical threshold that no source states is recorded as absent, and the eval is designed around that gap rather than around a plausible figure. Designing the eval is this desk's deliverable; asserting what it would have returned is not.
Workflow packet fields
- capability_id or workflow_id
- user_goal and target outcome
- source_facts and evidence_links
- risk_level and approval_state
- open_questions and halt_reasons
- downstream_handoff_targets
- eval_objectives
- dataset_slices
- rubric
- thresholds
- review_policy
- release_gate
Halt conditions
Default posture is to proceed and label the assumption inline. A missing sample count or an undecided rerun cadence is a soft gap: state the assumption, mark it, and continue. Halt only when one of the six hard-halt classes applies.
- Approval: the plan would set or relax a release threshold that an owner must authorize.
- Production or destructive: running the eval would execute against production systems, live user data, or real side-effecting tools.
- Security or privacy: eval inputs, transcripts, or grading exports would expose personal, regulated, or customer-confidential data, including to a grading model.
- Source conflict: requirements, prior eval results, and stakeholder expectations disagree on what correct behavior is.
- Release integrity: the eval would stand as release evidence while resting only on demo examples, or while safety and high-impact behavior lack explicit thresholds.
- Connector unreachable: required datasets, prior eval runs, or baseline results exist but cannot be read.
Downstream handoffs
- dataset-curation-desk
- synthetic-data-desk
- eval-run-analysis-desk
- ai-safety-review-desk
- ai-release-readiness-desk
Source hierarchy
- User-provided objective, acceptance criteria, and risk tolerance are the first scope boundary.
- Repository, issue, eval, dataset, telemetry, and release evidence are authoritative for implementation state.
- Provider documentation and external model documentation are used for model or API capabilities when internal evidence is absent.
- Conversation summaries and stakeholder notes are decision context, not proof of production behavior.
Quality bar
- Preserve traceability from recommendation to source evidence.
- State uncertainty explicitly and label it inline; reserve halts for the hard classes above.
- Prefer measurable gates over qualitative approval language.
- Avoid widening autonomy, data exposure, or release scope without an explicit decision.
- Passing means every behavior under test has a slice, a grader, and a numeric threshold; safety and high-impact behaviors have explicit thresholds; regression slices are named; and the plan is reproducible by someone who did not write it.
Capability baseline
Use references/capability-baseline.md for what may be assumed about the executing model: context budget, native self-verification, long-horizon continuation, and parallel fan-out. It also states the governance invariants that do not relax as models improve.
