Origins, Background and History

#raidt/S1

flowchart LR
    A[Managerial uncertainty] --> B[Responsible AI limits]
    B --> C[GenAI runtime pressure]
    C --> D[Star S1 origins]
    D --> E[RAIDT run-level focus]
    E --> F[Run evidence pack]
    E --> G[Five-pillar scoring]
    F --> H[Reviewable governance]
    G --> H
    I[Organisational settings] --> E

← Circle 1 - Foundational problem logic

Ring: Inner foundation star

Function

Explains the intellectual and practical origin of RAIDT by showing how the project moved from concerns about AI under uncertainty and Responsible AI into a run-level evidence framework for governing GenAI use in organisational work. This star clarifies why RAIDT treats the run, rather than only the model or policy statement, as the central unit of governance.

Role in the project

This star is a foundations note with direct implications for theory, evidence design, implementation logic, empirical validation, and policy translation. It anchors the project?s origin story, defines the problem RAIDT is trying to solve, and explains why the framework sits between Responsible AI principles and operational GenAI governance. For PhD supervision, it helps establish that RAIDT is not merely a compliance checklist or a prompt engineering technique. It is a structured response to a governance gap: organisations need evidence at the point where GenAI is actually configured and used.

This note therefore contributes to the foundations of Paper 08, frames the empirical logic taken forward in Paper 09, and supports the policy and standards translation work developed in Paper 10. It also helps explain why sector playbooks, scoring rubrics, and run-level evidence packs belong to one coherent project rather than separate strands.

Main questions answered by this star

What does the origin of RAIDT mean in conceptual and practical terms?
Why does RAIDT begin with AI and managerial uncertainty rather than with GenAI alone?
What problem do Responsible AI frameworks leave unresolved at the level of operational evidence?
Why does GenAI create a stronger need for governance at the level of the run?
What exactly is a run, and why is it the key governance object in RAIDT?
What evidence proves that a specific GenAI use can be reviewed, challenged, or reconstructed?
How does this origin story justify the design of the run-level evidence pack?
How does the note connect to the five RAIDT pillars: Responsibility, Auditability, Interpretability, Dependability, and Traceability?
How does this star help supervisors understand the movement from concept, to framework, to empirical testing, to policy relevance?
Why is RAIDT better understood as an evidence-based governance intervention than as a purely abstract theory?

Workshop discussion prompts

10-20 min ? Why did the RAIDT project emerge from uncertainty, Responsible AI, and Information Systems governance rather than from a narrow technical evaluation problem?
20-40 min ? What changes when the governance object moves from the model to the configured run, especially in GenAI systems using prompts, tools, and retrieval?
40-60 min ? Which forms of evidence are necessary if an organisation wants a GenAI output to be reviewable, challengeable, and aligned with standards, policy, and operational accountability?

Items in this star (10)

Main message

RAIDT emerges from a practical and scholarly problem that became more visible as AI systems moved from controlled analytical settings into messy organisational work. The starting point is not GenAI hype by itself. The starting point is uncertainty. Managers, professionals, and public-sector actors often make decisions when the available information is incomplete, contested, fast-moving, or difficult to verify. In these settings, an AI system may appear helpful because it can summarise, generate options, draft communications, or synthesise evidence quickly. Yet uncertainty also makes governance harder, because decision-makers need to know not only what the system produced, but how and under what conditions that output came into being.

The early intellectual route into RAIDT therefore sits at the intersection of managerial uncertainty, Responsible AI, audit and accountability traditions, and Information Systems governance. Responsible AI contributed the value language: fairness, accountability, transparency, safety, explainability, and human oversight. Information Systems governance contributed the organisational lens: controls, accountability structures, process ownership, monitoring, and alignment with institutional objectives. Audit and accountability traditions added a further demand: if something materially influences action, then there should be a way to reconstruct and review it. These traditions are not identical, but together they reveal a common pressure. Organisations require more than aspirations; they require inspectable evidence.

This pressure intensifies with generative AI. Earlier AI governance discussions often concentrated on the model as a relatively stable object. By contrast, GenAI performance and risk are shaped at run time. A single output can depend on the prompt wording, system instruction, tool permissions, model version, temperature or decoding settings, retrieval source, retrieved document set, adapter such as PEFT or LoRA, alignment controls such as RLHF-shaped behaviour constraints, and the human review process that follows. In other words, the relevant governance object is not simply the model in abstraction. It is the configured use of that model for a particular task, by a particular actor, in a particular context, at a particular time.

