Epistemic Engine

The verification layer that proves AI agent decisions before they act.

Comment

Epistemic Engine

Inspiration

AI agents can now review code, write patches, and tell you whether something is safe to deploy. The problem: a confident answer is not a justified decision.

Observability tools are great at answering what did the agent do — every model call, tool execution, and trace. What they can't answer is the question that actually matters before you let an agent act:

Which claims justify this conclusion, what evidence supports them, what contradicts them, and what still needs to be checked?

That gap is what I built Epistemic Engine to close. One principle drives the whole system:

An agent may act only when its critical claims survive evidence, contradiction, and verification.

What it does

Say an AI reviewer looks at a pull request and concludes: "This is safe to deploy."

Epistemic Engine refuses to treat that sentence as a decision. It breaks the recommendation into atomic claims — the build succeeds, existing clients stay compatible, no sensitive data reaches the logs, the migration rolls back safely — and binds typed evidence to each one: diffs, test results, build artifacts, migration checks, agent execution events.

Anything unsupported, assumed, unknown, or contradicted stays visible instead of disappearing into a single confidence number. When a critical claim lacks evidence, the engine plans the smallest useful verification, and a restricted Codex worker writes a targeted test inside a disposable repo checkout. The test runs, and its result becomes new evidence.

A deterministic policy engine then returns one of five outcomes — VERIFIED, VERIFIED_WITH_CONDITIONS, INSUFFICIENT_EVIDENCE, CONTRADICTED, or REJECTED — and issues a content-addressed Decision Certificate: the claims, the evidence on both sides, the verification results, the policy version, and the hashes to reproduce it all.

The demo

The demo ships an intentionally unsafe PR to an orders service. It builds. The tests pass. The AI reviewer says ship it.

The engine disagrees, twice:

  • "Existing clients remain backward compatible" → UNSUPPORTED. Nothing proves an older client can still call the modified endpoint.
  • "No sensitive customer data is written to logs" → CONTRADICTED. The PR adds a log structure containing a customer email field.

It proposes the smallest fix for the first problem: a legacy-client integration test. After human approval, Codex generates it — allowed to touch only tests/ — and the restricted runner executes it. The test fails, exposing the real compatibility break. Deployment is blocked.

A corrected patch restores compatibility and removes the sensitive logging. The checks pass, and the engine issues a fresh certificate.

How I built it

Go control plane — ordered, idempotent event ingestion; claim and evidence processing; contradiction, assumption, and unknown tracking; verification orchestration; deterministic policy evaluation; SSE for live updates; SHA-256 content hashing; certificate generation. PostgreSQL stores everything, with evidence and proofs content-addressed by hash.

Web workspace — Next.js, React, and React Flow put the whole decision on one screen: execution timeline, claim graph, evidence inspector, contradictions, verification progress, policy outcome, certificate. Every element answers one of three questions: what is claimed, why it's supported or contradicted, and what must happen before the action may continue.

Deployed end-to-end on Google Cloud.

How OpenAI is used

GPT-5.6 with Structured Outputs (Responses API) proposes the epistemic objects: atomic claims, importance, evidence relationships, contradictions, assumptions, unknowns, and bounded verification plans. Its output is a proposal, nothing more — it must pass JSON Schema validation, domain validation, deterministic policy rules, and permission checks before it counts.

Codex writes the verification tests, under strict constraints: one explicit objective, restricted repo context, a writable-path allowlist, timeouts, resource limits, and no access to the deployment environment.

The Agents SDK powers the Python reviewer in the demo — execution, tool calls, approval pauses, resumable runs, and export of the observable events the engine ingests.

The architectural line I refused to blur: AI proposes, application code decides. Permissions, allowlists, policy evaluation, hashing, and final authorization live in deterministic Go. No hidden chain-of-thought is requested, stored, or displayed — the system works only with observable artifacts and independently executable verification.

Challenges I ran into

Defining "verified." A model saying a claim is "87% true" is theater. Instead, the engine computes an explainable evidence-support score — S = coverage × quality × independence × freshness × scope-match × verification-strength − contradiction-burden — that describes the strength of evidence within a declared scope, never a probability of truth. And critical rules override the number: an unresolved contradiction on a critical claim blocks the action no matter how good the aggregate score looks.

Preserving contradictions. Language models instinctively smooth conflicting information into one fluent answer. The engine keeps disagreement as a first-class graph edge — one piece of evidence supports a claim while another contradicts it, and both stay on screen. That's what lets the system block, abstain, or demand more evidence instead of hallucinating consensus.

Making generated code safe. Generated tests are only useful if they can't do damage: human approval gates, disposable checkouts, writable-path restrictions, execution timeouts, restricted networking, and content hashes on every generated artifact.

Keeping decisions reproducible. A decision shouldn't change because an event arrived twice or JSON fields serialized in a different order. Idempotent event IDs, canonical serialization, versioned policies, and content-addressed certificates make any change to the decision inputs detectable.

Accomplishments I'm proud of

I built a complete decision-verification loop, not another observability dashboard: recommendation → claims → evidence → contradictions → bounded verification → deterministic policy → reproducible certificate.

The part I care about most: final authorization is never delegated to a language model. AI structures and investigates the decision; application-owned policy decides. There's also a deterministic local analysis mode, so the core workflow runs reproducibly without a model call per run.

What I learned

Tracing and verification are different layers. A trace proves the agent called a testing tool — it doesn't prove the test was relevant to the critical claim, covered the right scope, or that contradicting evidence didn't exist.

Beyond that: evidence belongs to individual claims, not final answers. Contradictions and unknowns deserve to be first-class objects. Verification should be proportional to risk. And a reproducible Decision Certificate turns out to be far more useful than any confidence score.

Working through these constraints also produced a design for the Epistemic Protocol — a vendor-neutral format for exchanging claims, evidence, contradictions, verification results, and decisions between agents, pipelines, and compatible control planes.

What's next

Making the engine trivial to adopt in any agent or delivery workflow: the Epistemic Protocol spec, Go/TypeScript/Python SDKs, a configuration-driven CLI, GitHub Actions and CI adapters, embeddable UI components, and an MCP adapter for ChatGPT and other assistants.

The long-term vision fits in one line:

Instrument once. Use any compatible engine. Display decisions in any interface. Gate any autonomous workflow.

Built With

Share this project:

Updates