Skip to main content

core/evals/ — regression gate for AUDIT.md

Every change to AUDIT.md must keep this suite green. The harness validates agent outputs (a run's docs/BACKLOG.md + docs/HANDOFF.md) against the machine-checkable subset of the protocol's rules, and proves each rule is load-bearing by fault injection: a B* fixture plants a known fault set (usually exactly one; B16 deliberately plants three to verify exact-set reporting), and the validator must catch exactly that set — no more, no less. A trap that stops tripping means a rule has silently died. G* fixtures are the precision half: compliant-but-tricky outputs (negated prose, redaction markers, adversarial formatting, minimal-valid) that must NOT trip anything — the suite proves rules fire and don't over-fire.

Two checks make the rest load-bearing: TEMPLATE-NONCONFORMANT (output that doesn't follow the Phase 2 template can no longer silently escape the other tripwires — BS-12) and the CONFIG preflight (CONFIG-PLACEHOLDER / CONFIG-BAD-ENUM, which also auto-loads PROTECTED_AREAS from the target's AUDIT.md so R3 needs no --protected double entry — BS-13).

Files

File Role
code_audit_validator.py The validator implementation. Zero dependencies (stdlib only); published to PyPI as code-audit-validator.
validate.py Repo-side CLI shim over the module above — every documented python3 core/evals/validate.py … invocation goes through it.
fixtures/ G* = compliant outputs that must pass. B* = fault-injection traps that must fail with declared codes.
rules.json Rule registry: rule → AUDIT.md anchor → violation codes → fixtures proving it. Coverage gaps are declared honestly.
baseline.json Last recorded matrix (fixture → outcome) pinned to an AUDIT.md version + sha256.
run-evals.sh Runner; --record refreshes baseline.json.

Commands

python3 core/evals/validate.py --all                  # full suite, human output
python3 core/evals/validate.py --all --json           # machine-readable
./core/evals/run-evals.sh --record                    # run + pin baseline to current AUDIT.md
python3 core/evals/validate.py --run <dir>            # validate a real run's docs/ output
python3 core/evals/validate.py --run <dir> --report json   # structured findings export (core/schemas/report.v1.json)
python3 core/evals/validate.py --run <dir> --report sarif  # GitHub code-scanning format
python3 core/evals/validate.py --aggregate r1.json r2.json # portfolio roll-up over report JSONs
python3 core/evals/validate.py --batch targets.yaml        # fleet runner: per-target reports + portfolio.json
python3 core/evals/validate.py --compare prev.json curr.json  # run-over-run regressions (reopened tasks, new codes)
python3 core/evals/validate.py --run <dir> --emit-feedback # feedback@1 calibration record (core/schemas/feedback.v1.json)
python3 core/evals/validate.py --run <dir> --fail-on High  # severity exit-code policy (all violations still printed)
python3 core/evals/scripts/retro-summary.py           # retro scores per protocol version (did each release help?)
python3 core/evals/scripts/retro-summary.py --feedback-dir <field-data>  # + per-version FIELD trend

Field-run accuracy evaluation (tiers, metrics, calibration pipeline): TESTING-PROTOCOL.md.

Point --run at the target repo root (or its docs/): if the target's AUDIT.md is found, its CONFIG is preflighted and PROTECTED_AREAS is loaded automatically; --protected extends it.

Runner vs copy mode. A target needs either an audit-profile.yaml with a config: section (runner mode — the protocol stays here, launch via ./core/evals/run-audit.sh <target> [agent cmd]) or a full AUDIT.md copy (copy mode — pinned + self-contained; wins precedence when both exist). The preflight, placeholder/enum checks and PROTECTED_AREAS auto-load behave identically for both sources (B17/B18/G08 vs B26/G11).

Waivers. A target repo may carry docs/AUDIT-WAIVERS.yaml — audit-trailed, expiring suppressions (code + optional file/match + reason + approved_by + mandatory ISO expires). A valid waiver suppresses the matched violation and is reported separately; an expired or undated one un-suppresses it AND flags the stale waiver (WAIVER-EXPIRED). This is the sanctioned exception channel — eval fixtures, by contrast, may never be weakened.

Parsing notes (precision boundaries, pinned by fixtures). Tables inside

leading-pipe GFM rows — the exact Phase 2 template shape; pipeless variants
read as nonconformant. Protected-area matching is case-insensitive substring —
keep CONFIG entries specific (`src/billing/`, not `src/`). Artifacts must be
UTF-8 and ≤ 10 MB (`MALFORMED-FILE` otherwise, never a crash).

**Version pinning.** The validator checks the *current* protocol's template.
Validating artifacts produced under an older protocol? Pin the matching tag
(validator and protocol release in lockstep: `v1.2.0` ↔ protocol v1.2.0).

## Adding a fixture

1. Create `core/evals/fixtures/<Gnn|Bnn>-<slug>/` with `fixture.yaml` + `docs/BACKLOG.md` (and `docs/HANDOFF.md` if relevant).
2. `fixture.yaml` is flat `key: value` (no YAML library needed):

   ```yaml
   id: B11-my-trap
   description: one line
   expect: fail                  # or pass
   expected_violations: [R1-NO-OUTPUT]
   exercises_rules: [R1]
   protected_areas: []
  1. For expect: fail, the validator must report exactly expected_violations — plant one fault per fixture unless the fixture's purpose is exact-set verification (B16). Keep docs/BACKLOG.md template-conformant (Mode line + tables or the R7 line) so the planted fault is the only signal; ship a near-miss G* sibling when adding a new rule, so precision is pinned alongside recall.
  2. Register the fixture in rules.json under the rule(s) it exercises — validate.py --all fails on registry drift in either direction (BS-10).
  3. Run ./core/evals/run-evals.sh --record.

What the validator cannot see (declared gaps)

The authoritative register is core/improve/BLINDSPOTS.md — one row per blind spot, with status and evidence. Headlines:

  • Whether code changes were genuinely valuable (retro item 9 — human judgment).
  • Whether findings were padded (retro item 3 — judgment; the validator only guarantees padding is never required).
  • Live-agent properties: actual command execution, 3-strike counting, resume behavior (R4). For hard guarantees on those, use deterministic hooks/CI in the target repo, not prompt text.
  • Run completeness: --run accepts a docs/ directory without HANDOFF.md (legitimate mid-flight). When reviewing a run that claims to be finished, confirm HANDOFF.md exists yourself (BS-09).

Metadata

Release files for code-audit-validator 1.5.0

For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.

Source distribution (sdist)

Source distribution for code-audit-validator 1.5.0
File Size Uploaded
code_audit_validator-1.5.0.tar.gz 43.6 kB Details

Built distribution (wheel)

Table of built distributions (wheels) for code-audit-validator 1.5.0
File Interpreter ABI Platform
code_audit_validator-1.5.0-py3-none-any.whl Python 3 none any Details

Total release size: 75.5 kB

Release files / code_audit_validator-1.5.0.tar.gz

Download URL code_audit_validator-1.5.0.tar.gz
Size 43.6 kB
Tags Source
SHA-256 checksum
How to use checksums
27720efc727d71c70d746463bda8fa696f15850f7eec4b4b95fbcd12e57e7fdd
BLAKE2b-256 checksum
How to use checksums
5653ab180a58a2635c3725cc956487522a1d800d600be2813c829be008faa22d
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/6.1.0 CPython/3.13.13

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Jun 13, 2026.

Transparency log

Release files / code_audit_validator-1.5.0-py3-none-any.whl

Download URL code_audit_validator-1.5.0-py3-none-any.whl
Size 31.9 kB
Tags Python 3
SHA-256 checksum
How to use checksums
3a4e2dd7ffc7e2e4520460820eceaf9512421b5c61f451fdc96ce57019db2711
BLAKE2b-256 checksum
How to use checksums
5542ce3aad68ebfa4872fb575a083e38d7984c763aca1a9efac021bafb75836c
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/6.1.0 CPython/3.13.13

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Jun 13, 2026.

Transparency log

Release history Release notifications | RSS feed

This release

1.5.0 This release

2 release files

1.4.0

2 release files

1.3.0

2 release files

1.2.0

2 release files

Anthropic, PBC Visionary sponsor Bloomberg Visionary sponsor Hudson River Trading Visionary sponsor Meta Visionary sponsor NVIDIA Visionary sponsor Microsoft Sustainability sponsor Depot Continuous Integration AWS Cloud computing and Security Sponsor Datadog Monitoring Fastly CDN Google Download Analytics Sentry Error logging StatusPage Status page