This is the conceptual move that gives RAIDT its distinct identity. RAIDT defines the run as the unit of governance. A run is one configured use of a GenAI system for a specific task in context, including the instruction, model and tool configuration, retrieved context where used, output, and human or automated checks. This definition matters because most accountability questions arise after a specific output has been used. A supervisor may ask why a briefing note looked persuasive but omitted a critical source. A clinician may challenge an AI-generated summary. A regulator may ask how a recommendation was produced. A customer may contest an explanation or decision-support output. In each case, policy statements and model documentation may help, but they are not sufficient. What is needed is evidence about the actual run.

RAIDT responds by turning the run into an evidence object. Its first practical output is the run-level evidence pack. This pack records what happened in a form that can support review, challenge, comparison, and governance intervention. Typical fields include the run identifier, timestamp, user or role, task type, domain, prompt identifier and version, prompt hash, model identifier, provider, configuration settings, tool chain, retrieval query, retrieval index, retrieved document identifiers or hashes, output record, review decision, oversight notes, and scoring outcome. The purpose is not to record everything for its own sake. The purpose is to capture enough evidence to reconstruct a materially significant use of GenAI and to evaluate whether the organisation governed that use well.

The second practical output is the RAIDT score profile, organised around five pillars. Responsibility asks whether the run served a legitimate and properly bounded purpose, and whether there was suitable ownership and oversight. Auditability asks whether a later reviewer can reconstruct the run. Interpretability asks whether relevant users can understand the meaning, limitations, and appropriate use of the output. Dependability asks whether the run is stable, safe, and sufficiently robust for the task. Traceability asks whether outputs can be linked back to prompts, sources, tools, model versions, and downstream action. Together, these pillars convert broad Responsible AI language into concrete review questions and scoring logic.

This origin story also clarifies why RAIDT is not reducible to prompt engineering. Prompting, RAG, PEFT or LoRA, and RLHF-style controls matter in the project, but they matter as influence mechanisms and governance interventions rather than as ends in themselves. Prompting shapes the instruction space. RAG shapes source grounding and evidential traceability. PEFT and LoRA shape task adaptation and operational behaviour. RLHF and alignment controls shape guardrails, refusals, and behavioural boundaries. RAIDT studies these mechanisms because they affect what a run does, what risks it creates, and what evidence must be captured if that run is to remain governable.

The note is therefore foundational for the wider research design. In Paper 08, it supports the argument that RAIDT is a mechanism-based, mid-range design framework grounded in a clear problem pathway: uncertainty leads to governance pressure; Responsible AI provides normative direction; GenAI exposes an operational evidence gap; RAIDT responds by governing the configured run. In Paper 09, the same logic becomes empirically testable, because different influence methods and configurations can be compared through their effect on the evidence pack and the five-pillar score profile. In Paper 10, the note matters because it explains why RAIDT can serve as a translation layer between operational practice and policy frameworks such as the EU AI Act, ISO/IEC 42001, and the NIST AI RMF.

The importance of this star is therefore both conceptual and practical. Conceptually, it explains why RAIDT exists and why the run is the right unit of analysis for organisational GenAI governance. Practically, it justifies what should be captured, reviewed, scored, and improved in live use. It helps supervisors see that the project is neither a generic ethics statement nor a purely technical evaluation protocol. It is a governance architecture built around evidence at the point of use.

There are, however, clear boundaries. RAIDT does not claim to solve every Responsible AI issue, nor does it claim that run-level evidence removes uncertainty or guarantees lawful use. It does not replace domain expertise, legal judgement, or organisational accountability structures. It also does not assume that every run requires the same evidential burden. The appropriate depth of evidence depends on task criticality, sector, and use context. Even so, the central claim remains strong: when GenAI is used in organisational work, governance quality depends on whether a specific run can be reconstructed, interpreted, challenged, and improved. That is the historical and conceptual foundation of RAIDT.

Key questions and answers

Q1. What is the central historical problem that gave rise to RAIDT?

