RAIDT Core

To define RAIDT as a run-level governance framework for generative AI in organisational work, clarify its central claims, specify the run as the unit of governance, and explain the two core outputs: the run-level evidence pack and the five-pillar RAIDT score profile.

This note is the conceptual anchor for the whole RAIDT project. It sits primarily in the foundations layer, but it also links theory, evidence design, implementation logic, empirical validation, and policy translation. In practice, Circle 0 explains what RAIDT is, why the project is organised around the run rather than around the model alone, and how the framework is intended to support responsible AI governance across real organisational settings. It therefore supports all downstream work on pillars, evidence capture, scoring, governance interventions, sector playbooks, and policy alignment.

• Star C0 - RAIDT Core, Definition, Values, Claims and Innovation ? Defines the project identity: RAIDT as run-level evidence for responsible governance of GenAI in organisational work.

• What does RAIDT mean as a governance concept rather than as a slogan?
• Why does RAIDT define the run, rather than the model or organisation, as the primary unit of governance?
• What problem in current responsible AI practice does RAIDT attempt to solve?
• What exactly is included in a run-level evidence pack?
• How does the RAIDT score profile operationalise the five pillars of Responsibility, Auditability, Interpretability, Dependability, and Traceability?
• What kinds of evidence would show that RAIDT improves governance quality in practice?
• How does RAIDT connect technical design choices such as prompting, retrieval, tooling, PEFT or LoRA adaptation, and alignment controls to managerial accountability?
• How does RAIDT support contestability, assurance, and standards or policy alignment?
• How should supervisors understand the theoretical contribution of RAIDT in relation to Information Systems governance, responsible AI, and uncertainty management?
• What would count as success, limitation, or over-claim for the RAIDT framework?

• 10-20 min ? Does the run work as a credible unit of governance for organisational GenAI use, or does it need to be combined with stronger model-level and system-level controls?
• 20-40 min ? Which evidence elements are essential for a minimally defensible run-level evidence pack in high-stakes organisational contexts?
• 40-60 min ? How should the five RAIDT pillars be scored so that the profile supports governance decisions rather than becoming a compliance ritual?

RAIDT is the core organising idea of the project: a framework for governing generative AI through evidence about individual runs. In RAIDT, a run is one configured use of a generative AI system for a particular task, at a particular time, in a particular organisational context. This is a deliberate move away from treating governance as something that sits only at the level of the base model, the vendor, or a broad policy statement. Those levels still matter, but they do not tell decision-makers enough about what actually happened when a system was used to produce an output for work.

This matters because organisational use of generative AI is highly contingent. The same model can behave differently depending on prompt design, retrieved context, tool permissions, fine-tuning choices, safety settings, user expertise, domain constraints, and review practices. A procurement analyst drafting a supplier summary, a university administrator preparing a policy note, and a clinician using a summarisation support tool may all technically use the same model family, yet the governance questions are not the same. RAIDT therefore treats the run as the smallest practically meaningful unit at which evidence, accountability, and intervention can be assembled.

The framework produces two practical outputs. The first is a run-level evidence pack. This is the structured record of what the system was asked to do, how it was configured, what context it drew on, what output it produced, and what checking took place. The second is a five-pillar RAIDT score profile covering Responsibility, Auditability, Interpretability, Dependability, and Traceability. Together these outputs are intended to help organisations move from vague assurances about AI use to inspectable, contestable, and actionable governance evidence.

Responsibility concerns who designed, approved, operated, reviewed, or acted on a run. It makes explicit that governance is not only a technical matter; there must be named accountability, role clarity, and decision authority. Auditability asks whether an independent reviewer could reconstruct what happened and assess whether controls were followed. Interpretability concerns whether the rationale of the run is understandable enough for users and reviewers to make sense of the output, its basis, and its constraints. Dependability examines whether the run is sufficiently robust, reliable, and fit for purpose under the stated conditions of use. Traceability concerns the chain of evidence linking input, context, processing choices, output, review, and downstream action.

