Release Gate

release-gate

The independent admission controller for AI systems.

Release-Gate combines code-level agent risk, external evaluations, runtime traces, governance evidence, verification results and human approvals into an auditable PROMOTE / HOLD / BLOCK decision, without requiring teams to replace the tools that produced the evidence.

A PROMOTE means the candidate meets the declared release policy, with the evidence and the gaps the decision lists. It is never a statement that a release is safe.

[PyPI version] [License] [Benchmarks] [Security Policy]

 code-level agent risk     SARIF from your scanner, or release-gate's own ──┐ external evaluations      promptfoo, ProofAgent, red teams, eval harnesses ─┤ runtime traces            OpenTelemetry, Langfuse, Arize-Phoenix ───────────┤   one candidate state, verification results      tests, provers, model checkers ───────────────────┼─▶ one claim graph,      ─▶ PROMOTE / HOLD / BLOCK governance evidence       governance.yaml, the pinned AIBOM ────────────────┤   one declared policy      + the Admission Report human approvals           reviews and approvals of this exact candidate ───┘

Where it sits

Each of these answers a different question. Release-gate reads the others' results as attributed evidence and answers the last one.

It does not re-run, re-grade or replace any of them. A promptfoo result stays promptfoo's, a scanner's finding stays the scanner's, and the Admission Report says which evidence release-gate produced itself and which it read from another tool. Its own agent-code scanner is one producer among them, not the product.

What a decision says

Unknown is never a pass. Every decision states what was not assessed, and evidence about another state of the release does not count for this one. The decision is deterministic from the declared policy and the evidence. Models can be asked to read evidence, and their readings never decide.

How it works

flowchart LR  subgraph own["Release-gate's own checks"]    direction TB    o1["AST / taint scan"] ~~~ o2["PR diff"] ~~~ o3["governance"] ~~~ o4["trace validation"] ~~~ o5["loop sim, agent score"]  end  subgraph ext["Your tools"]    direction TB    e1["evals, red teams"] ~~~ e2["traces, SAST"] ~~~ e3["proofs, reviewers"]  end  sem["Semantic verifier<br/>bounded questions<br/>UNKNOWN on any failure"]  case["AssuranceCase<br/>claims, evidence, assumptions,<br/>contradictions, counterexamples,<br/>failed branches, coverage, independence"]  own --> case  ext --> case  sem -. "a reading, never a verdict" .-> case  case --> policy{"declared<br/>policy"} --> out["PROMOTE / HOLD / BLOCK"]

The invariant. Release-Gate may generate evidence, ingest evidence, normalize evidence, compare evidence, semantically interpret bounded evidence, and determine whether evidence satisfies policy. It must never pretend that one model, one scanner, one evaluator, one score, or one successful test establishes universal truth.

Each claim ends in one status, and the declared policy says which statuses admit:

flowchart LR  ev["the evidence<br/>on one claim"] --> claim{"a claim"}  claim -- "a valid counterexample<br/>(outranks any support)" --> c["CONTRADICTED"]  claim -- "a bound proof, or two<br/>independent groups of checks" --> e["ESTABLISHED"]  claim -- "support short of that" --> s["SUPPORTED or<br/>PARTIALLY_SUPPORTED"]  claim -- "only support about<br/>another state" --> u["UNSUPPORTED"]  claim -- "inconclusive or unreadable" --> k["UNKNOWN"]  claim -- "nothing bears on it" --> n["NOT_ASSESSED"]

No score is an input, and copies of one test from one session count once. ARCHITECTURE maps each box to its code. tests/test_product_invariant.py executes every clause of the invariant.

Try it

pip install release-gaterelease-gate assure your-run.jsonl        # no config file, no YAML, no account

That works on an OpenTelemetry trace, a Langfuse export, a promptfoo result, or release-gate's own record format: the shape is detected, not declared. You get a verdict, what a person has to look at, and what would resolve it.

In a pipeline, the release's claims and everything the pipeline produced decide together:

release-gate assure release.jsonl --evidence evidence/ \  --methodology [email protected] --admission

Exit 0 PROMOTE, 10 HOLD, 1 BLOCK. CI templates cover GitHub Actions, GitLab, Jenkins, CircleCI and Azure Pipelines.

Release-gate's own checks are evidence too. The --json of pr, verify, loop-sim and agent-score is read like any tool's. Here is a release that promotes on its own, plus one trace that called a tool its governance file forbids:

# examples/evidence/first-party/verify.json was written by#   release-gate verify governance.yaml --trace trace.json --iteration 2 --cost 0.06 --jsonrelease-gate assure examples/agents/02-release-promoted.jsonl \  --evidence examples/evidence/first-party/verify.json \  --methodology [email protected] --admission

  Decision     BLOCK               BLOCK under [email protected] and rg-resolution@1: 2 blocking condition(s) established — RG-CONTRA-002 (contradictions, on rg-trace:run-2291); RG-VERIF-002 (claim_status, on rg-trace:run-2291)

