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

A RAIDT gate becomes operational when it is tied to bounded evidence, explicit thresholds, and enforceable consequences. The technical foundation paper contrasts operational accountability with symbolic commitment: governance is real when systems are subjected to evidence-bearing review procedures that show what was scrutinised, what failure mattered, and who was responsible. In RAIDT, that means the gate is applied to a run-level evidence pack with stable identifiers, timestamps, prompt and configuration records, retrieval snapshots or provenance pointers where relevant, outputs, integrity hashes, checks, and documented oversight. Reviewers record evidence pointers, and the resulting score profile across the five pillars (Responsibility, Auditability, Interpretability, Dependability, Traceability) is judged against anchors 1=missing / 3=partial / 5=audit-ready and context-specific thresholds.

It is only symbolic when the organisation has policies, model cards, or generic sign-off language but cannot reconstruct one configured run or show why it passed. An operational RAIDT gate must therefore do three things. First, it must use the run as the unit of governance rather than a system-level abstraction. Second, it must be inspectable, so a later reviewer can verify the grounds of the decision from the evidence pack itself. Third, it must trigger action: below-threshold pillars block release, escalate to human review, or initiate remediation such as instrumentation fixes, stronger constraints, or configuration stabilisation. This is why influence methods as governance interventions must be versioned and logged; otherwise the gate has nothing reliable to evaluate.

Take a public-service eligibility workflow. A symbolic gate would be a manager stating that the system is approved and that staff should use it carefully. An operational RAIDT gate is different. The case cannot proceed unless the run-level evidence pack contains the exact prompt version, the model deployment ID, the policy clause and version used to justify the recommendation, the output hash, and the reviewer check.

If auditability or traceability falls below the threshold because the policy clause cannot be reconstructed, the recommendation is not issued. The corrective action is concrete: repair logging, bind the workflow to versioned policy retrieval, or require manual adjudication until the evidence path is restored. That is an operational gate because it changes what the organisation is allowed to do.

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