← Docs

How ThoughtProof behaves

A behavior reference for builders integrating verification into an agent.

Not a marketing page and not a full API spec — just the questions you actually ask before wiring a verifier into a loop: what the verdicts mean, what happens when the agent is unsure, what happens on a timeout, how long each product takes, and exactly what comes back.

Verdict semantics On UNCERTAIN Timeout & failure Latency per product What your agent gets back

Verdict semantics

Every product returns one of three verdicts. They are deliberately conservative: the verifier is judging whether an action is safe and defensible, not predicting an outcome.

ALLOW

The reasoning holds up. The action is safe to execute. For most agents this is the only verdict that should proceed to an irreversible step (trade, transfer, write, settlement).

UNCERTAIN

The verifier could not confirm the reasoning is sound — evidence is thin, the thesis is single-dimensional, or the verifiers disagree. UNCERTAIN is not a soft ALLOW. Treat it as "do not proceed as-is": re-plan, gather more context, or escalate (see below).

BLOCK

The reasoning is indefensible — a material flaw, an unmanaged risk, a contradiction. The action should not execute. The response carries the objections that drove the block.

Conservative merge. When a request runs through more than one engine (e.g. Sentinel pre-check then RV), the worst verdict wins: BLOCK > UNCERTAIN > ALLOW. A clean ALLOW from one layer never overrides a BLOCK from another.

What the verdict is NOT

The verdict is about the defensibility of the reasoning, not the direction of the world. A trade can be blocked for accepting unbounded risk and still, by luck, have been profitable. The point of verification is to stop the catastrophically-reasoned action, not to forecast the market.

On UNCERTAIN — re-plan, don't just halt

The naive integration treats anything other than ALLOW as a hard stop. That's safe but wasteful: the agent learns nothing and simply idles. A better pattern, and the one we recommend, is to feed the verifier's objections back to the agent and let it decide once more:

const v = await verify(decision);
if (v.verdict !== "ALLOW") {
  // Hand the objections back to the agent for ONE revision.
  const revised = await agent.replan(decision, v.objections);
  const v2 = await verify(revised);        // independently re-verified
  return v2.verdict === "ALLOW" ? execute(revised) : standDown();
}

In practice the revision is usually one of: size down / add an explicit invalidation, gather the missing evidence the objections named, or stand down entirely when the objections show there's no defensible action. All three are good outcomes — standing down is a correct answer, not a failure.

Bound the loop. Re-plan at most once (or a small fixed N) per decision, and always re-verify the revision through the same independent pipeline. There is no way to "argue past" the verifier — a revised decision earns ALLOW only by being genuinely more defensible, not by being re-submitted. Without a bound, an agent that keeps failing can loop and burn calls.

Timeout & failure handling

Verification sits in front of an irreversible action, so the failure posture is fail-closed: if the verifier cannot return a confident result, the safe default is to not act.

Network / timeout: treat a missing response like a non-ALLOW. Do not execute on a verifier you couldn't reach. Set a client timeout slightly above the product's typical latency (see below) and fail closed past it.
Internal uncertainty: when the engine genuinely can't form a confident verdict it returns BLOCK (fail-closed) rather than a low-confidence ALLOW — a high-stakes decision is never waved through on weak evidence.
Degraded runs: if a verification tier is under-provisioned (e.g. a provider is unreachable), the response is flagged rather than silently downgraded, so you can detect and retry instead of trusting a thinner panel.
Payment (x402): an unpaid x402 request returns 402 with the payment descriptor before any verification runs — handle it as "pay then retry", not as a verdict.

Latency per product

These are real measured engine latencies, dominated by model inference. None of the products is sub-second — verification is a deliberate step, not a free middleware hop. Size your timeouts and your loop frequency accordingly.

Product	Tier	Typical latency	Use it for
Sentinel	Checkpoint	~3–5s	High-frequency pre-execution gate on every agent step
Sentinel	Standard	~13s	Heavier lifecycle checks
PLV	Standard	~5s	Plan/trace faithfulness (compliance, audit)
PLV	Thorough	~15s	Deep multi-stage faithfulness cascade
RV	Standard	~50s	Adversarial reasoning verification at decision points with consequences

Pattern: gate every step with cheap, fast Sentinel; escalate only the consequential decisions to RV. Don't put a ~50s RV call inside a tight loop — reserve it for the moments where a wrong ALLOW actually costs something.

What your agent gets back

A verification response is built to be acted on programmatically and audited later. The exact fields vary per product; the shape below is RV's /v1/check, which is the most detailed:

{
  "verdict": "BLOCK",            // ALLOW | BLOCK | UNCERTAIN
  "confidence": 0.95,            // certainty in the verdict (never 1.0/0.0)
  "objections": [                // the reasons — what your agent acts on
    "Trading against a confirmed multi-timeframe downtrend with 5x
     leverage violates basic risk management...",
    "No stop-loss specified; a 20% adverse move wipes the account..."
  ],
  "modelCount": 3,               // independent providers in the panel
  "verificationProfile": "standard",
  "durationMs": 52107
}

The three things to wire into your agent:

verdict — your control-flow branch (execute / re-plan / stand down).
objections — the actionable content. On a non-ALLOW, these are exactly what you feed back into a re-plan. They're human-readable and specific.
The signed attestation — RV verdicts are signed (EdDSA, verifiable via JWKS); Sentinel and PLV can emit on-chain attestations (EAS, opt-in). This is what makes a verdict auditable after the fact: you can prove a decision was checked and what the verifier said, without trusting the agent's own logs.

Want to see this end to end? The docs walk through a first API call, and our verified trading agent publishes a live block-log of decisions it blocked — each with the objections and the signed verdict.