Harness Conformance
Harness Conformance
Results
These results are updated automatically from scripted model, tool, and verifier scenarios at the linked Gym revision. Each P0, P1, or P2 cell shows passing scenarios / measured scenarios; a dash means no applicable measurements are available. Green counts mean all measured scenarios pass; red counts mean at least one does not pass.
Detailed checks by harness
✓ Pass · ✗ Requirement not demonstrated (invalid, missing, blocked, or no result) · — Not applicable.
simple
P0
- Passing:
tool_success,tool_failure,usage_omitted,retry_429,retry_500,model_error,judge_verifier,verifier_failure,context_compaction - Not passing: None
P1
- Passing:
judge_verifier - Not passing:
context_compaction
opencode
P0
- Passing:
tool_success,tool_failure,usage_omitted,retry_429,retry_500,model_error,judge_verifier,verifier_failure,context_compaction - Not passing: None
P1
- Passing:
judge_verifier,context_compaction - Not passing: None
codex
P0
- Passing:
tool_success,tool_failure,usage_omitted,retry_429,retry_500,model_error,judge_verifier,verifier_failure,context_compaction - Not passing: None
P1
- Passing:
judge_verifier,context_compaction - Not passing: None
hermes
P0
- Passing:
tool_success,tool_failure,usage_omitted,retry_429,retry_500,model_error,judge_verifier,verifier_failure,context_compaction - Not passing: None
P1
- Passing:
judge_verifier,context_compaction - Not passing: None
kilocode
P0
- Passing:
tool_success,tool_failure,usage_omitted,retry_429,retry_500,model_error,judge_verifier,verifier_failure,context_compaction - Not passing: None
P1
- Passing:
judge_verifier,context_compaction - Not passing: None
stirrup
P0
- Passing:
tool_success,tool_failure,usage_omitted,retry_429,retry_500,model_error,judge_verifier,verifier_failure,context_compaction - Not passing: None
P1
- Passing:
judge_verifier,context_compaction - Not passing: None
openclaw
P0
- Passing:
tool_success,tool_failure,usage_omitted,retry_429,retry_500,model_error,judge_verifier,verifier_failure,context_compaction - Not passing: None
P1
- Passing:
judge_verifier - Not passing:
context_compaction
nooa
P0
- Passing:
tool_success,tool_failure,usage_omitted,retry_429,retry_500,model_error,judge_verifier,verifier_failure,context_compaction - Not passing: None
P1
- Passing:
judge_verifier - Not passing:
context_compaction
379ae226d12a · Results
A scenario counts in a tier when it has applicable checks at that priority, and passes when all of those checks pass. A scenario can contribute to more than one tier; failures in one tier do not change another tier’s count. Completed check results remain visible when a probe reports execution errors. Expand the details to see each harness’s passing and not-passing scenarios by tier, followed by the full check matrix. Follow the linked CI results to investigate individual failures.
These measurements cover local execution. See Rollout Evidence for collection setup.
Inspect rollout evidence
Check the evidence retained by a harness/benchmark pair after collecting an evaluation:
The gym-p0/v1 profile checks trajectory evidence across TE-1–TE-9. Each check
declares tier: P0, P1 or P2. Every applicable P0 check must pass on every rollout.
All current checks are P0, including ownership and call-to-step attribution.
TE labels group results for reporting; they do not determine priority or schedule checks.
This guide and the check definitions maintain the implemented requirements.
Checks do not repeat Gym’s unit tests for ID uniqueness, timestamp ordering or usage normalization.
The profile covers retained artifacts. It does not certify live failure/retry scenario coverage, closed-run completeness, health, accuracy, or deployment readiness. Independent completeness required by some health consumers is separate from TE-9’s retained reference check. Only the saved sandbox rows of TE-10 are included. P1 efficiency requirements remain outside this profile.
Applicability and delivery
By default the pair has policy steps, tools, and a verifier. Use --no-tools,
--no-verifier, or --no-steps only when that feature does not apply to the
pair. These flags select checks; they are not inferred from the artifacts.
With --no-steps, step checks are excluded; invocation ownership checks still apply.
--bundle accepts a JSONL file, or a directory with exactly one rollouts.jsonl
or evaluator_rollouts.jsonl, at its root or under artifacts/.
Each evidence check uses one designated location: $.ng_trajectory for model
calls, steps, invocations and tool executions; rollout fields for grades;
$.ng_agent_observations.records for sandbox outcomes and compaction helper
references. Tool arguments currently live in the canonical invocation conversation.
Missing canonical evidence is not repaired from duplicate capture/observation
attachments, and those copies are not compared for consistency.
--capture-dir retains capture sidecars in input provenance only. It cannot
supply or invalidate evidence at the designated locations. --require-sandbox
requires a saved sandbox record; sandbox records are checked whenever present.
Each inspection atomically publishes an immutable directory containing:
evidence_summary.json: gate, per-TE counts, token availability, applicability, source/checker hashes and qualification limits.evidence_results.jsonl: individual checks with ID, kind, priority tier, status, JSONPath, reason and blocking prerequisite; TE labels and failure findings for reporting.evidence_report.md: evidence table.
Exit codes are 0 for a met gate, 1 for unmet evidence, and 2 for an input/checker error. An empty input is an error. Reports omit payload contents. Identical inputs and checker versions reuse the same report directory.
Read individual results
- Schema: saved fields have the required structure, types and values.
- Semantic: references resolve to unambiguous saved targets.
- Behavioral: harness behavior and saved evidence match the controlled test’s model, tool and verifier observations.
- Health: each rollout health result matches its scenario’s expected
healthy,unhealthyorunobservedoutcome. A pass means the expected outcome occurred, not necessarily that the rollout was healthy.
The standalone inspector runs schema and semantic checks; the conformance runner also runs behavioral and health checks.
Health checks are generated from Gym’s registered rollout checks and are all P0.
The runner calls the same top-level health engine as gym eval health-check once
on the saved rollout and failure files, retaining its reports under health/.
Each scenario’s health_expectations overrides the default healthy expectation;
unknown check IDs are configuration errors. New registered rollout checks default
to healthy. Task-level checks requiring repeated executions are outside this suite.
Each check reports pass (✓), fail (✗: requirement not demonstrated), or
not_applicable (—: excluded by the check’s applicability condition).
Missing required input and blocked prerequisites fail the check; the result retains
the reason and blocked_by IDs. Blocked checks do not evaluate their input.
An unrelated malformed step does not invalidate model-call checks.
A behavioral failure does not erase artifact passes.
The runner writes conformance_report.md with one table per harness: check IDs as
rows and scenarios as columns. Process return codes and timeouts stay in
scenario_result.json as execution status, outside the evidence checks. A failure
sidecar without a normal rollout fails applicable artifact checks. Missing check
results also display ✗; execution details retain any runner/checker error.
Compare harnesses
Use the same task and capture settings when comparing harnesses:
The command writes per-harness reports plus harness_evidence.md and
harness_evidence.json. Applicability flags apply to every input pair in that
comparison. A matrix FAIL identifies missing or inconsistent evidence; it is not
a benchmark accuracy result.
Checker unit tests use hand-authored synthetic evidence contracts, independent of harness implementations. Mutations verify missing, conflicting, and malformed evidence without prescribing which checks a real harness should pass.