RAIDT provides the conceptual and operational anchor for the project. Its function is to translate high-level responsible AI principles into a run-level governance framework that can be inspected, scored, compared, and improved in organisational settings. The note clarifies what a run is, what counts as evidence, why the evidence pack matters, and how the five-pillar profile turns diffuse governance expectations into a practical assessment mechanism.

This is the centre note and therefore sits across the whole RAIDT project rather than within a single star. It links foundations, theory, governance design, implementation logic, empirical validation, and policy pathways.

In project terms, this note contributes to:

• foundations, by defining the problem that RAIDT addresses;
• theory, by clarifying the run as the unit of governance;
• evidence, by specifying the run-level evidence pack;
• pillars, by introducing Responsibility, Auditability, Interpretability, Dependability, and Traceability;
• implementation, by showing how evidence and scoring become governance interventions;
• empirical validation, by clarifying what can be observed and tested in practice;
• policy alignment, by linking RAIDT to standards and regulatory expectations.

The map is organised as 4 circles containing 12 stars + 1 centre. Every item is tagged by its star, and every question is anchored to its primary item.

• Circle 0 - RAIDT Core - definition, value claims, unit of governance, outputs, and innovation. (tags C0)
• Circle 1 - Foundational problem logic - origins, responsible AI, uncertainty, governance meaning, GenAI failure modes, and the run-level gap. (tags S1-S3)
• Circle 2 - Operational governance mechanism - evidence architecture, five pillars, scoring, and influence methods as governance interventions. (tags S4-S6)
• Circle 3 - Academic, adoption and boundary layer - theory, implementation, policy, empirical domains, limitations, future questions, and supervisory navigation. (tags S7-S12)

• What does RAIDT mean in precise project terms?
• Why does RAIDT treat the run, rather than only the model or the organisation, as the primary unit of governance?
• What problem does RAIDT solve that existing responsible AI and Information Systems governance approaches leave unresolved?
• What constitutes a run-level evidence pack, and why is it necessary for meaningful oversight?
• How do the five RAIDT pillars provide a usable governance profile?
• How does RAIDT connect prompt engineering, RAG, PEFT or LoRA, RLHF or alignment controls, and human review into one governance logic?
• What forms of evidence would allow supervisors, reviewers, and organisational decision-makers to evaluate the framework?
• How does RAIDT support Paper 08 foundations, Paper 09 empirical validation, Paper 10 policy pathways, and sector playbooks?
• How does this centre note help supervisors understand the novelty, scope, and practical value of the project?

• 10?20 min ? Is the run the right unit of governance for generative AI in organisational work, or should governance remain at the model, workflow, or policy level?
• 20?40 min ? Which evidence fields are essential for a credible run-level evidence pack, and which would be too costly or unrealistic to capture consistently?
• 40?60 min ? How should the five RAIDT pillars be translated into scoring rules, intervention thresholds, and sector-specific playbooks?

RAIDT begins from a practical and conceptual problem in contemporary generative AI governance. Organisations increasingly use large language models and related GenAI systems to draft documents, classify cases, summarise records, retrieve internal knowledge, support analysis, and generate recommendations. Yet most governance mechanisms still operate at a level that is too broad to explain what actually happened in a specific use event. Policy statements may set principles. Model cards may describe a system in general terms. Risk registers may classify an application area. None of these, on their own, provide a sufficiently precise account of how one concrete organisational use of GenAI was configured, what information it relied on, what output it produced, what checks were applied, and why the result should or should not be trusted.

RAIDT responds to that gap by treating the run as the unit of governance. A run is one configured use of a generative AI system for a specific task, at a specific time, in a specific context. The run includes the instruction or prompt, the model and tool configuration, any retrieved context where retrieval-augmented generation is used, the output generated, and the human or automated checks attached to that use. This is important because organisational risk does not arise only from the abstract properties of a model. It also arises from situated combinations of prompts, retrieved documents, custom fine-tuning, tool permissions, user intent, workflow pressure, and review quality. RAIDT therefore shifts the governance lens from general capability to inspectable organisational use.

This move matters for responsible AI because many principles become actionable only when translated into evidential questions. Responsibility requires knowing who initiated or approved a run and under what authority. Auditability requires records that make later inspection possible. Interpretability requires enough explanation to understand how the output was formed or constrained. Dependability requires evidence about reliability, consistency, and control of failure conditions. Traceability requires the ability to follow the chain from input conditions through generation to decision consequences. By placing these concerns at run level, RAIDT turns them into a practical governance architecture rather than a purely normative checklist.

