Q110 - How_does_RAIDT_differ_from_a_generic_checklist
Q110 — How does RAIDT differ from a generic checklist?
← RAIDT · Star C0 - RAIDT Core, Definition, Values, Claims and Innovation · primary item: C0.12 · What RAIDT is not
Appears in sources
integrated_82#Q1.10
Answer
RAIDT differs from a generic checklist because it does not stop at asking whether controls exist in principle. A generic checklist usually records abstract presence or absence: a policy exists, a reviewer exists, documentation exists. RAIDT instead requires a run-level evidence pack for a specific material use and scores that evidence against the five pillars (Responsibility, Auditability, Interpretability, Dependability, Traceability). This matters because generative AI risk materialises at run time, where prompts, retrieval, tool chains, versions, and oversight decisions shape the output that an organisation may later need to defend.
The papers also distinguish RAIDT from a checklist at the level of theory. RAIDT is formalised as a mechanism-based mid-range design theory, not merely a descriptive list of good practice. It explains why evidence capture, versioning, and governed configuration change governance outcomes, and it treats influence methods as governance interventions whose effects can be observed in scored runs. A checklist can support review, but on its own it does not explain causal logic or make claims testable across contexts.
Operationally, RAIDT produces a score profile grounded in inspectable artefacts and calibrated anchors 1=missing / 3=partial / 5=audit-ready. That structure is designed to avoid compliance theatre. It makes trade-offs visible, allows repeated runs to be compared across configurations, and keeps attention on whether a specific use can be reconstructed, challenged, and improved rather than on whether the organisation can merely tick a box.
Practical example
Take an HR team using GenAI to draft shortlist justifications. A generic checklist might confirm that human review is required, that version control exists somewhere, and that an AI policy has been signed off. RAIDT goes further. For each hiring-related run, it asks whether the run-level evidence pack contains the prompt template version, job criteria version, model deployment identifier, any adapter version, the generated justification, and the recorded oversight decision.
That difference changes the governance outcome. If the shortlist is challenged months later, the organisation can only reconstruct the case if those run-specific artefacts exist. Under RAIDT, weak provenance would lower Traceability and possibly Auditability even if the checklist looked satisfactory. The method therefore resists generic assurance language and ties governance quality to evidence for the actual run under review.
Sources in RAIDT papers
08-RAIDT_Foundations_M_V5011-RAIDT_Academic_Logic_M_v11