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
Every product returns one of three verdicts. They are deliberately conservative: the verifier is judging whether the submitted package is defensible against mandate and evidence — not predicting an outcome, and not authorizing execution.
No blocking objection was found in the submitted decision package, within the scope of this check. Execution remains bound to the integrating system’s own controls and release rules. ALLOW is not a guarantee that the action is safe to execute.
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).
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.
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.
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
402with the payment descriptor before any verification runs — handle it as "pay then retry", not as a verdict.
Latency per product
These figures are integrator guidance (how to size timeouts and loop frequency), not an SLA and not a percentile from a named public measurement run. None of the products is sub-second — verification is a deliberate step. Fail closed if the call exceeds your timeout.
| Product | Tier | Integrator guidance | Use it for |
|---|---|---|---|
| Sentinel | Checkpoint | typically a few seconds | High-frequency pre-execution gate on every agent step |
| Sentinel | Standard | typically longer than Checkpoint; size timeout in the tens of seconds | Heavier lifecycle checks |
| PLV | Standard / Thorough | multi-second to tens of seconds depending on cascade depth | Plan/trace faithfulness (compliance, audit) |
| RV | Standard | typically tens of seconds — do not put inside a tight loop | Adversarial reasoning at decision points with consequences |
| DQL | Standard (only tier) | See note | Five-axis verify (intent · scope · risk · consistency · reversibility) via single cascade |
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.