Answer:
RAIDT arose from the gap between broad Responsible AI principles and the practical need to govern specific uses of AI in uncertain organisational settings. The key issue was that organisations increasingly relied on AI-assisted outputs in contexts where evidence was incomplete, risks were dynamic, and accountability still had to be maintained.

Practical example:
A manager uses GenAI to draft a risk summary during a supply-chain disruption. The output influences action, but later nobody can show which sources, settings, or checks shaped that text.

Link to RAIDT:
RAIDT addresses this by making the individual run reviewable through an evidence pack and by scoring governance readiness across the five pillars.

Q2. Why is uncertainty so important to the origin of RAIDT?

Answer:
Uncertainty exposes the limits of simple automation logic. In uncertain settings, the question is not only whether a model performs well on average, but whether a specific output can be trusted, interpreted, and challenged in context.

Practical example:
A public-sector team asks a GenAI system to summarise policy options when the source landscape includes contested reports and rapidly changing guidance.

Link to RAIDT:
RAIDT requires evidence about context, retrieved sources, prompt design, and review steps so that uncertainty is made visible rather than hidden.

Q3. Why were Responsible AI principles not enough on their own?

Answer:
Responsible AI principles provide valuable normative direction, but they often stop at statements of what should matter rather than specifying what should be captured when AI is actually used. Principles need operational translation.

Practical example:
An organisation claims to value transparency, yet cannot show the exact prompt, model version, or review record behind a disputed GenAI output.

Link to RAIDT:
RAIDT translates principles into evidence requirements and scoring criteria, especially under Responsibility, Auditability, and Traceability.

Q4. What does RAIDT mean by a run?

Answer:
A run is one configured use of a GenAI system for a specific task, at a specific time, in a specific context. It includes the instruction, system and model configuration, tools, retrieval context where applicable, output, and human or automated checks.

Practical example:
A legal operations team runs a contract-clause summarisation workflow using a fixed template, a selected model, a retrieval layer over internal policies, and a reviewer sign-off.

Link to RAIDT:
The run is the primary unit captured in the evidence pack and the unit assessed by the RAIDT scoring profile.

Q5. Why does GenAI increase the need for run-level governance?

Answer:
GenAI outputs are shaped heavily by runtime conditions rather than by model architecture alone. Small changes in prompts, retrieval, tool invocation, or configuration can materially change outputs and risks.

Practical example:
The same user query produces two different recommendations because one run used live retrieval and another used only model memory.

Link to RAIDT:
RAIDT treats runtime configuration as governance-relevant evidence, which strengthens Auditability, Dependability, and Traceability.

Q6. What is the run-level evidence pack designed to prove?

Answer:
The evidence pack is designed to prove that a specific run can be reconstructed, reviewed, and challenged with enough fidelity to support organisational accountability. It shows what was asked, what configuration was active, what was retrieved, what was produced, and what checks followed.

Practical example:
After a disputed AI-generated client response, the organisation can recover the prompt version, source set, model version, output hash, and reviewer decision.

Link to RAIDT:
The evidence pack is one of the two core outputs of RAIDT and provides the factual basis for pillar scoring and governance intervention.

Q7. How do the five RAIDT pillars grow out of this origin story?

Answer:
The pillars operationalise the original governance problem. They turn broad concerns about oversight, transparency, reliability, and accountability into reviewable dimensions of a specific run.

Practical example:
A healthcare summarisation run may score well on Traceability because sources are logged, but poorly on Interpretability if clinicians cannot tell where uncertainty remains.

Link to RAIDT:
Responsibility, Auditability, Interpretability, Dependability, and Traceability provide the scoring structure that converts origin logic into operational assessment.

Q8. How does this note connect to RAG, PEFT/LoRA, and RLHF-style controls?

Answer:
These methods matter because they shape how a run behaves and therefore what evidence should be captured. They are not peripheral technical details; they are part of the governance surface.

Practical example:
A RAG workflow requires logging the retrieval query and retrieved documents, while a LoRA-adapted model requires recording the adapter version used in the run.

Link to RAIDT:
RAIDT treats such mechanisms as governable influence points that affect evidence pack completeness and pillar scores.

Q9. Why is this star important for supervisors and examiners?

Answer:
It explains the project?s coherence. Without this note, RAIDT could be misread as a loose collection of governance ideas, technical methods, and policy references. The origin story shows the single research logic connecting them.

