Inspecting the effective policy 

Would this be allowed? 

Pick a configuration, a tool and — optionally — a backend user, then press Simulate. The tab runs that call past the five gates listed below and reports one verdict plus each gate's own answer (ADR-157, ADR-167).

The verdict is one of three:

Allowed
All five gates permit the call and it would run unattended.
Allowed, after a human approves
All five gates permit the call, and the tool is approval-bound (ADR-134): the run suspends and waits for a decision before it executes. Folding this into Allowed would hide the axis at exactly the moment it decides, so it is its own outcome.
Blocked
At least one of the five refuses. The table says which.

Five gates are asked, each through the service the runtime itself calls:

Gate What it decides Depends on the actor?
Configuration access (ADR-070) whether this backend user may use this configuration at all, given the backend groups it is restricted to Yes — through the user's group membership
Tool gate (ADR-094) registered, enabled, permitted, within the configuration's tool groups, within the provider trust zone's data-class ceiling Yes — through the tool's requiresAdmin()
Input-context gate (ADR-144) whether the snippets and skills this configuration injects may reach the trust zone it can send to No
Routing (ADR-142) whether any model resolves for a tool-calling run at all No
Human approval (ADR-134) whether the tool is bound to an operator decision No

Two axes are actor-scoped, and the table says so. Routing reads the model catalogue with enable-fields ignored and no user context, the input-context gate compares a configuration against a trust zone, and the approval requirement is a property of the tool's own declaration. The two that read the user are the tool gate, through the tool's requiresAdmin(), and configuration access, through the backend groups the record carries. A picker that implied five per-user answers where there are two would be worse than no picker.

The configuration selector lists every active configuration and applies no membership filter, so a group-restricted configuration paired with a non-member is a pairing the picker makes easy to produce. The tab asks ConfigurationResolver the same question the runtime asks it, so that pairing reads Blocked here and names the restriction as the reason (ADR-167).

Two things that can stop a real call are not asked here, so Allowed does not promise them: the budget check and the guardrail pipeline. Both decide on the call itself — the remaining spend, the text of the prompt — and a picker supplies neither. The budget check has a second reason, stated in ADR-167: it reports usage and limit numbers only when it refuses, so "close to the limit" and "no data" cannot be told apart from "plenty left", and a row saying otherwise would be a measurement nobody took.

For a criteria-mode configuration the input-context gate is stricter here than at run time. The simulation asks the gate without a serving model, so the gate takes the zone from the configuration itself, and for a criteria-mode record that is the fail-closed externalGlobal. A real call has resolved its model by then and is judged against that model's provider zone (ADR-149). When routing picks a local or privately hosted model, the simulation can therefore read Blocked for snippets or skills the real call sends. For the sources the configuration injects, the input-context row never reads Allowed where the gate refuses at run time (ADR-157). A caller can also attach snippets or skills to one run (ADR-164). The simulation does not see those, and they can make the real call stricter. To check the model routing would pick, read Why this model? below.

The actor picker is not impersonation. The selected backend user is resolved read-only through the same seam a queue worker uses to authorise for the user who queued its work (ADR-083): the uid is looked up, the fresh database record supplies the permission surface, and the gates are asked. No session is switched, nothing executes as that user, and nothing is written. Privilege comes from the record, so the picker cannot grant rights the account does not have — and a uid that no longer resolves, because the account was deleted or disabled, produces a stated refusal rather than a silent fall back to your own rights.

A simulation is not recorded. The runtime writes a governance event when it blocks a call; a simulation blocks nothing, so writing one would put rows into the audit for calls that never happened. The trade is deliberate and it has a cost: "who checked what, and when" cannot be answered from the audit. See ADR-157.

Observe mode is visible on both gates. A configuration the input-context gate refuses while tools.dataClassEnforcement is observe is reported as permitted and refused: the send proceeds and the refusal is recorded. Reading only "no exception" would have called that allowed.