• qa_deck_100#slide 60 · Interpretability, dependability, and traceability

In RAIDT, a run is traceable when the organisation can reconstruct how a specific output was produced from the evidence attached to that use event, not from general documentation about the model. This follows RAIDT's treatment of the run as the unit of governance: the scored object is the run-level evidence pack, and traceability asks whether outputs can be linked back to the inputs, retrieved sources, versions, tools, transformations, and review decisions that shaped them. A traceable run therefore preserves provenance rather than relying on retrospective narrative description.

The foundations paper defines Traceability as the extent to which the provenance of an output can be established, including what sources informed it, what transformations occurred, and what system components contributed. In practice, this means recording prompt and template identifiers, model/provider/version or deployment identifiers, tool-call sequences, retrieval snapshots, source identifiers and versions, timestamps, output hashes, and oversight records. This is why RAIDT treats influence methods as governance interventions: retrieval augmentation, adapter-based tuning, alignment policies, and tool use all alter the provenance chain and must be versioned and logged as part of the run evidence. A run is not strongly traceable merely because it cites sources. Under the scoring rubric, traceability remains weak if the underlying retrieval snapshot, policy version, or tool output cannot be independently re-established later. Strong traceability supports reconstruction, contestability, and comparison within a score profile, especially in disputed or high-stakes uses.

Consider an HR shortlist justification generated with a domain-tuned assistant. Several months after recruitment, an unsuccessful applicant challenges the basis on which the shortlist was prepared. In a traceable RAIDT run, reviewers can recover the prompt template and its version, the criteria file used for shortlisting, the model deployment identifier, the PEFT/LoRA adapter version, any retrieved policy passages, the generated justification, and the manager's approval decision.

That evidence allows the organisation to test whether the shortlist relied on the approved criteria and the approved system configuration in force at the time. If the output contains a persuasive explanation but the adapter version or retrieved policy text was never preserved, the run cannot be reconstructed properly. RAIDT would therefore treat the traceability evidence as incomplete, even if the prose looked competent when first produced.

• 08-RAIDT_Foundations_M_V50
• 00-RAIDT_Scoring_v1