Practical example:
During supervision, a reviewer asks why prompting experiments, evidence fields, and policy alignment all sit in one thesis.

Link to RAIDT:
This star shows that each component serves the same purpose: making specific GenAI runs governable, reviewable, and improvable.

Q10. What does this star not claim?

Answer:
It does not claim that RAIDT replaces legal compliance, guarantees correctness, or removes the need for human judgement and domain expertise. It also does not assume that one evidence burden fits every task.

Practical example:
A low-risk drafting task may require lighter evidence capture than a high-impact clinical or regulatory decision-support run.

Link to RAIDT:
RAIDT is a structured governance framework, not a universal substitute for law, professional standards, or context-sensitive judgement.

Practical examples

A hospital team uses GenAI to draft discharge summaries. RAIDT would require run-level capture of prompt version, retrieved patient-context constraints, model configuration, clinician review outcome, and any noted uncertainty before the summary is accepted.
A university administrator uses GenAI to prepare a policy briefing from internal documents and public guidance. RAIDT would make retrieval records, prompt instructions, and review decisions visible so that contested claims can be traced back and challenged.
A financial services team uses a LoRA-adapted model to classify and explain customer complaint themes. RAIDT would capture the adapter version, task boundaries, output checks, and evidence needed to assess whether the run remained dependable and auditable.
A local authority deploys a RAG-enabled assistant for case-note drafting. RAIDT would capture source provenance, prompt constraints, reviewer role, and downstream use so that organisational accountability does not end at model selection.

Evidence needed / what to capture

If this star is operationalised, the following evidence fields are especially relevant:

Run ID and timestamp
User, role, or accountable function
Task label and domain context
Stated purpose and permitted use boundary
Prompt ID, prompt version, and prompt hash
System instruction or workflow template version
Model ID, provider, and model version
Key configuration settings relevant to the run
Tool chain and tool-call record where applicable
Retrieval query, retrieval index, and retrieved source identifiers or hashes
Adapter or PEFT/LoRA version where used
Alignment or safety-control setting where relevant
Output text or output reference plus output hash
Reviewer identity or role, review decision, and review notes
Identified limitations, uncertainty notes, or contestability flags
RAIDT pillar scores and rationale
Governance intervention triggered, if any

Link to RAIDT project

This star connects directly to the wider RAIDT project in the following ways:

Paper 08: foundations and methodological pathways ? It provides the origin logic and explains why RAIDT is framed as a mechanism-based, evidence-oriented design pathway rather than a generic ethics model.
Paper 09: empirical validation ? It defines the variables that can be tested empirically, including how prompting, RAG, PEFT/LoRA, RLHF-style controls, and stacked configurations affect evidence quality and pillar scores.
Paper 10: policy pathways ? It shows why RAIDT can operate as a translation layer between operational practice and external governance expectations such as the EU AI Act, ISO/IEC 42001, and NIST AI RMF.
Sector playbooks ? It supports adaptation into domain-specific guidance by showing that the evidence burden should vary with task criticality, sector risk, and organisational use context.
RAIDT scoring ? It provides the rationale for why the five pillars are necessary and why scoring must be grounded in evidence from actual runs.
RAIDT evidence pack ? It justifies the evidence pack as the core accountability artefact for reconstructing, reviewing, and comparing configured uses of GenAI.
RAIDT governance interventions ? It explains why interventions such as prompt redesign, retrieval constraints, reviewer escalation, or evidence capture expansion are legitimate responses to observed run-level weaknesses.

Citation ideas to support this note

Responsible AI principles, accountability, transparency, and explainability literature
Information Systems governance and IT governance source categories
Auditability, accountability, and contestability literature in socio-technical systems
AI under uncertainty, decision support, and managerial uncertainty literature
GenAI governance and runtime risk literature
Prompt engineering, RAG, and system configuration documentation as technical support categories
PEFT/LoRA and alignment-control literature for model adaptation and behavioural shaping
Standards and policy materials related to the EU AI Act, ISO/IEC 42001, and NIST AI RMF
Empirical evaluation and design science or mid-range design theory source categories

Boundaries and limitations

