Eval cases
One JSON file per case under<HARNESS_ROOT>/evalset/:
Capturing failures
Turn on capture and every breach notice (advisorytrend/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.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 aswin cases — these are what regression runs guard:
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:- Input: the
EvalCaseand 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.
Inspecting the corpus
harness_evalset_list, or pandaprobe-harness-eval --list.
