Q153 - What_does_semi-automatic_RAIDT_implementation_look_like
Q153 — What does semi-automatic RAIDT implementation look like?
← RAIDT · Star S8 - Implementation and Operations · primary item: S8.02 · Semi-automated implementation
Appears in sources
integrated_82#Q4.2
Answer
A semi-automatic RAIDT implementation looks like a hybrid evidence workflow in which system logging and model assistance support, but do not replace, human verification. The empirical paper states this most directly: RAIDT can be semi-automated by having a system log metadata while the model drafts a structured evidence summary, with human verification. In practice, this means each run is captured as a bounded record containing identifiers and timestamps, prompt and template versions, model and tool settings, retrieved context where used, outputs, hashes, automated checks, and the review steps applied. Because RAIDT treats influence methods as governance interventions, the run record also needs method-specific fields such as retrieval snapshots, adapter identifiers, or alignment-policy versions where relevant.
The scoring process is similarly hybrid. Objective completeness checks can be run automatically for Auditability and Traceability, for example by verifying the presence of run IDs, prompt version identifiers, retrieval snapshot pointers, output hashes, and logged checks. Those checks may generate provisional score suggestions, but the reviewer still confirms or adjusts the result. Human judgement remains central for Responsibility, Interpretability, and Dependability, because those pillars depend on whether an output was appropriate, contestable, and stable in context. The result is not a narrative assurance memo; it is a run-level evidence pack linked to a score profile grounded in logged artefacts. In RAIDT terms, semi-automation preserves the discipline that the model-generated summary is a convenience layer, while the evidence pack remains the source of truth and the basis for applying the anchors 1=missing / 3=partial / 5=audit-ready.
Practical example
In a finance adverse-action workflow, a bank uses a governed prompt to draft an explanation for why an applicant was declined. A semi-automatic RAIDT implementation logs the prompt version, model deployment, relevant policy clause version, any retrieval query and snapshot from the internal lending-policy corpus, the generated explanation, and an integrity hash. The model then drafts a structured evidence summary that points to those fields and proposes whether auditability and traceability appear complete.
A compliance reviewer verifies the summary, checks that the explanation is understandable and contestable, and confirms that the reason codes and policy provenance are appropriate before release. The bank therefore gets a reviewable run-level evidence pack without treating the model?s own description of the run as the evidence.
Sources in RAIDT papers
08-RAIDT_Foundations_M_V5009-RAIDT_Empirical_M_V50.docx