This star explains why RAIDT emerged; it does not by itself validate the full framework empirically.
It does not claim that run-level evidence eliminates uncertainty, bias, or hallucination.
It does not replace legal compliance, professional judgement, or domain-specific assurance processes.
It does not imply that every GenAI interaction requires the same depth of logging or review.
It does not treat the five pillars as permanent or universal truths; they remain project-specific governance constructs that require empirical refinement.
It does not assume that evidence capture alone guarantees trustworthy outcomes; evidence must still be interpreted and acted upon.

Conclusion

RAIDT began from a simple but important research problem: organisations were starting to use AI, and later GenAI, in uncertain decision environments where accountability still mattered, but the available governance tools were too abstract. Responsible AI gave the project its normative language, such as transparency, accountability, and oversight, but it did not always specify what evidence needed to be captured when a particular AI output was produced and used. GenAI made that gap more serious because outputs depend heavily on runtime configuration, including prompts, retrieval, tools, model versions, and review steps. That led to the central design move in RAIDT: define the run as the unit of governance. A run is one configured use of a GenAI system in a specific context, and RAIDT asks whether that run can be reconstructed, reviewed, challenged, and improved. From that, the framework produces two practical outputs: a run-level evidence pack and a five-pillar score profile covering Responsibility, Auditability, Interpretability, Dependability, and Traceability. So this star matters because it explains why the whole project exists and why evidence at the point of use is the core contribution.

Suggested slide order for oral presentation

Why RAIDT had to emerge
The move from principles to evidence
Why the run becomes the governance unit
What the evidence pack captures
How the five pillars operationalise governance
Why this matters for research, policy, and sector application
What RAIDT does not claim
Why this star matters to the whole PhD project

Slides

Slide 1 — why RAIDT emerged

Purpose:
Frame the origin of the project and establish the problem space.

Key message:
RAIDT emerged because organisations needed a way to govern GenAI use in uncertain, high-stakes contexts with evidence rather than principles alone.

Slide content:

AI use expanded into uncertain organisational work
Responsible AI gave values but not enough operational evidence
GenAI increased runtime variability and governance pressure
RAIDT responds at the level of the configured run

Speaker note:
Use this slide to explain that RAIDT did not begin as a generic governance checklist. It came from the practical difficulty of governing AI-assisted work where outputs influence action but cannot easily be reconstructed later. Emphasise the combination of uncertainty, accountability pressure, and GenAI operational complexity.

Visual idea:
Problem pathway diagram from uncertainty -> Responsible AI -> GenAI governance gap -> RAIDT.

Link to RAIDT:
Introduces the core rationale for the framework and its run-level orientation.

Citation support to mention if asked:
Responsible AI principles, AI uncertainty literature, and Information Systems governance categories.

Slide 2 — from responsible AI to evidence-based governance

Purpose:
Show why normative principles required operational translation.

Key message:
Responsible AI says what should matter; RAIDT specifies what must be captured when GenAI is actually used.

Slide content:

Principles such as transparency and accountability remain necessary
Principles alone do not reconstruct a specific output
Governance requires evidence about real use in context
RAIDT translates values into inspectable artefacts

Speaker note:
Explain that RAIDT is not rejecting Responsible AI. It extends it. The issue is that high-level principles do not tell an auditor or supervisor what prompt was used, what sources were retrieved, or what checks were applied in a specific case.

Visual idea:
Two-column comparison: principle language on one side, evidence requirements on the other.

Link to RAIDT:
Justifies the evidence pack and the shift from abstract governance to operational governance.

Citation support to mention if asked:
Responsible AI, accountability, transparency, and contestability source categories.

Slide 3 — why the run is the unit of governance

Purpose:
Define the core conceptual move in the framework.

Key message:
In GenAI, the relevant governance object is the configured run, not only the model in abstraction.

Slide content:

A run is one configured use for one task in one context
Output depends on prompt, model, tools, retrieval, and checks
Accountability questions arise after a specific run
Governance therefore has to operate at run level

Speaker note:
Walk through the definition of a run carefully. Make clear that runtime configuration is not peripheral. It is often the reason why one output is safe and another is not, even when the same base model is used.

Visual idea:
Run anatomy diagram showing prompt, model, tools, retrieval, output, and review.

Link to RAIDT:
Defines the unit from which RAIDT evidence capture and scoring are built.

