Docs

ThoughtProof validates whether a proposed agent action is justified by its mandate and the evidence supplied — before separate systems authorize and execute it. This page covers what you send, what you get back, and how to build against it.

New to the category? What decision validation is explains where this control sits relative to policy engines, security scanning, and in-loop critics.

Which API to call

Full request and response schemas, authentication, MCP configuration and the JavaScript SDK live in the endpoint reference. The published MCP connector — Desktop / CLI stdio, thoughtproof-mcp@0.3.2, hero tools verify_before_action / verify_decision — is on the DQL product page. Measured latency per product and tier is in the behavior reference.

The decision package

Validation runs against a bounded package, not against your agent's whole conversation. Four things go in:

• Mandate — the constraints the decision must satisfy. Risk limits, freshness requirements, required evidence, scope. This is what "justified" means for your workflow, stated explicitly.
• Action — the specific proposal being checked: the trade, the release, the submission.
• Evidence — what the agent is relying on. Quotes, prices, test results, sign-offs, citations.
• Provenance — where the evidence came from and when.

The quality of the outcome depends on the quality of the mandate. A package with no stated constraints gives the verifier nothing substantive to check against.

Outcomes

Every product returns one of three native, machine-readable outcomes:

• ALLOW — the reasoning holds against the supplied mandate and evidence.
• UNCERTAIN — the verifier could not confirm the reasoning is sound. This is not a soft ALLOW. Re-plan, gather context, or escalate to a human.
• BLOCK — the reasoning did not hold. The response carries the objections that drove it.

If the agent replans in response to objections, the revised proposal is a new package and is validated on its own terms. A pass on the revision never retroactively approves the original action.

Failure posture

Validation sits in front of an irreversible action, so the default is fail-closed: if you cannot get a confident result, do not act.

• Timeouts and network errors: treat a missing response like a non-ALLOW. Set your client timeout above the product's typical latency and fail closed past it.
• Internal uncertainty: when an engine cannot form a confident verdict it returns a stop rather than a low-confidence ALLOW.
• Both BLOCK and UNCERTAIN stop execution in a fail-closed integration. Teams that keep a human in the loop typically route UNCERTAIN to that person rather than treating it as a pass.

See the behavior reference for verdict semantics, timeout handling and per-product latency in detail.

Audit trail

Select decisions can be recorded in a signed validation artifact that references the specific package evaluated.

• RV verdicts are signed with EdDSA and verifiable via JWKS.
• Sentinel and PLV can emit on-chain attestations (EAS). This is opt-in and not issued by default.
• Artifacts describe one decision. They carry do_not_convert_to_reputation and are not intended to be aggregated into an agent score.

An artifact records what the verifier was given and what it returned. It does not prove the agent's intent, and it does not prove that facts asserted in the evidence were true.

Research: the PoT deliberation protocol

Background on the multi-agent research work the validation products grew out of. It is not one of the four APIs above and is not a supported product surface.

Why self-verification is weak

Asking a model to check its own output shares the architecture that produced it. Models trained on overlapping data with similar architectures share systematic blind spots, and self-reported confidence tracks accuracy poorly. Majority voting across similar models inherits the same correlation problem — agreement between correlated systems is not independent confirmation.

A dedicated critic agent, tasked with examining reasoning quality rather than voting on conclusions, is structurally different from another vote. That distinction is the design principle behind the products.

Five-stage pipeline

Epistemic Blocks

A block is a versioned, signed record of a deliberation: the normalized query, every proposal with model provenance, every critique, evaluation scores, and a synthesis with explicit uncertainty. Blocks are immutable once signed, chainable, and stored locally by default. Where models disagree, the block preserves the minority position rather than forcing consensus.

Provider neutrality

The protocol's design constraint is independence from any single model provider: a verification layer operated by a model vendor evaluates its own product, and single-vendor audit trails are fragmented by construction. The protocol enforces model diversity and down-weights contributions from over-represented models.

Bring your own keys

The pot-cli reference implementation runs with your own provider API keys, so deliberation traffic goes directly between you and the model providers you have chosen, and you pay those providers at their rates.

Running it

npm install -g pot-cli

# Set your own provider keys
export OPENAI_API_KEY="..."
export ANTHROPIC_API_KEY="..."

# Run a deliberation
pot run "Your question here"

# View the resulting Epistemic Block
pot blocks list
pot blocks show <block-id>

• npm package (MIT licence)
• support@thoughtproof.ai