• workshop_dense_100#slide 81

In RAIDT, corrective action is the governance response to low scores or incidents, such as updating prompts, fixing retrieval, improving logs, or adding human review. Its meaning is inseparable from run as the unit of governance: the organisation does not only ask whether a system is broadly compliant, but whether a specific configured use can be reconstructed, challenged, and improved. The basis for that judgement is the run-level evidence pack, which is assessed through a score profile across the five pillars (Responsibility, Auditability, Interpretability, Dependability, Traceability). When that profile shows weaknesses under the anchors 1=missing / 3=partial / 5=audit-ready, RAIDT expects an explicit corrective response tied to the observed deficit.

A typical example in the papers is a public-service or knowledge-intensive workflow in which retrieval supports an answer but the exact policy text, snapshot, or provenance cannot later be reconstructed. In RAIDT terms, that is not a minor documentation gap; it is a governance weakness because the organisation cannot defend the run under review. Corrective action would therefore include preserving retrieval snapshots, versioning prompt templates, hashing outputs and sources, and linking the run to review and change-management records. If the weakness sits in Responsibility rather than Auditability, the correction may instead be stronger escalation rules or mandatory human oversight.

This matters because RAIDT is designed to change practice, not merely to describe it. Corrective action closes the loop between scoring and governance embedding. It converts review into managed intervention, supports post-incident learning, and prevents evidence-centred governance from becoming compliance theatre. In that sense, corrective action is the practical mechanism by which influence methods as governance interventions are revised and made more governable over time.

Consider a public-service eligibility advice tool that retrieves policy clauses and drafts a recommendation for a caseworker. A review finds that the answer cites a rule, but the system did not preserve the exact retrieved clause version, the prompt revision used, or the oversight note explaining why the draft was accepted. Under RAIDT, the score profile would likely show weak Auditability and Traceability, even if the text itself looks plausible.

Corrective action would be concrete. The team would fix retrieval so that policy snapshots are stored with identifiers and hashes, require prompt version logging, and add a reviewer sign-off field for borderline cases. If repeated runs still vary too much, they might also tighten the prompt structure or narrow the retrieval corpus. The point is not only better engineering; it is a more reviewable and contestable run for future decisions.

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