The framework produces two main outputs. The first is a run-level evidence pack. This is the documented record of the run, including context, technical settings, retrieved inputs, output, review processes, and governance metadata. The second is a five-pillar RAIDT score profile covering Responsibility, Auditability, Interpretability, Dependability, and Traceability. The evidence pack provides the material for assessment; the score profile provides a compact way to compare runs, identify weaknesses, and trigger governance interventions. In this sense, RAIDT is not only descriptive. It is also diagnostic and intervention-oriented.

The run-level focus is especially useful under conditions of uncertainty. Generative AI outputs are probabilistic, context-sensitive, and often variable across small changes in prompt wording, retrieval context, or system configuration. Managers are therefore asked to act under uncertainty about correctness, consistency, accountability, and downstream effects. RAIDT addresses managerial uncertainty by making each run more legible. It does not remove uncertainty entirely, but it reduces avoidable ambiguity by requiring evidence about what was done, with what system, using which inputs, under what controls, and with what result. That is why RAIDT sits naturally at the intersection of responsible AI, Information Systems governance, and organisational decision-making under uncertainty.

The framework also accommodates current GenAI development practices. In prompt engineering, it captures the instructions and constraints that shape a run. In RAG settings, it records what documents or chunks were retrieved and how retrieval affected the result. Where PEFT or LoRA-based adaptation is used, RAIDT can capture the presence and governance status of the adaptation layer. Where RLHF or other alignment controls shape model behaviour, RAIDT can treat those controls as part of the relevant configuration and assurance context. This makes RAIDT compatible with modern GenAI stacks rather than tied to a narrow single-model view.

A practical example illustrates the point. Suppose a university uses GenAI to draft a student support response. A policy document alone cannot explain whether the draft relied on outdated guidance, whether the prompt asked the model to infer sensitive information, whether internal documents were retrieved correctly, or whether a human reviewer checked the final text before sending it. A RAIDT evidence pack could capture the run timestamp, user role, prompt, model version, retrieved policy extracts, draft output, review status, and scoring notes across the five pillars. That evidence would make the event inspectable and contestable. It would also support organisational learning if similar runs repeatedly show low interpretability or weak traceability.

A second example concerns a compliance team using a domain-adapted model with LoRA-based tuning to summarise incidents. Here the governance question is not simply whether the base model is safe. It is whether this adapted configuration, used by this team, for this purpose, with this prompt pattern and this review workflow, is dependable enough for organisational use. RAIDT offers a way to answer that question systematically at the level where operational risk actually materialises.

The five pillars are central because they organise governance evidence into an intelligible profile. Responsibility asks whether ownership, authority, and accountability are clear. Auditability asks whether the run can be inspected after the fact. Interpretability asks whether those reviewing the run can understand, at a practical level, how the output was produced and bounded. Dependability asks whether the run is stable and sufficiently reliable for the task. Traceability asks whether the evidential chain can be followed from initiation through outcome and consequence. Together, the pillars create a structure for scoring, comparison, threshold setting, and intervention. A low score might trigger additional review, restricted deployment, prompt redesign, retrieval controls, model substitution, or escalation to policy owners.

RAIDT is therefore both a conceptual contribution and a practical governance mechanism. For Paper 08, it clarifies the methodological pathway from responsible AI concerns to a run-level evidential framework. For Paper 09, it defines observable variables that can be tested empirically across cases, sectors, or runs. For Paper 10, it provides a pathway for translating policy and standards language into operational evidence practices. Sector playbooks can then adapt the same core logic to different risk environments such as education, healthcare, financial services, local government, or professional services.

At the same time, RAIDT makes bounded claims. It does not claim that run-level evidence alone guarantees safe or fair AI. It does not replace model evaluation, organisational culture, procurement controls, or legal compliance. It does not eliminate uncertainty, bias, or misuse. Its claim is narrower and more defensible: responsible governance of organisational GenAI improves when each meaningful run can be documented, interpreted, assessed, and acted upon using a consistent evidence-and-scoring logic. That is the project's central organising idea.

Q1. What is RAIDT?

Answer:
RAIDT is a run-level evidence framework for governing generative AI in organisational work. It defines the run as the unit of governance and requires each meaningful use event to be documented and assessed through an evidence pack and a five-pillar score profile.

Practical example:
An internal knowledge assistant generates a policy summary for an operations manager. RAIDT records the prompt, model version, retrieved documents, output, reviewer, and score profile for that specific run.

