---
title: "Inspecting the effective policy"
manual: "LLM Foundation"
version: "main"
permalink: "https://docs.typo3.org/permalink/netresearch/nr-llm:inspecting-the-effective-policy@main"
source: "Administration/GovernanceSimulator.rst"
rendered: "2026-11-12T15:41:35+00:00"
---

# Inspecting the effective policy {#inspecting-the-effective-policy}

## Would this be allowed? {#administration-governance-simulator}

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](https://docs.typo3.org/permalink/netresearch/nr-llm:adr-157@main), [ADR-167](https://docs.typo3.org/permalink/netresearch/nr-llm:adr-167@main)).

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](https://docs.typo3.org/permalink/netresearch/nr-llm:adr-134@main)): 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](https://docs.typo3.org/permalink/netresearch/nr-llm:adr-070@main)) | 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](https://docs.typo3.org/permalink/netresearch/nr-llm:adr-094@main)) | 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](https://docs.typo3.org/permalink/netresearch/nr-llm:adr-144@main)) | whether the snippets and skills this configuration injects may reach the trust zone it can send to | No |
| Routing ([ADR-142](https://docs.typo3.org/permalink/netresearch/nr-llm:adr-142@main)) | whether any model resolves for a tool-calling run at all | No |
| Human approval ([ADR-134](https://docs.typo3.org/permalink/netresearch/nr-llm:adr-134@main)) | 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](https://docs.typo3.org/permalink/netresearch/nr-llm:adr-167@main)).

**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](https://docs.typo3.org/permalink/netresearch/nr-llm:adr-167@main): 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](https://docs.typo3.org/permalink/netresearch/nr-llm:adr-149@main)). 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](https://docs.typo3.org/permalink/netresearch/nr-llm:adr-157@main)). A caller can also attach snippets or skills to one
run ([ADR-164](https://docs.typo3.org/permalink/netresearch/nr-llm:adr-164@main)). 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?](https://docs.typo3.org/permalink/netresearch/nr-llm:administration-governance-routing@main) 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](https://docs.typo3.org/permalink/netresearch/nr-llm:adr-083@main)): 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](https://docs.typo3.org/permalink/netresearch/nr-llm:adr-157@main).

**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.