Verdict overview

A coding agent that sends every task to one frontier model pays frontier prices for work a cheaper model could complete, and it leaves no record of why a given call was made. Cost dashboards report the bill afterward. They do not decide anything.

The usual fix is a router that scores models and picks a winner. That moves the problem rather than solving it. A confident score can still select a model that is stale, unqualified, or excluded by policy, and when a run misbehaves there is no artifact showing which candidates existed and why they were rejected.

Verdict treats model choice as an admission decision first and a preference second. The execution-path optimizer qualifies offers, then selects a strategy by expected complete cost. Legacy selectors can supply evidence, not override that authority.

• Eligibility runs before ranking. A ranker can reorder survivors; it cannot restore a candidate the gates removed.
• Unknown is not healthy. Missing, stale, malformed, or contradictory availability evidence is a named drop, not a pass.
• Every dropped candidate carries a named reason, such as policy, health, capability, stale, or quota.
• Spend policy and authoritative session decisions constrain cost selection. Free preference is policy-specific, not a universal cheapest-model guarantee.
• When nothing qualifies, the request is blocked. There is no silent fallback to a frontier model.

The details are in Architecture and Dynamic model selection.

The repository includes a deterministic fixture that makes one routing decision and names every excluded candidate:

$ verdict quickstart --non-interactive --dry-run
Verdict credential-free quickstart
===================================
Task: Add structured output to the invoice parser
Required capabilities: structured_output, tools
Selected route: demo/frontier-tools
Excluded candidates: 3
Receipt: fixture:issue-35 (deterministic_fixture)
Status: PASS
- demo/no-tools: missing capability: tools
- demo/quota-empty: quota exhausted
- demo/unverified: health unknown

It calls no provider, reads no credentials, and writes no state. The fixture demonstrates capability and availability filtering with deterministic inputs. It is not a run of the live execution-path optimizer or proof of live-provider behavior.

Verdict is an independent project. I designed its architecture and decision records and built the Python reference implementation: eligibility and policy gates, the context-pack compiler, receipts and replay, the CLI and HTTP API, gateway and coding-tool adapters, and the proof tooling that keeps public claims tied to evidence. A TypeScript companion, verdict-node, shares the request contract.

Much of the implementation runs through the autonomous development workflow described in these docs. Agents implement bounded tickets. The workflow's proof gates, not the agents, decide when work is done.

• Status: Shipped
  Eligibility, fail-closed routing, and receipts

  Hard gates, named drop reasons, durable receipts, replay, and the offline proof paths are implemented in the public repository and covered by CI.

• Status: Shipped
  Credential-free fixtures

  The quickstart fixture and local benchmark fixtures are deterministic, and the evidence bundles are digest-verifiable.

• Status: Shipped
  ExecutionEnvelope v1 contract

  Shipped on main; ships in v0.3.0. Python, JSON Schema, and Zod contract definitions with parity checks, plus a fixture corpus and mutation tests.

• Status: Shipped
  Release certification bundles

  Shipped on main; ships in v0.3.0. Automated gate scanning and evidence collection for tagged releases.

• Status: Shipped
  Goal-to-receipt orchestration with independent review

  Shipped on main; ships in v0.3.0. Orchestrated runs project separate implementer and reviewer routes with bounded recovery (ADR-036).

• Status: Shipped
  Route identity in run receipts

  Shipped on main; ships in v0.3.0. Receipts record intended vs executed route for transparency.

• Status: Shipped
  Privacy floor

  Shipped on main; ships in v0.3.0. Restricted and trusted_upstream tasks require explicit restricted_data_routes allowlist; fail closed.

• Status: Shipped
  Acceptance pipeline

  Shipped on main; ships in v0.3.0. Honest, fail-closed gate evidence with credential scanning and explicit pass requirements; threat model and privacy policy documented.

• Status: Experimental
  Live gateway routing

  Admitting free-tier models from a live gateway, proving they respond, and executing through that gateway works against a compatible local gateway. The evidence is dated observation, not a production operating record.

• Status: Experimental
  Coding-tool adapters

  Reversible commands point Claude Code, Codex, Cursor, Cline, OpenCode, and Prime at Verdict. Some IDE settings still need a manual step, so certification is partial.

• Status: Roadmap
  Receipt explorer UI

  A public interface built on the receipt contract is planned. It is outside the current release boundary.

• Status: Roadmap
  Tagged release with full gate evidence

  v0.3.0 release candidate in progress (acceptance gates being completed)

• Status: Roadmap
  OpenJev decision signals

  In progress for v0.3.0: shadow signals plus an opt-in advisory mode that may only reorder candidates that already passed every hard gate. Not live, and no effect on routing today.

• Status: Roadmap
  Codiv provider

  Provider candidate built (identity, failure classes); no live endpoint configured.