While developing the TypeSafe AI provider, I began to create "Decision" operation types. First ai_decision was part of ai_provider_typesafe_ai, then I split into its own project, now we are working to integrate the functionality into AI core without a separate submodule. Throughout the evolution of that development this issue was discovered and a fix developed in https://git.drupalcode.org/project/ai/-/merge_requests/2046 among updates for other issues. This is 2 of a set of issues that will be solved with this MR. ## Problem/motivation `GuardrailsEventSubscriber` runs every guardrail set with chat semantics: - Several built-in checks inspect only chat objects, and pass anything else. - A blocked request becomes a `ChatOutput` holding a refusal message. - A rewrite result replaces chat messages. A typed, non-chat operation (for example Decision, whose callers expect answers keyed by question ID) needs different behavior: - which checks are supported; - which content they inspect; - how thresholds aggregate; - how a block is reported (for example, a typed exception instead of a fake answer). Before this change, such an operation could only decorate the global subscriber. That also changed chat's processing order. LLM-backed guardrails (`NonDeterministicGuardrailInterface`) can call AI providers themselves. `GuardrailsEventSubscriber` guards against recursion with a private, per-fiber depth counter. A second guardrail runner cannot see that counter, so recursion that crosses operations (chat into another operation, or back) is not detected. ## Proposed resolution - Add `Drupal\ai\Guardrail\OperationGuardrailHandlerInterface`, with `getOperationType()`, `preGenerate()` and `postGenerate()`. - Add `Drupal\ai\Guardrail\OperationGuardrailHandlerRegistry`. It collects services tagged `ai.guardrail_operation_handler` (a `service_collector`) and rejects a second handler for the same operation. - Split `GuardrailsEventSubscriber`'s subscriptions: - priority 10 dispatches to a registered handler; - the existing runner stays at priority 0 and returns early for operations a handler has claimed. Global sets still attach at 100. Chat and every operation without a handler keep their current behaviour and order. - Move the per-fiber depth counter into a shared `GuardrailExecutionContext` service: - `isActive()` reports whether a check is already running; - `run()` restores the depth in a `finally` block. The existing runner and any operation handler use the same state, and deterministic checks still run on nested calls. - Document the extension point in `docs/developers/guardrails/index.md` ("Operation-specific handling"). Files: `src/Guardrail/OperationGuardrailHandlerInterface.php`, `src/Guardrail/OperationGuardrailHandlerRegistry.php`, `src/Guardrail/GuardrailExecutionContext.php`, `src/EventSubscriber/GuardrailsEventSubscriber.php`, `ai.services.yml`. ### Tests - `tests/src/Unit/Guardrail/OperationGuardrailHandlerRegistryTest.php`: duplicate handler, and depth reset after a failure. - The first consumer, `Drupal\ai\Guardrail\DecisionGuardrailRunner`, has kernel coverage in `tests/src/Kernel/OperationType/Decision/DecisionGuardrailsTest.php`: - recursion across operations in both directions (`testCrossOperationRecursion`); - per-fiber isolation of the nesting state (`testFiberIsolation`); - chat delegation and ordering staying on the default runner (`testChatDelegation`, `testChatOrdering`); - per-set thresholds and aggregated stops; - unsupported-check rejection before the provider call. - The existing chat guardrail kernel tests pass unchanged. ## Remaining tasks Review ## User interface changes None. ## API changes - New interface, registry service, tag `ai.guardrail_operation_handler`, and a `GuardrailExecutionContext` service. - `GuardrailsEventSubscriber::__construct()` gains two optional arguments, `$operationHandlers` and `$guardrailContext`. Both default to new instances, so existing subclasses and manual construction keep working. - `GuardrailsEventSubscriber::getSubscribedEvents()` now registers two listeners per event, at priorities 10 and 0. Before, one listener ran at the default priority, which was also 0. ## Data model changes None