Q076 - How_should_a_stacked_RAIDT_configuration_be_documented_and_a
Q076 — How should a stacked RAIDT configuration be documented and assessed in practice?
← RAIDT · Star S6 - Influence Methods as Governance Interventions · primary item: S6.13 · Stacked influence
A stack becomes governable when every active layer is registered inside one run-level evidence pack.
Appears in sources
qa_deck_100#slide 78 · RAG, PEFT, RLHF-type controls, and stacked configuration
Answer
A stacked RAIDT configuration should be documented with run as the unit of governance. In practice, that means every execution should produce a run-level evidence pack that binds together the prompt ID and hash, model/version, adapter lineage, retriever and corpus snapshot identifiers, retrieved context IDs, reward or preference IDs where alignment is used, output hashes, timestamps, reviewer scores, and adjudication notes. Across the papers, this documentation is distributed through prompt registries, adapter cards, retrieval policies, reward sheets or pair-dataset records, JSONL run logs, sealed manifests, and reviewer instruments. The stack is only governable if those artefacts are cross-referenced rather than stored as disconnected notes.
Assessment should then proceed as a structured comparison, not a narrative impression. The run should be scored against the five pillars (Responsibility, Auditability, Interpretability, Dependability, Traceability) using a common reviewer rubric, with calibration, dual review, and adjudication where disagreement is material. Operationally, the 1-5 scale is best read through anchors 1=missing / 3=partial / 5=audit-ready, because this makes the evidential threshold explicit for each pillar. A strong assessment also compares the full stack with ablations, so the organisation can see what RAG, LoRA, prompt scaffolds, or RLHF individually contribute to the overall score profile. That is how stacked influence is made auditable in practice: document the whole run, score the run, compare the run, and retain the evidence for replay and post-market review.
Practical example
In a healthcare note-summarisation workflow, a hospital might run a stack composed of a role-based prompt, a LoRA adapter tuned to clinical idiom, a governed RAG layer over approved guidance, and an optional RLHF layer for bedside-safe tone. For one discharge-summary run, the governance store would archive the prompt version, adapter ID, corpus snapshot hash, retrieved chunk IDs, output SHA-256, reviewer forms, and any adjudication outcome.
The same run would then be scored by two reviewers against the RAIDT rubric. If Traceability is complete because every salient claim points to retrieved note spans and guideline passages, that pillar can approach the audit-ready end of the anchors. If the reward path is poorly documented, Auditability would be marked lower even if the prose is excellent. This keeps assessment concrete and prevents a polished answer from being mistaken for a governable one.
Sources in RAIDT papers
04-RAIDT_Prompt_Eng_V206-RAIDT_RAG_V107-RAIDT_RLHF_V1