A Polygraph engine

polygate — the merge gate unverified stateful code can't get past

Verification only protects you if it runs on every change — including the ones nobody re-verified. polygate wires the Polygraph gates into your CI/CD pipeline: every merge request is replayed, model-checked, and compatibility-gated before it can touch a protected branch, with no API key anywhere near the merge path.

The pipeline

What goes in, the stages it runs, what it leaves behind. Step through the stages to trace the run.

fig 8
polygate
the merge gate unverified stateful code can’t get past
Three jobs, one trust boundary. The gates that block a merge are deterministic and keyless; the single job that calls a model is manual and protected.
enforce in ci/cd
01
Merge request
Every change — including the ones nobody remembered to re-verify.
02
keyless
Hash staleness
A content-hash check catches code that changed without re-verification. There is no way to skip it and no credential involved.
03
blocking
polygraph-check
Exhaustive model checking and trace replay against the committed artifacts. Deterministic, free, and on the merge path.
04
the only key
regenerate-specs
The one job that bears organizational keys: manual, protected branch only, masked variables, triggered deliberately by a maintainer.
05
keyless
push-artifacts
Whitelisted hashes and verdicts go to the control plane, so every downstream consumer can prove what was verified, when, and against which exact bytes.
consumes
merge request · committed artifacts + content hashes
produces
merge verdict (blocking) · published hashes and verdicts
A gate is only as good as its failure modes. A stale artifact fails the hash check, so an edit cannot merge unverified; a doctored manifest still dies at the exhaustive model check.

How it works

Three jobs, one trust boundary. The gates that block a merge are deterministic and keyless — the single job that calls a model is manual, protected, and the only place a credential lives.

1

polygraph-check — on every merge request

Keyless and deterministic. A content-hash staleness check catches code that changed without re-verification, then exhaustive model checking and trace replay run against the committed artifacts. No credentials, no model call, no way to skip it.

2

regenerate-specs — manual, protected branch only

The one job that bears organizational keys, triggered deliberately by a maintainer via masked variables. Specification generation is the only step that costs a model call — everything that gates a merge stays free.

3

push-artifacts — keyless publication

Whitelisted hashes and verdicts are pushed to the control plane, so every downstream consumer can prove what was verified, when, and against which exact bytes.

Fits with: polygate is where the rest of the toolchain becomes policy — it runs the polygraph replay and model-check gates and the polyvers compatibility gates in the pipeline itself, so "verified" stops being a habit and becomes a branch protection rule.

polygate on GitHub ↗

Why it holds

A gate is only as good as its failure modes. polygate is designed so the cheap paths are the trusted ones.

Verification as a habit

  • Someone forgets to re-run the checks
  • Keys leak into every pipeline job
  • A doctored manifest slips through

Verification as a gate

  • Stale artifacts fail the hash check — the edit can't merge unverified
  • Merge-path jobs are keyless by construction
  • A manipulated manifest still dies at the exhaustive model check