How we verify AI agent output: architecture of deterministic integrity

LLM-as-judge shifts the problem — it doesn't solve it. Here is how Xplore Integrity captures agent work mechanically, builds a provenance graph, and verifies every claim without another model in the loop.

The problem with verifying agents

An AI agent fills a dashboard, writes a report, or answers a high-stakes question. It shows a number — “total exposure $28,000.” It cites a URL. It quotes a snippet. The user sees the result but not the work: did the agent actually read that file? Does the website exist? Does the arithmetic hold? Was the snippet invented?

LLMs make all four mistakes regularly — and confidently self-report that everything checks out.

The industry’s default answer is “LLM-as-judge”: another model reads the output and scores it. This shifts the problem without solving it. The judge hallucinates too, leaves no audit trail, and its errors are indistinguishable from the agent’s. You cannot build trust on something that is itself untrustworthy.

A different foundation

Xplore Integrity takes a fundamentally different approach:

Facts are captured mechanically. Claims are verified against facts.

Everything the agent does through tools — reads a file, fetches a URL, calls an API, publishes a widget — is intercepted by code at the I/O boundary. The agent cannot forge or omit these records. This is the observed zone: trust by construction.

Everything the agent asserts — sources it cites, values it claims, conclusions it draws — enters a separate declared zone with zero trust by default. Verification is the deterministic comparison of the second against the first.

Two zones, one graph

The integrity graph has exactly two kinds of data:

Observed — captured at the tool boundary by our adapters:

Tool calls with arguments and results
File content stored by SHA-256 (content-addressable)
Web pages fetched with full response body
API calls and their payloads
The task prompt and agent configuration

Declared — what the agent says about its own work:

Sources it claims to have used (with quoted snippets)
Values it asserts (with references to sources)
Artifacts it publishes (dashboards, reports, answers)

Hallucinations and errors manifest as structural divergences between zones. A source without a fetch is a dangling reference. A quoted snippet not found in captured bytes is a fabrication. A number that exists nowhere in the observed data is invented. None of this requires understanding the meaning — only comparison.

The verification pipeline

Five steps, all deterministic except one:

Capture — SDK, bridge, or gateway intercepts agent I/O at the tool boundary. Secrets are redacted. Content is stored by hash.
Journal + CAS — Events go into an append-only log (gaps in sequence numbers are themselves facts of lost capture). Content goes into content-addressable storage by SHA-256.
Materialize — A pure function folds events into a provenance graph. No LLM, no randomness, no clock dependency. Rebuilding from the journal produces byte-identical results.
Verify — Policy checks fire per vertex type. Sources get resolution and grounding checks. Claims get value verification and origin policy. Artifacts get slot sufficiency and coverage checks. Runs get integrity and consistency checks. 16 of 17 checks are fully deterministic.
Passport — The output is not a single number (that would be dishonest). It’s a qualified verdict: Verified Trust (the lead metric) capped by Capture Level, qualified by Policy Coverage and Slot Coverage.

What the verifier catches — a real example

We ran a web-research agent on a nuclear risk assessment task. The agent produced a structured report citing multiple sources, with numeric claims about facility data.

The verifier caught:

Dangling source references — three URLs cited in the report that the agent never fetched (the ref_resolution check)
Fabricated snippets — a quoted passage that doesn’t appear in the captured page content (the snippet_grounding check)
Origin violation — a financial figure sourced from a news website when the policy required it from the regulatory database (the origin_policy check)

None of these required an LLM to detect. They are structural facts about what happened versus what was claimed.

Integration without rewriting your agent

The system works at four levels of integration, each with an honest trust cap:

Level	Trust cap	How it works
Instrumented	×1.0	Our SDK wraps your tool-dispatch function. Full I/O capture.
Log-structured	×0.85	A bridge reads your runtime’s structured logs (OpenAI traces, session JSONL). Agent code untouched.
Gateway	×0.7	A proxy sits on the MCP/API boundary. One config change, no code.
Declared	×0.4	The agent pushes claims with provenance. Only external re-checks verify.

Deeper integration means more evidence — and a higher trust cap. But even the lightest integration gives useful, honestly-qualified results.

Beyond verification: security, compliance, training

Once you have a typed provenance graph with mechanical evidence, integrity is just the first consumer:

Security — Origin policies are taint policies. Untrusted content reaching an exec tool is a detected information flow. Reads without influence on output signal exfiltration.

Compliance — The graph is the audit artifact for EU AI Act traceability, SR 11-7 model risk, and GDPR provenance. No separate documentation needed.

Training signal — Deterministic checks generate verifiable rewards for open-ended tasks where RLVR normally can’t reach. Failed subgraphs localize credit assignment to the exact node — better than a scalar reward on the whole trajectory.

The honest limits

Integrity captures everything at the I/O boundary but cannot see inside the model’s reasoning — only its self-report (the declared zone). The observed zone is complete for tool interactions; the declared zone is what the agent chooses to tell us.

Cherry-picking in an open-world context (the agent could have searched for counter-evidence but didn’t) is the hardest case. Slot policies and inventory diff cover the closed world; the open web remains a frontier where active counter-evidence search is the only answer.

And LLM-judge doesn’t disappear entirely — semantic entailment (“does the claim actually follow from the snippet?”) still requires it for one edge type. But it’s localized to a single edge, carries lower weight, and is always qualified by the deterministic checks around it.

Xplore Integrity is available as part of the platform. See the technical architecture or learn how to deploy it in production.