Link to RAIDT:
This is the framework's core definition and explains why the centre note anchors the evidence pack, scoring logic, and governance interventions.

Q2. Why is the run the unit of governance?

Answer:
Because organisational harms and benefits emerge from specific uses, not only from abstract model capabilities. The same model can be low-risk in one run and high-risk in another depending on task, context, retrieved data, and review quality.

Practical example:
A model used to draft a meeting invitation is not governed in the same way as the same model used to summarise a safeguarding report.

Link to RAIDT:
The run-level approach justifies the need for run-level evidence and for pillar scores that vary by use case rather than by model name alone.

Q3. What problem does RAIDT solve?

Answer:
RAIDT addresses the gap between high-level responsible AI principles and the evidential needs of real organisational oversight. Many frameworks say that AI should be accountable or transparent, but they do not specify what evidence should exist for a concrete use event.

Practical example:
A department cannot investigate a problematic GenAI output because no one recorded the prompt, source material, or approval step. RAIDT makes those items governable artefacts.

Link to RAIDT:
This is the rationale for the evidence pack and for using scoring to turn abstract governance concerns into operational checks.

Q4. What is included in a run-level evidence pack?

Answer:
A robust evidence pack captures the run identity, task purpose, user role, time, model and tool configuration, prompt or instruction, retrieved context, output, checks performed, decision status, and governance metadata such as pillar scores and escalations.

Practical example:
In a RAG workflow, the evidence pack would include which internal documents were retrieved, when they were accessed, and whether they were current.

Link to RAIDT:
The evidence pack is one of RAIDT's two principal outputs and the primary input to pillar scoring and intervention design.

Q5. Why are the five pillars necessary?

Answer:
The pillars provide a structured way to judge whether a run is responsibly governed. Without pillars, evidence collection can become descriptive but directionless. The pillars give evaluative purpose to the evidence.

Practical example:
A run may have strong audit logs but poor interpretability if reviewers cannot explain why the output cited one policy clause rather than another.

Link to RAIDT:
Responsibility, Auditability, Interpretability, Dependability, and Traceability form the score profile that makes RAIDT analytically useful.

Q6. How does RAIDT relate to prompt engineering?

Answer:
Prompt engineering is a governance-relevant configuration activity because prompt wording shapes system behaviour, boundaries, and risk exposure. RAIDT treats prompts as evidence rather than as invisible craft.

Practical example:
A system prompt instructs the model to refuse legal advice, while a user prompt asks for procedural guidance only. Capturing both clarifies why the output stayed within scope.

Link to RAIDT:
Prompt content is part of the run record and can materially affect interpretability, dependability, and responsibility scores.

Q7. How does RAIDT handle RAG, PEFT or LoRA, and alignment controls?

Answer:
RAIDT treats these as parts of the run's technical and governance context. Retrieved material, adaptation layers, and alignment controls all shape what the system can do and what evidence is needed to evaluate it.

Practical example:
A claims assistant uses a LoRA-adapted model plus retrieval from internal guidance. The evidence pack records both the adaptation status and the retrieved guidance used in the run.

Link to RAIDT:
This keeps RAIDT compatible with contemporary GenAI systems and ensures the evidence pack reflects real system configuration rather than an oversimplified model-only account.

Q8. What kind of evidence would prove RAIDT is useful?

Answer:
Useful evidence would show that RAIDT improves oversight, supports better escalation decisions, reduces ambiguity in post-hoc review, and produces repeatable scoring across comparable runs.

Practical example:
In a pilot study, supervisors reviewing RAIDT evidence packs may identify unsafe uses more consistently than supervisors relying on policy statements alone.

Link to RAIDT:
This question points directly to Paper 09 empirical validation and to testing the reliability and utility of the scoring framework.

Q9. How does RAIDT connect to policy and standards?

Answer:
RAIDT can operationalise policy expectations by translating broad requirements into specific evidence fields and governance checks. This makes standards and regulation more usable at workflow level.

Practical example:
An organisation maps its RAIDT evidence fields to internal controls informed by the EU AI Act, ISO/IEC 42001, and the NIST AI RMF.

Link to RAIDT:
This supports Paper 10 policy pathways and shows how run-level evidence can align organisational practice with external governance expectations.

Q10. How should supervisors understand the novelty of RAIDT?

Answer:
The novelty lies in combining a precise unit of governance, a concrete evidence architecture, and a scoring mechanism that supports intervention. RAIDT is not just another statement of responsible AI principles; it is a framework for making those principles inspectable in practice.

Practical example:
A supervisor can see how the same conceptual framework supports theory-building, case study design, policy mapping, and sector playbook development.