The block comes from the failed trace check, not from the verifier's own ROLLBACK. That verdict is recorded and decides nothing.

Nothing to install first: drop a run into the browser demo — it runs this same engine, and its three sample runs are the files in examples/assurance/, byte for byte.

Or run the worked examples. In six tools, one release, one decision, five tools report good news and the decision still holds, for the reason it prints. Five agent runs cover an OpenTelemetry trace, a promptfoo eval, a destructive migration, a research swarm, and one that promotes:

python examples/demo-admission/run_demo.pycd examples/agents && ./run-all.sh

What each one demonstrates →

The product's acceptance test is one more. One enterprise release, end to end admits AI-generated code whose tools move money, over every kind of evidence. It answers each question a release owner asks, and shows that no score, model judgment or test count outvotes the counterexample it contains:

python examples/acceptance/run_acceptance.py

Three things a scanner or a score cannot do

1. It reduces machine work to a list a person can actually read

Two million records is not reviewable. A score over two million records is not reviewable either — it is one number standing in for a judgement nobody made.

Release-gate returns a bounded set of things that need a human, derived from which claims the decision actually rests on:

Every figure in that table is measured by the test suite, not written here by hand — a claim that drifts from the implementation fails a test.

Criticality comes from reachability in the claim graph, never from volume — a claim one agent emitted once is exactly as load-bearing as one four hundred agents discussed.

And a shorter list is not a better case. That is a property in code that cannot return anything else, because the one dangerous way to read this table is that a smaller number is a win. It can equally mean detection got worse.

2. Every verdict says what it did not check

This is the part most tools skip. A pass that doesn't state its own coverage is indistinguishable from a pass that never looked.

WHAT WAS ASSESSED  [    assessed]  input_integrity: the input file was hashed by release-gate  [    assessed]  record_mapping: 6 of 6 record(s) mapped; 0 skipped  [NOT_ASSESSED]  execution_reconstruction: no execution graph was reconstructed  [NOT_ASSESSED]  replication: no verification attempt names a target  [NOT_ASSESSED]  adversarial_review: no verifier set out to disprove this

NOT_ASSESSED is a first-class answer, kept apart from "we looked and found nothing" everywhere in the engine. So is UNKNOWN, and so is a refuted check as against an unresolved one. Collapsing those is how a gap comes to read as a clean bill of health.

3. When it holds, it returns the work order

A gate that only says no is a nag. Each item comes with what would close it:

[BLOCK]    RG-ACT-001    'execution_reconstruction' is stated as NOT_ASSESSED             → supply the run's trace or tool-call log
[ADVISORY] RG-PROV-002   all evidence traces to a single producer             → add evidence from an independently-operated producer

That list is machine-readable (--json), so the next agent run can go and get the evidence rather than a human re-reading the case to work out what was missing.

What it will not tell you

Not that a release is safe. Not that a result is guaranteed correct. Not that the gate is unhackable — twenty attacks run against the engine itself and one is recorded NOT_DEFENDED with what bounds it instead. Not that a case is uncontested, that hallucinations are solved, or that an expert has been replaced: the output is a list of what needs a person.

Each refusal is a property in code that cannot return anything else. docs/POSITIONING.md names every one with the line that enforces it.

From Python

import release_gate as rg
case = rg.create_case(objective="Deploy generated migration", subject=migration)case.add_execution(trace)                       # the steps, or a native tracecase.add_verification(test_result, method="TEST_SUITE", outcome="PASSED",                      verifier="ci://pytest", against_subject=True)
decision = case.finalize()     # PROMOTE / HOLD / BLOCK, with its coverage attachedprint(decision.required_evidence)

The same four calls carry one agent's migration and a ten-thousand-worker research run. Not two products with a shared name — one code path: 346 engine functions are common to both, 87% of everything the single-agent path touches.

Configuration

Nothing is required to run. A methodology is what turns structure into a verdict — without one, release-gate reports everything structural it can see and holds, because "is this enough?" is a domain question and inventing an answer would be claiming a standard it does not have.

release-gate assure --list-methodologiesrelease-gate assure run.jsonl --methodology [email protected]

One input, four yardsticks, four answers — each naming what it is missing:

Organisation config (--config) layers your own standards on top and can only ever tighten. The methodology, the resolution policy (--resolution-policy: what it takes to establish a claim, what a counterexample does) and the organisation config together are the declared release policy a PROMOTE is measured against. Each is digested into the case.

📖 Full walkthrough: inputs, outputs, and what to configure →

What feeds the decision

The admission decision above is the product. These produce or carry its evidence, and each is documented in its own place:

Docs

Development

git clone https://github.com/VamsiSudhakaran1/release-gatecd release-gate && pip install -e '.[dev]'pytest -q

License

MIT — see LICENSE.