The problem RAIDT addresses is a recurring gap in responsible AI governance. Many governance approaches are strong at the level of principles, risk categories, or lifecycle controls, but weak at the point where an actual organisational use occurs. Generative AI creates particular pressure here because prompts are variable, retrieval pipelines can introduce hidden sources, output quality can shift across contexts, and human review is often inconsistent. As a result, organisations may claim that a system is aligned, documented, or policy-compliant while still lacking evidence about whether a specific output used in practice was produced responsibly.

RAIDT addresses this gap by connecting technical configuration to governance evidence. The run-level record can capture the instruction or prompt, the model and tool configuration, whether retrieval-augmented generation was used, what source materials were retrieved, whether a PEFT or LoRA variant was deployed, what alignment or RLHF-derived controls applied, what automated checks ran, what human review occurred, and whether escalation or override was necessary. This does not eliminate uncertainty, but it makes uncertainty visible and governable. For managerial settings, that is crucial. Managers often do not need metaphysical certainty about how a model ?thinks?; they need evidence about whether this use was appropriate, documented, reviewable, and defensible.

The framework also matters because it creates a bridge between academic theory and operational governance. In Information Systems terms, RAIDT can be read as a governance architecture for distributed sociotechnical action. In responsible AI terms, it operationalises accountability and oversight. In uncertainty terms, it reframes the problem from ?Can we fully trust this model?? to ?What can we evidence about this run, what uncertainty remains, and what governance response is proportionate?? This is especially relevant to domains where contestability matters. If a person challenges an AI-supported recommendation, an organisation needs more than a policy statement; it needs a reconstructable record.

A practical example helps. Suppose an HR team uses a GenAI tool to draft a first-pass job description. A RAIDT evidence pack would record the prompt, approved template, model version, whether internal competency documents were retrieved, what editing occurred, who approved release, and which checks ensured discriminatory or misleading language was removed. The score profile may show strong traceability and auditability but weaker interpretability if the source basis of some phrasing was unclear. That profile then informs a governance intervention, such as requiring mandatory source citation in future runs.

A second example is RAG-based policy drafting. A university team asks a model to produce a student-facing guidance note using internal regulations. Without run-level evidence, the team may only know that ?the model used the policy database?. With RAIDT, the run can record which documents were retrieved, their versions, the retrieval query, conflicts among sources, review steps, and whether the final output deviated from authoritative text. This makes governance concrete rather than rhetorical.

The framework has clear boundaries. RAIDT does not claim that every risk can be resolved at run level. Base model training data, vendor practices, upstream bias, and broader institutional power relations still require system-level and policy-level governance. Nor does RAIDT claim that scoring is fully objective. Scores are structured judgements supported by evidence, and they must be validated empirically. The value of RAIDT is not that it removes judgement, but that it disciplines judgement by tying it to a documented run.

Within the wider project, Circle 0 therefore establishes the central proposition to be tested and refined: responsible governance of generative AI in organisational work becomes more practical and defensible when the run is treated as the unit of evidence, assessment, and intervention. This proposition can then be explored methodologically in Paper 08, tested empirically in Paper 09, and translated into policy pathways and standards alignment in Paper 10.

Q1. What is RAIDT in one sentence?

Answer:
RAIDT is a run-level evidence framework for governing generative AI use in organisational work. Its purpose is to make each material AI-assisted task inspectable through structured evidence and a five-pillar score profile. Rather than asking only whether an AI system is generally safe or compliant, RAIDT asks whether a specific use was responsibly configured, documented, reviewed, and acted upon.

Practical example:
A policy officer uses a GenAI tool to draft a briefing note. RAIDT focuses on that single drafting event as the unit to document and assess.

Link to RAIDT:
This is the core project definition and explains why the run-level evidence pack and five-pillar scoring system are the main outputs.

Q2. Why is the run the unit of governance?

Answer:
The run is the point where model behaviour, prompt design, retrieved context, tools, and human oversight come together in practice. Governance at model or policy level remains necessary, but it is too abstract to explain whether one concrete organisational use was appropriate. The run is therefore the smallest unit at which responsibility and evidence can be assembled in a usable way.

Practical example:
The same model produces very different risk profiles when used for brainstorming workshop ideas versus summarising a legal contract.

Link to RAIDT:
The run anchors evidence capture, scoring, audit reconstruction, and targeted governance interventions.

