Bench

Bench / Reading room

The constitution

Eight constraints. Declared, not implied.

Bench enforces a written constitution, a JSON file named bench.json, and its Oracle enforces it as law. Every constraint is declared with an identifier, a severity, and a rationale, so a veto always names the article it rests on. These are the eight constraints in force as of August 2026. The file itself is public: bench.json on GitHub.

Seven constraints carry veto severity: a violation blocks the change before it touches a file. One, test coverage, carries warning severity. Declaring the rules in a file, rather than implying them in a prompt, is the point: the same eight articles bind every change, every session, and the ledger records which constitution hashes ruled on each verdict.

  1. C-001

    No Silent Error Swallowing

    veto

    Every catch block must log, re-throw, or return a typed error. Empty catch blocks are violations. Silent failures compound into untraceable production bugs.

  2. C-002

    Scope Boundary Enforcement

    veto

    A change stays within one coherent scope. Bundling unrelated edits into a single change is a violation. Scope creep is the primary trust failure mode of AI-generated code.

  3. C-003

    Dependency Declaration

    veto

    Every new import or dependency must be explicitly declared. Undeclared dependencies are supply chain attack vectors and reproducibility failures.

  4. C-004

    Type Safety Preservation

    veto

    Existing type annotations must not be removed or weakened. The operative test is whether available precision was discarded, not whether the token Any appears in the diff.

  5. C-005

    Test Coverage for New Logic

    warning

    New functions or branches of logic need corresponding tests, or an explicit justification for deferring them. Governance without verification is theater.

  6. C-006

    No Hardcoded Secrets or Credentials

    veto

    No API keys, passwords, or tokens in source. All secrets load from environment variables or a secrets manager.

  7. C-007

    Governance Pipeline Integrity

    veto

    Changes to the pipeline itself (challenger, defender, oracle, ledger, constitution) must not weaken enforcement, bypass verification, or disable logging. A governance system that can silently weaken itself is not a governance system.

  8. C-008

    Ledger Immutability

    veto

    Entries may only be appended. Editing, reordering, or removing an entry is a violation under all circumstances, with no exception. Tampering with evidence is the highest governance violation.

A floor, not a default

A governed project can stack its own constitution layer on top of the core: new constraints in the reserved P- namespace, and severity_overrides that raise a core constraint's severity. A layer can add and tighten, never weaken. A missing layer is safe, because the floor applies in full, and a malformed or hostile layer fails closed.

Constraints with case law

These articles are not aspirational. C-007 alone has produced vetoes on the record against bench.json, ledger/chain.py, utils/api.py, and pipeline/runner.py, all changes proposed while Bench was building itself under its own law. Every one of those rulings is a hash-chained entry in the ledger, readable with python -m cli ledger.

To see how a constraint becomes a verdict, read what AI code governance is, or start at the procedure itself: challenge, defend, rule, record.