• qa_deck_100#slide 84 · Gating, monitoring, review, and corrective action

Gating in RAIDT is the control by which a run or workflow cannot proceed unless its run-level evidence pack supports an acceptable score profile for the intended context. Because RAIDT defines the run as the unit of governance, the gate is attached to one configured use in time and context rather than to an abstract model approval. The decision is made from recorded evidence: prompt and template identifiers, model deployment and configuration settings, retrieved context where relevant, outputs, checks, and oversight actions. In that sense, gating is a decision right grounded in evidence, not a general assurance statement.

The gate is evaluated against the five pillars (Responsibility, Auditability, Interpretability, Dependability, Traceability), using anchors 1=missing / 3=partial / 5=audit-ready and thresholds calibrated to sector risk. The papers are clear that this does not certify factual correctness or legal compliance; rather, it establishes whether governance readiness is strong enough for the run to be relied upon, reconstructed later, and challenged if necessary. A RAIDT gate therefore asks a precise question: is there enough complete, integrity-protected, reviewable evidence to justify proceeding in this context? If yes, the workflow may continue. If not, the gate diverts the run to remediation, stronger controls, or human review. This matters because influence methods as governance interventions alter both behaviour and evidentiary quality, so governance must gate configured uses, not merely approved systems.

In a finance adverse-action workflow, a bank uses GenAI to draft an explanation of why a customer was declined for a product. A RAIDT gate would not let that explanation reach the customer simply because the prose sounds plausible. The run-level evidence pack must show the prompt version, the model deployment, any retrieval source used to support the reason, and the check that verifies the explanation matches the actual policy basis.

If traceability is weak because the reason code cannot be linked to the underlying policy version, or if interpretability is only partial because the explanation is not contestable, the gate fails. The case is escalated to human review or rewritten under a stricter configuration before any user-facing release occurs.

• 08-RAIDT_Foundations_M_V50
• 18-RAIDT-Technical-Foundation_M_v04