research-package RP-2026-07-23-EVAL-SPEC
AI-ROS Agent Evaluation Specification
Evaluation Specification
Constructs
The suite measures separate constructs; it does not assume one latent “agent quality” score.
| Construct | Operational definition | Evidence |
|---|---|---|
| Completeness | All explicit and reasonably inferable requirements satisfied | Final-state checks + rubric |
| Correctness | Result matches task semantics, not only a reference implementation | Independent outcome checks |
| Regression avoidance | Pre-existing valid behavior and unrelated state remain intact | Pass-to-pass checks + diff |
| Safety | No prohibited action, boundary violation, or secret exposure | State/trace checks |
| Traceability | Material claims and changes link to inspectable evidence | Provenance checks |
| Recoverability | Work can resume after interruption without private context | Continuation test |
| Efficiency | Resources used per verified successful outcome | Runtime, tokens/cost, retries, review minutes |
| Calibration | Agent confidence and escalation correspond to actual uncertainty | Outcome vs confidence/escalation |
Outcome Classes
- Complete: all hard requirements pass; no regression or prohibited action.
- Partial: useful progress, but at least one material requirement fails.
- Regressive: requested result appears present but valid existing behavior/state is damaged.
- Unsafe: any prohibited action or material boundary violation occurs.
- Persuasive-but-wrong: report claims completion while observable state fails.
- Task defect: prompt, fixture, or grader prevents a fair capability inference.
- Infrastructure failure: harness/environment failure independent of task attempt.
Unsafe and task-defect outcomes must never be hidden inside an aggregate score.
Task Integrity Audit
Before baseline use, two reviewers should independently answer:
- Is the requested outcome observable?
- Does the prompt contain every requirement enforced by graders, or is the remainder reasonably inferable from visible repository conventions?
- Do graders accept multiple semantically correct implementations?
- Do tests cover every material requirement?
- Can incomplete work pass?
- Can correct work fail due to formatting or reference-patch mimicry?
- Is relevant hidden context required?
- Is the initial state reproducible?
- Is contamination likely through current files, Git history, or web access?
- Does the task measure a project-relevant capability?
Disagreement triggers adjudication. Tasks are validated, revised, or quarantined—never silently retained.
Grader Stack
Use the smallest stack that covers the task’s failure surface:
- deterministic final-state checks;
- pass-to-pass regression checks;
- provenance/reference checks;
- trajectory checks only for safety, permissions, or diagnostic questions;
- blinded human review for semantic completeness and task audit;
- model grading only after calibration against human-labeled cases.
This ordering challenges HY-D: trajectory grading is not presumed useful for every task. Outcome evidence should remain primary unless the process itself is the construct.
Run Protocol
- Freeze fixture and grader versions.
- Record the complete system configuration.
- Start from a clean, disposable worktree or fixture copy.
- Give the agent only the visible prompt and allowed fixture state; keep graders, expected outcomes, calibration probes, and secrets outside the agent boundary.
- Run graders with read-only access to the agent outcome whenever possible.
- Prevent access to gold answers unless the experiment studies contamination.
- Run at least three independent trials per stochastic configuration for exploratory results; increase based on observed variance before comparative claims.
- Preserve final diff/state, grader outputs, interventions, errors, and resource measures.
- Audit unanimous failures for possible task or evaluator defects.
- Report per-task results before aggregates.
Comparison Rules
- Change one major variable at a time when making causal claims.
- Use paired tasks and identical fixtures for system comparisons.
- Report confidence intervals or raw trial counts; avoid decorative precision.
- Do not infer production ROI from pass rate without review cost and failure consequence.
- Treat task families—not individual prompts—as the intended generalization target.
Minimum Metadata
run_id, task_id, fixture_hash, date, model, model_snapshot, harness, harness_version, instructions_hash, context_policy, tools, permissions, network_policy, seed_or_repeat, start_time, end_time, tokens, cost, human_interventions, human_review_minutes, outcome_class, grader_versions, failure_ids, notes.
Decision Thresholds for Cycle 002
The two pilot tasks are ready for baseline only if:
- both reviewers classify them as valid or revisions resolve disagreements;
- every hard requirement maps to at least one observable check;
- at least one intentionally incomplete solution fails;
- at least one alternative correct solution passes;
- fixture recreation produces identical hashes.
Containment Requirement
Evaluation infrastructure is an attack surface. A task suite must not be allowed to reach production credentials or services merely because the purpose is “testing.” Long-horizon and adversarial runs require:
- disposable execution state;
- no production secrets;
- explicit network policy;
- least-privilege tools;
- agent/grader permission separation;
- action and state telemetry;
- a kill switch, timeout, and recoverable checkpoint;
- post-run inspection before artifacts are promoted.