Q054 - What_makes_a_run_audit-ready_rather_than_merely_logged
Q054 — What makes a run audit-ready rather than merely logged?
← RAIDT · Star S5 - RAIDT Pillars and Scoring · primary item: S5.02 · Auditability
Audit-ready evidence is organised for challenge, not just captured somewhere in the system.
Appears in sources
qa_deck_100#slide 56 · Responsibility and auditability
Answer
A run is audit-ready in RAIDT when its evidence supports reliable reconstruction and review, not merely when some logs exist. The scoring appendix is explicit that generic logging is insufficient because governance depends on a scored object: the run-level evidence pack. Logs may be fragmented, overly technical, or incomplete; they often answer engineering questions rather than governance questions. RAIDT therefore requires a bounded, reviewable record tied to the specific run and suitable for independent inspection.
An audit-ready run normally includes stable identifiers and retained artefacts for the task context, prompt and template version, model or deployment identifier, configuration settings, toolchain dependencies, retrieved materials where relevant, output text, integrity hashes, checks performed, and human oversight actions. The evidence must be anchored to system logs and repositories, not to a model-generated narrative of what supposedly happened. Where retrieval is used, stored retrieval snapshots with identifiers and hashes are critical; citations alone do not make a run reconstructable. Integrity protection and retention matter as well, because records that cannot be trusted or are no longer available cannot support audit review.
This is why the score profile uses the anchors 1=missing / 3=partial / 5=audit-ready. A merely logged run may contain scattered traces. An audit-ready run, by contrast, preserves complete and usable evidence that allows a reviewer to test governance claims, challenge weak practice, and trigger corrective action where controls or documentation are inadequate.
Practical example
In a hospital discharge-summary workflow, an assistant drafts a summary from clinician notes and retrieved policy text. Suppose the hospital keeps ordinary application logs showing that a request was made, but does not retain the prompt version, the retrieval snapshot, the model deployment ID, or the clinician's review decision. If an omission later harms a patient, the organisation has logs, but not an audit-ready record.
The run becomes audit-ready when the evidence pack preserves the run ID and timestamp, full prompt or prompt hash with version identifier, model version and settings, retrieval snapshot identifiers and hashes, output text and output hash, safety-check results, and the clinician's approval, edit, or escalation note. That record supports post-incident reconstruction rather than leaving investigators to infer what happened from partial traces.
Sources in RAIDT papers
00-RAIDT_Scoring_v113-RAIDT-Evidence-Review_M_v10