Q3. What problem does RAIDT solve?

Answer:
RAIDT addresses the gap between high-level responsible AI principles and the messy reality of actual organisational use. Many organisations can show policies, procurement documents, or vendor claims, but cannot reconstruct what happened in a contested AI-assisted decision or output. RAIDT aims to close that gap.

Practical example:
An employee challenges an AI-assisted recommendation, but the organisation cannot show which prompt, context, or review process led to it.

Link to RAIDT:
The evidence pack is designed precisely to make such cases reconstructable and reviewable.

Q4. What belongs in a run-level evidence pack?

Answer:
At minimum, the pack should capture task purpose, user role, prompt or instruction, model and version, tool settings, retrieval sources where relevant, output artefacts, review steps, approvals, exceptions, and timestamps. In some contexts it should also include risk classification, escalation rules, and post-run outcomes.

Practical example:
A finance team run includes the prompt, model endpoint, retrieved policy documents, spreadsheet tool access, generated summary, and sign-off record.

Link to RAIDT:
The evidence pack is one of the two central practical outputs of the framework.

Q5. Why are the five pillars needed?

Answer:
The five pillars turn a broad governance ambition into assessable dimensions. Responsibility makes accountability visible; Auditability makes reconstruction possible; Interpretability supports understanding; Dependability addresses robustness and fitness for purpose; Traceability links evidence across the run lifecycle. Together they prevent governance from collapsing into a single vague judgement.

Practical example:
A run may be dependable in output quality but weak in traceability if the source basis cannot be reconstructed.

Link to RAIDT:
The RAIDT score profile uses these pillars to produce a structured assessment rather than a binary pass or fail.

Q6. How does RAIDT relate to prompt engineering?

Answer:
Prompt engineering is not just a performance technique; in RAIDT it is also a governance variable. Prompts shape task framing, output constraints, and potential failure modes, so they must be documented where they materially affect organisational outcomes.

Practical example:
A prompt that instructs a model to provide ?confident recommendations? may suppress uncertainty language that reviewers need to see.

Link to RAIDT:
Prompt design becomes part of run evidence and influences pillar scoring, especially Interpretability, Dependability, and Traceability.

Q7. How does RAIDT handle RAG and retrieved context?

Answer:
RAIDT treats retrieval as part of the run configuration because external or internal source selection strongly affects output quality and defensibility. Governance requires knowing not only that retrieval occurred, but which materials were retrieved, from where, and with what version status.

Practical example:
A student guidance answer is less defensible if it used an outdated policy PDF when a newer version existed.

Link to RAIDT:
Retrieved context is part of the evidence chain and is central to Traceability and Auditability.

Q8. Where do PEFT, LoRA, and alignment controls fit?

Answer:
These are configuration and assurance factors that shape how a model behaves in a given run. If an organisation uses a PEFT or LoRA-adapted variant, or relies on RLHF-derived alignment and safety controls, those choices should be captured as part of the technical and governance context. They do not replace run-level governance, but they materially affect it.

Practical example:
A customer-service assistant built on a LoRA-adapted model may behave differently from the base model in tone, constraints, and domain specificity.

Link to RAIDT:
Such factors belong in the run-level evidence pack and inform Dependability and Responsibility assessments.

Q9. How does RAIDT support standards and policy alignment?

Answer:
RAIDT can act as an operational layer that helps organisations show how abstract obligations are being enacted in day-to-day use. Standards and policy instruments often require documentation, accountability, risk management, and monitoring; RAIDT provides a concrete evidence structure through which such expectations can be demonstrated and tested.

Practical example:
An organisation maps evidence fields in the run pack to internal controls derived from the EU AI Act, ISO/IEC 42001, or the NIST AI RMF.

Link to RAIDT:
This is a major route from Circle 0 into Paper 10 and sector playbooks.

Q10. What would count as proof that RAIDT works?

Answer:
RAIDT is supported if empirical studies show that run-level evidence improves review quality, accountability clarity, contestability, and intervention design without creating unmanageable administrative burden. Evidence of usefulness would include better audit reconstruction, more consistent governance decisions, and clearer identification of where risks actually arise.

