Q232 - Retention_policy_definition_example_and_why_it_matters_in_RA
Q232 — Retention policy — definition, example, and why it matters in RAIDT
← RAIDT · Star S4 - Evidence Architecture and Artefacts · primary item: S4.17 · Retention and access control
D. Evidence Architecture | Ordered by mind-map priority: inner circles first, then operational detail.
Appears in sources
workshop_dense_100#slide 55
Answer
Within RAIDT, a retention policy is a run-record rule that specifies what evidence from a particular run is preserved, for how long, in what form, and under which access restrictions and privacy safeguards. It is not merely a generic records-management statement. Rather, it is part of the operational specification that makes a run-level evidence pack reviewable over time. The papers link this directly to governance integration: a run record must connect to audit, incident, risk and change-management processes, and that connection requires consistent identifiers, retention metadata and access control.
A clear RAIDT example is a run in which a system uses retrieval augmentation or alignment controls. Because influence methods as governance interventions materially shape outputs, the organisation must decide whether to retain full prompts, retrieval snapshots, output text, hashes, policy-layer identifiers, or some combination of these. Where privacy or intellectual-property constraints apply, the papers recommend proportionate storage, secure repositories, hashes, immutable identifiers, redaction rules and role-based access rather than indiscriminate logging. Retention policy therefore governs the evidentiary life of the run, not just its initial capture.
This matters because RAIDT evaluates governance readiness through evidence, not assertion. If relevant artefacts disappear before a complaint, audit sample or incident review, Auditability and Traceability become hard to defend; if they are kept without limits or safeguards, Responsibility is weakened by avoidable privacy and security risk. Retention policy thus shapes whether the score profile can legitimately support the five pillars (Responsibility, Auditability, Interpretability, Dependability, Traceability). In that sense, it is a practical condition for moving from anchors 1=missing / 3=partial / 5=audit-ready.
Practical example
Consider a healthcare note-summarisation run for a high-risk presentation. The hospital records the prompt template, model version, uncertainty guidance, reviewer decision and output hash. Because the prompt and output may contain patient data, the retention policy states that full text is kept only in a restricted clinical repository for a short, defined period, while hashes, run identifiers and review metadata are retained longer for audit and incident investigation. Access is tiered so clinicians and designated governance staff can reconstruct the case without making sensitive content widely visible.
This matters if a clinician later questions whether the summary omitted an escalation signal. The hospital can retrieve the run-level evidence pack, inspect what the system had access to, and review the oversight decision, while still respecting privacy safeguards. The policy therefore supports both evidential durability and controlled access in a way consistent with RAIDT.
Sources in RAIDT papers
08-RAIDT_Foundations_M_V5013-RAIDT-Evidence-Review_M_v10