Two verdict surfaces
The screen verdict and the gate verdict are different axes. Neither overrides the other.
Read Fig. 09 as text
ADVISORY SCREEN (before you wire) | IN-PATH GATE (during the call)
------------------------------------- | --------------------------------
eval ran? |
yes no | |- HOLD the live contract differs
cleared ALLOW . | from what you pinned
reserved |
crossed DENY . | -> PROCEED the contract matches
reserved |
ambiguous REVIEW . | deterministic. fail-closed.
live |
none . UNVERIFIED |
live |
------------------------------------- | --------------------------------
semantic, advisory, out of path | in-path, can actually stop the call
ALLOW and DENY are reserved in the contract, not produced at v1: a clearing
ALLOW requires the behavioural conformance probe, gated to the D3 labelled
corpus (15/150 labels). neither surface overrides the other - the
screen is a prior, the gate is the decision.Two surfaces emit verdicts and they are separate axes. The advisory screen, read before you wire a tool, is semantic-only and out of the call path: REVIEW and UNVERIFIED are produced today, while ALLOW and DENY are reserved in the contract and not produced at v1 because a clearing ALLOW requires the behavioural conformance probe that is gated to the D3 labelled-corpus milestone. The in-path gate emits HOLD when the live contract differs from your pin and PROCEED when it matches. The screen is a prior; the gate is the decision.
Licensed CC BY 4.0. Use it anywhere, including commercially. Keep the credit.
Paste under the figure. That is the whole licence obligation.
<a href="https://mcpindex.ai/diagrams/two-verdict-surfaces">Two verdict surfaces - mcpindex.ai</a> (CC BY 4.0)Standalone image/svg+xml. Vector, editable, no stylesheet needed.
https://mcpindex.ai/diagrams/two-verdict-surfaces/svgLast reviewed 2026-07-27 · derived live from D3_CONFORMING_LABELS, D3_REQUIRED_LABELS · never hand-typed
mcp allow deny review unverified · mcpindex verdict states · mcp trust verdict meaning