Link to RAIDT:
This question ties the centre note to the whole project structure and explains why RAIDT is the organising idea rather than one concept among many.

• A university student-support team uses GenAI to draft email responses. RAIDT captures the prompt, retrieved policy documents, model version, reviewer identity, and pillar scores before a response is sent.
• A hospital administration unit uses a GenAI summarisation tool for non-clinical paperwork. RAIDT records whether sensitive data were retrieved, which controls were applied, and whether the output required human correction.
• A financial services compliance team uses a LoRA-adapted assistant to draft internal incident summaries. RAIDT captures adaptation status, source documents, approval steps, and dependability concerns.
• A local authority service desk deploys a RAG chatbot for staff guidance. RAIDT reveals when outdated retrieval sources or unclear ownership undermine auditability and traceability.

• Run identifier and timestamp
• Organisational unit, task type, and intended purpose
• User role and authority level
• Model name, version, provider, and relevant configuration
• Tool use, permissions, and workflow position
• Prompt, system instruction, and other run directives
• Retrieved documents, chunks, source provenance, and retrieval time
• Presence of PEFT, LoRA, or other adaptation layers where relevant
• Relevant alignment or refusal controls where known
• Generated output and any edited final output
• Human review steps, automated checks, and approval status
• Risk flags, exceptions, contestation points, and escalation history
• Five-pillar scores with short justifications
• Governance intervention triggered, if any
• Retention, logging, and policy alignment metadata

• Paper 08: foundations and methodological pathways - This note defines the project's central construct, explains the run-level problem, and justifies the move from principles to evidence architecture.

• Paper 09: empirical validation - The note identifies observable fields, candidate variables, and evaluative outcomes that can be tested through case studies, pilots, or comparative scoring exercises.

• Paper 10: policy pathways - The note shows how run-level evidence can operationalise policy expectations from responsible AI guidance, standards, and regulation.

• Sector playbooks - The centre logic can be adapted into domain-specific guidance while retaining a shared evidence core and pillar structure.

• RAIDT scoring - The note introduces the purpose of the five-pillar profile and its role in comparing runs and identifying governance weaknesses.

• RAIDT evidence pack - The note defines the evidence pack as the practical artefact that makes run-level governance inspectable and reviewable.

• RAIDT governance interventions - The note explains why scoring should trigger actions such as escalation, redesign, restriction, retraining, or closer review.

• Responsible AI governance literature on accountability, transparency, contestability, and oversight
• Information Systems governance scholarship on controls, audit trails, and organisational accountability
• Literature on uncertainty in managerial decision-making and technology-enabled judgement
• Research on prompt engineering and the instability of GenAI outputs across context changes
• RAG literature on retrieval quality, provenance, and source-grounding
• PEFT and LoRA literature on adaptation layers and deployment governance implications
• RLHF and alignment literature on behavioural shaping and control boundaries
• Standards and policy sources such as the EU AI Act, ISO/IEC 42001, and the NIST AI RMF
• Empirical studies of GenAI use in sector settings such as education, healthcare, public administration, and professional services

• RAIDT does not claim that run-level logging alone guarantees safe, fair, or lawful AI use.
• RAIDT does not replace model evaluation, procurement review, security controls, or organisational policy.
• RAIDT does not eliminate uncertainty; it makes uncertainty more inspectable and manageable.
• RAIDT is likely to create evidence-capture overhead, so proportionality and automation matter.
• Some high-value evidence may be unavailable in closed commercial systems.
• Scoring quality depends on clear definitions, trained assessors, and repeatable criteria.
• Sector adaptation is necessary because acceptable evidence and thresholds differ by domain.

RAIDT is the centre of the project because it states the main claim in operational terms: generative AI governance becomes more credible when the run is treated as the unit of analysis and the unit of control. A run is not just a model response. It is one specific use of a configured GenAI system for a particular task, at a particular time, with a particular context, prompt, retrieval set, and review process. The problem is that most responsible AI frameworks stay at principle level, while most organisational risks arise at this concrete use level. RAIDT addresses that gap by producing two outputs: a run-level evidence pack and a five-pillar score profile covering Responsibility, Auditability, Interpretability, Dependability, and Traceability. That gives the project a clear methodological pathway. Paper 08 explains the conceptual foundations, Paper 09 tests whether the evidence-and-scoring logic works empirically, and Paper 10 shows how policy and standards can be translated into operational practice. The contribution is therefore not only theoretical. It is a practical governance framework designed for real GenAI workflows.