Q270 - How_evidence_architecture_supports_all_five_pillars

Q270 — How evidence architecture supports all five pillars

← RAIDT · Star S5 - RAIDT Pillars and Scoring · primary item: S5.13 · Evidence-based scoring

The fields in the run record are not administrative extras. They are the evidence base from which the pillar scores become possible.

Appears in sources
Answer

In RAIDT, evidence architecture supports governance by turning dispersed logs, prompts, sources, outputs, and approvals into a structured, versioned, reviewable object. The review paper describes this architecture through context-of-use, configuration provenance, input and output recording, oversight and decision recording, and post-run monitoring context; the foundations paper then shows how those elements become operational in the run-level evidence pack. This matters because RAIDT defines the run as the unit of governance, so architecture is not a back-office storage issue but the mechanism that makes a contested use inspectable.

The same architecture supports all five pillars (Responsibility, Auditability, Interpretability, Dependability, Traceability) because different evidence elements answer different governance questions. Responsibility is supported by task purpose, policy constraints, reviewer roles, approvals, escalation records, and uncertainty disclosures. Auditability is supported by run IDs, timestamps, prompt and model versioning, parameters, hashes, and stable links to stored artefacts. Interpretability is supported by structured prompts, explanation templates, reason-code links, and plain-language limitation statements that let intended reviewers understand how to use the output. Dependability is supported by repeat-run records, dispersion metrics, perturbation tests, and monitoring signals that show whether behaviour is stable under expected conditions. Traceability is supported by retrieval snapshot IDs and hashes, source pointers, tool-chain identifiers, and adapter or policy-layer versions.

Crucially, RAIDT treats influence methods as governance interventions. Prompting, retrieval augmentation, PEFT/LoRA, and alignment controls all shape behaviour, so the architecture must capture them as governed configuration rather than informal tweaking. When that architecture is in place, the score profile does not merely report outcomes; it reveals where the evidential chain is strong, where it is thin, and which governance improvements are required.

Practical example

A cybersecurity team uses GenAI to triage alerts and propose analyst actions. An adequate evidence architecture records the alert context, the prompt template version, the model deployment, any retrieved threat-intelligence passages with snapshot hashes, tool outputs from enrichment services, the generated recommendation, and the analyst's approval or override. It also retains repeat-run checks for the same alert under fixed settings.

That single architecture supports every pillar at once. Responsibility is evidenced by escalation rules for severe incidents and by the analyst decision. Auditability comes from reconstructable identifiers and hashes. Interpretability comes from a structured response template that separates observations from recommendations and uncertainty. Dependability comes from repeat-run stability evidence. Traceability comes from preserved source snapshots and tool-chain provenance. Without that architecture, the team may have logs, but not an evidence object that can be scored or audited coherently.

Sources in RAIDT papers
Powered by Forestry.md