Practical example:
In a comparative study, teams using RAIDT produce more defensible records and detect more governance failures than teams relying only on general policy guidance.

Link to RAIDT:
This question directly connects Circle 0 to Paper 09 on empirical validation.

• An HR recruitment drafting run captures prompt wording, protected-characteristic safeguards, reviewer sign-off, and post-edit changes before a job advert is published.
• A university policy office uses RAG to generate student guidance and stores the exact policy sources, versions, retrieval results, and deviations from source text.
• A public-sector service team uses a LoRA-adapted assistant for case-note summarisation and records model variant, tool permissions, exception handling, and escalation triggers.
• A procurement team compares supplier responses with AI support and logs confidence limits, human review decisions, and reasons for overriding the model output.

• Run identifier and timestamp
• Organisational context, task type, and risk level
• User role, reviewer role, and decision authority
• Prompt or instruction text
• Model family, version, endpoint, and configuration settings
• Tool access, plugins, or external system connections
• Retrieval status, sources used, versioning, and query details
• Fine-tuning or adaptation status, including PEFT or LoRA where relevant
• Safety or alignment controls applied
• Output artefact and output metadata
• Human review steps, edits, approval, rejection, or escalation
• Observed uncertainty, caveats, or confidence statements
• Applicable policy, standard, or control mappings
• Outcome of the run and any downstream action taken

• Paper 08: foundations and methodological pathways ? Circle 0 defines the core construct of RAIDT, justifies the run as the unit of analysis and governance, and frames the methodological logic for how evidence and scoring will be designed.
• Paper 09: empirical validation ? The claims made here require testing through fieldwork, prototype evaluation, comparative studies, or expert review to determine whether RAIDT improves accountability and governance in practice.
• Paper 10: policy pathways ? Circle 0 provides the bridge from conceptual framework to operational policy translation, especially for standards alignment, auditability, and accountable implementation.
• Sector playbooks ? This note gives the generic logic that sector-specific playbooks can tailor for health, education, public administration, finance, HR, or other organisational domains.
• RAIDT scoring ? The five-pillar profile is introduced here as the main assessment mechanism that translates evidence into a governance-readable judgement.
• RAIDT evidence pack ? Circle 0 explains why the evidence pack exists and what kinds of evidence it must contain.
• RAIDT governance interventions ? The note frames interventions as responses to weak pillar performance, poor evidence quality, or mismatches between risk level and control design.

• Responsible AI governance and accountability literature
• Information Systems governance and sociotechnical accountability sources
• Human-AI interaction and contestability research
• Generative AI risk, assurance, and uncertainty management literature
• RAG governance, provenance, and documentation sources
• Fine-tuning, PEFT, LoRA, and alignment-control documentation or evaluation studies
• Policy and standards materials related to the EU AI Act, ISO/IEC 42001, and the NIST AI RMF
• Audit trail, documentation quality, and evidence-based assurance sources

RAIDT does not claim to solve all AI governance problems by documenting runs. It does not replace model evaluation, procurement scrutiny, organisational policy, legal review, or broader ethical analysis. It cannot guarantee that all outputs are correct, fair, or harmless. It also does not assume that the five-pillar score is mechanically objective; scoring remains a structured judgement that must be calibrated and validated. The framework is strongest when used as part of a wider governance stack that includes lifecycle controls, role design, standards alignment, and context-sensitive escalation.

RAIDT is the conceptual core of the project because it reframes responsible AI governance around the run rather than around abstract policy statements or model-level claims alone. A run is one concrete use of a generative AI system for a specific task, at a specific time, in a specific organisational setting. My argument is that this is the point at which governance becomes practically meaningful, because this is where prompts, retrieved context, model configuration, tool access, outputs, and review actually come together. RAIDT then produces two outputs: a run-level evidence pack and a five-pillar score profile covering Responsibility, Auditability, Interpretability, Dependability, and Traceability. The contribution is not that it removes uncertainty, but that it makes uncertainty governable through documentation, reconstruction, and targeted intervention. That matters for both theory and practice. Theoretically, it links responsible AI to Information Systems governance and uncertainty management. Practically, it offers a structure that supervisors, organisations, and policymakers can inspect, test, and adapt across sectors.