Citation support to mention if asked:
GenAI governance and runtime configuration source categories.

Slide 4 — what the evidence pack captures

Purpose:
Explain the first practical output of RAIDT.

Key message:
The run-level evidence pack makes a GenAI use reconstructable, reviewable, and challengeable.

Slide content:

Identity, purpose, and context of the run
Prompt, model, tool, and retrieval configuration
Output record and reviewer decision
Scores, notes, and governance actions

Speaker note:
Stress that the evidence pack is not just logging for its own sake. It is a governance artefact designed to support reconstruction, comparison, and intervention when something goes wrong or needs review.

Visual idea:
Evidence chain or table showing fields from run input to review outcome.

Link to RAIDT:
Represents one of the two core outputs of the framework.

Citation support to mention if asked:
Auditability, traceability, and provenance source categories.

Slide 5 — how the five pillars operationalise governance

Purpose:
Show how RAIDT converts evidence into an assessment structure.

Key message:
The five pillars turn governance concerns into reviewable and scoreable dimensions of a specific run.

Slide content:

Responsibility: purpose, ownership, oversight
Auditability: reconstruction and reviewability
Interpretability: meaning and limitation clarity
Dependability and Traceability: stability and source linkage

Speaker note:
Explain that the pillars are not decorative labels. They are the operational bridge between evidence capture and governance judgement. If a run cannot be reconstructed, Auditability is weak. If users cannot understand limitations, Interpretability is weak.

Visual idea:
Five-pillar wheel or scorecard.

Link to RAIDT:
Represents the second core output: the RAIDT score profile.

Citation support to mention if asked:
Responsible AI, assurance, and governance measurement categories.

Slide 6 — why technical methods matter to governance

Purpose:
Connect technical influence methods to governance logic.

Key message:
Prompting, RAG, PEFT/LoRA, and RLHF-style controls matter because they change run behaviour and the evidence needed to govern it.

Slide content:

Prompting shapes instruction and behavioural boundaries
RAG changes source grounding and traceability
PEFT/LoRA changes task adaptation and model behaviour
Alignment controls shape refusals and safety limits

Speaker note:
Clarify that RAIDT studies these methods as governance-relevant intervention points. The issue is not technical novelty alone, but how each method changes what can be explained, traced, reviewed, or challenged.

Visual idea:
Influence map linking technical methods to evidence and pillar impacts.

Link to RAIDT:
Supports empirical testing, evidence capture design, and governance intervention logic.

Citation support to mention if asked:
Prompt engineering, RAG, PEFT/LoRA, and alignment-control literature categories.

Slide 7 — why this star matters for papers 08, 09, and 10

Purpose:
Locate the note within the wider PhD project.

Key message:
This star provides the conceptual bridge from foundations to empirical validation and policy translation.

Slide content:

Paper 08: origin logic and methodological pathway
Paper 09: empirical comparison of governance readiness
Paper 10: translation to standards and policy frameworks
Sector playbooks: domain-specific operationalisation

Speaker note:
Use this slide to show thesis coherence. The same origin logic explains why the project contains conceptual framing, evidence fields, scoring, experiments, and policy alignment rather than treating them as unrelated outputs.

Visual idea:
Three-paper pathway with sector playbooks underneath.

Link to RAIDT:
Shows how this foundational note supports the full project architecture.

Citation support to mention if asked:
Design science, empirical governance evaluation, and policy framework categories.

Slide 8 — limits and value of the RAIDT origin story

Purpose:
Close with scope discipline and project significance.

Key message:
RAIDT does not solve every AI governance problem, but it provides a strong run-level basis for accountability in organisational GenAI use.

Slide content:

RAIDT does not replace law, judgement, or domain assurance
Not every run requires the same evidence burden
Evidence capture does not eliminate uncertainty
It does make governance more reviewable and improvable

Speaker note:
End by showing intellectual discipline. The value of RAIDT is not that it claims universal control over AI risk, but that it provides a tractable governance unit, a defensible evidence structure, and a clear scoring logic for live organisational use.

Visual idea:
Boundary diagram showing what RAIDT covers and what remains outside scope.

Link to RAIDT:
Reinforces the project?s practical contribution without overstating it.

Citation support to mention if asked:
Standards, governance assurance, and Responsible AI limitation debates.