Diagrams · Fig. 09

Two verdict surfaces

The screen verdict and the gate verdict are different axes. Neither overrides the other.

Two verdict surfacesTwo 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 the behavioural conformance probe a clearing ALLOW would need is advisory and uncalibrated in v1. 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.ADVISORY SCREEN · BEFORE YOU WIREDID THE EVAL RUN?YESNOclearedcrossed the deny thresholdambiguous or partialno eval on fileALLOWRESERVEDDENYRESERVEDREVIEWPRODUCED AT V1UNVERIFIEDPRODUCED AT V1IN-PATH GATE · DURING THE CALLHOLDthe live contract differs from what you pinned→ PROCEEDthe live contract matches your pinDETERMINISTIC · FAIL-CLOSED · IN THE CALL PATHALLOW and DENY are reserved in the contract, not produced at v1. The conformance probeis advisory and uncalibrated in v1 (calibrated=false), so the screen never clears a tool.Neither surface overrides the other. The screen is a prior; the gate is the decision.
Fig. 09 · 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. the
  conformance probe is advisory and uncalibrated in v1 (calibrated=false), so the
  screen never clears a tool. neither surface overrides the other - the
  screen is a prior, the gate is the decision.
What the figure says

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 the behavioural conformance probe a clearing ALLOW would need is advisory and uncalibrated in v1. 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.

Where this is explained
/methodology/screen
Use this diagram

Licensed CC BY 4.0. Use it anywhere, including commercially. Keep the credit.

Credit line (HTML)

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)
Direct SVG

Standalone image/svg+xml. Vector, editable, no stylesheet needed.

https://mcpindex.ai/diagrams/two-verdict-surfaces/svg

Last reviewed 2026-07-27 · derived live from D3_V1_STATE · never hand-typed

Questions this answers

mcp allow deny review unverified &middot; mcpindex verdict states &middot; mcp trust verdict meaning