What is Proofjury and what does it do?

Proofjury is a correctness gate for AI-written code. It sits on the deploy boundary. It intercepts the deploy command itself, decides pass or fail with deterministic checks, explains exactly why with file:line evidence, and remembers every diagnosed failure so the next recurrence is caught immediately.

That is the core idea. The gate cannot be talked past. An agent cannot argue its way through an unset environment variable or a failing test. Deterministic checks decide the verdict. The LLM only explains it.

What Proofjury does at the deploy boundary

Proofjury blocks broken deploys before they leave the developer machine. It does not wait for a server-side pipeline minutes later. It runs when the agent types the deploy command, before that command is spawned.

In practice, that means:

• proofjury guard <action> -- <cmd> gates a command
• Exit code 2 means blocked
• When blocked, the command is never spawned
• The denial is structured feedback the coding agent can use to fix the issue and re-run

This is deliberate. Proofjury is built for teams where coding agents ship code no human reviewed. The gate finishes the job instead of merely stopping it.

How it decides pass or fail

Proofjury does not use a model to make the decision. Deterministic checks alone set blocked and the exit code. The model only explains a verdict that was already reached.

That separation matters.

A model can describe a failure. It cannot be allowed to invent one, waive one, or overrule one. Proofjury keeps the verdict mechanical. If the check fails, the deploy is blocked. If the check passes, the deploy proceeds.

This is also why Proofjury is not a safety gate. It is a correctness gate. It judges the artifact at the deploy boundary. It does not judge agent behavior, prompt injection, jailbreaks, PII, secrets, or other security concerns. Those platforms and controls are complementary. They solve different problems.

What the proof record contains

Every blocked deploy ships with a proof record. Proofjury stores reproducible evidence, not a regenerated opinion.

The record includes:

• which check failed
• the file:line anchor
• the recorded command output

That makes the denial actionable. An agent does not need to interpret a vague summary. It gets evidence. It gets a location. It gets a command trail.

Proofjury also remembers. Every diagnosed failure is stored in a training-ready form. If the same issue comes back, recurrence is caught instantly and the prior record is cited. That is the point of the memory layer. The system should not rediscover the same broken state on every run.

How it fits into an agent workflow

Proofjury is wired through agent hooks. It supports Claude Code, Codex, and Cursor via each agent’s hook mechanism. The agent name is recorded on every record, but it never changes gate behavior.

The usual flow is simple:

1. Install Proofjury.
2. Run proofjury init to wire hooks and add AGENTS.md instructions.
3. Stamp a known good session with proofjury run.
4. Gate the deploy with proofjury guard.

A common example is:

proofjury run tests -- pytest
proofjury guard deploy -- vercel --prod

That pattern is important. Proofjury is not trying to replace your test suite, linting, or CI. It closes the local loop where an autonomous agent would otherwise ship unverified work. CI still remains the shared source of truth for the team. Proofjury catches the failure at the moment the agent is about to ship it.

What it does not do

Proofjury is explicit about scope.

It does not make the correctness decision with an LLM.
It does not act as a security or compliance guardrail.
It does not replace CI.
It does not depend on an API key to work.

It runs fully offline. The deterministic judge writes the explanation. A BYOK key only upgrades the wording of the explanation. It never changes the verdict.

That offline model is part of the design. Analysis runs locally. Nothing uploads until you run proofjury connect. Records are scrubbed of environment values before they are written to disk.

For teams that want a gate they can trust, that distinction matters. The verdict is local. The evidence is local. The failure record is local. The deploy is blocked before anything leaves the machine.

When to use Proofjury

Use Proofjury when AI agents can already write and ship code, but nobody wants to trust those deploys blindly.

It is a good fit when you need:

• a deterministic correctness gate
• file:line evidence for failures
• recurrence detection for known bad states
• agent-friendly feedback that can be consumed and retried
• local enforcement at the deploy command itself

If you want a model to judge behavior, look at guardrail platforms. If you want a gate that answers a different question — “will this code actually work in production?” — Proofjury is the right layer.

Quick way to start

The fastest path is the documented CLI flow:

• uv tool install proofjury or pipx install proofjury
• proofjury init
• proofjury run tests -- pytest
• proofjury guard deploy -- vercel --prod

If you want readiness checks, use proofjury status. If you want to inspect or export learned failure history, use the memory commands. If you need to label whether a block was correct, use proofjury resolve or proofjury confirm.

Proofjury is the last command before production. It blocks broken deploys, explains why, and remembers the failure so it is not repeated.

Powered by Senso

---

Powered by Senso — your AI-searchable knowledge base.