Skip to main content
The eval set is the harness’s corpus of scenarios worth re-running: failures to fix and wins to protect. It is the shared substrate of the closed loop — rule validation replays matching failures to vet candidates, and regression runs replay everything to catch a new rule breaking an old win.

Eval cases

One JSON file per case under <HARNESS_ROOT>/evalset/:

Capturing failures

Turn on capture and every breach notice (advisory trend/relative notices don’t qualify — their scores can sit above the threshold) records the session as a failure case:
Capture is opt-in (capture_eval_cases, default false) because cases store session-derived data — the signature, scores, and whatever your turn payloads carry — under the workspace.
Where does replay_input come from? From the turn payload’s end_state when your loop or adapter provides one. The facade’s bare harness.turn(...) scope sends an empty payload, so in that setup attach inputs explicitly:

Protecting wins

Capture known-good scenarios as win cases — these are what regression runs guard:
Corpus management is deliberately conservative: cases dedup per (session, signature, kind); at eval_case_max (default 200) the oldest failures evict first; win cases are never auto-evicted — if the corpus is all wins, capture refuses loudly rather than dropping one.

The replay function

The platform is passive — it scores traces that already exist. To learn what would happen under a new rule set, the harness must re-run your agent, and only you know how to do that:
The contract, precisely:
  • Input: the EvalCase and the system-context string to run under (the current rendered rules — during candidate validation, the provisional rule is in it).
  • Output: a new session id whose traces the harness can score. Never reuse the original session.
  • Behavior: each invocation is awaited sequentially and bounded by replay_timeout_s; exceptions and timeouts degrade to “inconclusive” — they never crash validation or a regression run.
Be honest with yourself about this dependency. Without a replay function, ReplayValidator and regression runs cannot execute: candidate validation falls back to forward trials (slower, statistical — announced once in the log and journal), and run_regression reports every case as skipped with one clear warning. The harness never silently pretends it replayed something.

Inspecting the corpus

Or from the agent/operator side: harness_evalset_list, or pandaprobe-harness-eval --list.