A boundary case in agent verification — what transaction policy alone may not capture.
Mature agent-payment stacks increasingly enforce transaction policy: allowlisted routers, spend caps, slippage limits, counterparty rules. That is necessary — money should not move outside bounded authority.
But those transaction-policy checks do not necessarily answer a different question:
Was the decision to act justified in the first place?
This is a boundary case from our verification pipeline — an agent whose action passed a representative deterministic authorization policy, and still shouldn't have been proposed.
An agent proposes a token swap under a user's mandate. We paired the proposed action with a representative deterministic authorization policy — the kind of populated checks a competent wallet or authorization service enforces:
| Check | Result |
|---|---|
| Router allowlisted | ✓ pass |
| Amount ≤ cap (500 USDC) | ✓ pass |
| Slippage ≤ 2% | ✓ pass |
| Recipient is own wallet | ✓ pass |
Representative policy result: ALLOW. A stack that evaluates only these populated transaction-policy fields could consider the action eligible to proceed toward signing.
The user's mandate wasn't just spend limits. It also required:
The agent's proposal: quote was 12+ minutes old. Portfolio drawdown: −9.5%. The breakout claim: not supported by the evidence package it cited.
The verifier's native outcome was UNCERTAIN. At the integration layer, we interpreted the structured objections as OBJECT: the action should not proceed unchanged, and the agent must replan. Some objections were revisable; the drawdown breach required standing down until the condition cleared.
STALE_EVIDENCE — quote age 760s vs. a 60s mandateMANDATE_DRAWDOWN_BREACH — 9.5% vs. an 8% risk-on limitUNSUPPORTED_CLAIM — no supplied evidence supported the breakout assertionEVIDENCE_CONTRADICTION — the cited portfolio state contradicted the "healthy" thesisThe agent replanned to HOLD and removed the swap from the revised decision package. A second verification pass evaluated that HOLD package — not the original trade — and preserved the key distinction: accepting the stand-down did not approve the original action. In an enforced integration, an objected action does not proceed toward approval, signing, or settlement.
The original and revised decision packages are hash-linked inside an Ed25519-signed validation artifact. The artifact references the agent's ERC-8004 identity and explicitly states do_not_convert_to_reputation: true. One bad proposal is evidence about one decision — not a permanent judgment about the agent.
Two different questions live in every agent action:
May this transaction execute? — policy, authz, wallets. Deterministic, necessary, well-served.
Should this decision have been made? — mandate adherence, evidence freshness, claim support. This is what verification is for.
An agent can be registered, "trusted" on a score, and fully inside spend limits — and still propose an unjustified action. Trusted-agent context does not authorize the next act. A permitted transaction is not a justified decision.
Some mandate checks — such as freshness windows or drawdown limits — can also be enforced deterministically when trustworthy values reach the authorization request. We treat those checks as overlap rather than claiming an exclusive lane. ThoughtProof focuses on the open-ended boundary: claim consistency, evidence support, structured objections, and replan.
Freshness is harder than it looks. If verification itself takes 20–45 seconds, a 60-second quote window can't mean "60 seconds old at settlement" — that punishes verifier latency, not agent behavior. The correct design: freshness is evaluated at decision time (was the agent's evidence fresh when it decided?), with a separate, wider TTL enforced deterministically at the execution edge — where signing can still be stopped, not inside a slow verifier.
We wrote both constraints down as ADRs. They'll matter to anyone building this layer.
For each decision, we can emit a signed validation artifact that:
It is evidence that validation occurred — not a credit score, and not a substitute for the pre-execution gate.
Mandate + supplied evidence in. Machine-readable outcomes, structured objections, and signed validation receipts out — before consequential actions proceed toward execution.