Foundational problem logic

This circle establishes the foundational problem logic for RAIDT. It explains why generative AI governance in organisational work cannot stop at high-level principles, model documentation, or policy statements, and why governance must instead be anchored in the run: one configured use of a GenAI system for a specific task, at a specific time, in a specific context. The note clarifies the underlying problem space, shows where current governance approaches fall short, and frames the need for run-level evidence, scoring, and targeted governance intervention across the five RAIDT pillars.

This is a foundations note with strong links to theory, evidence design, and later implementation. It contributes the conceptual basis for the whole RAIDT project by defining the practical governance problem that RAIDT is designed to solve. In project terms, it sits at the intersection of foundations, Information Systems governance, Responsible AI, and managerial uncertainty. It is therefore central to Paper 08 because it explains the methodological and conceptual pathway into RAIDT, central to Paper 09 because it identifies what must later be validated empirically, and central to Paper 10 because it shows why policy pathways need operational evidence rather than abstract compliance claims. It also provides the framing logic needed for sector playbooks, RAIDT scoring, evidence-pack design, and governance interventions.

• Star S1 - Origins, Background and History — Explains why the project emerged from Responsible AI, managerial uncertainty, IS governance, audit traditions, alignment concerns, and the operational pressure created by live GenAI use in organisations.
• Star S2 - Governance Meaning and Problem Context — Clarifies governance as oversight, control, accountability, reviewability, contestability, and continuous improvement rather than a vague ethics label, and shows why those functions must be tied to evidence from real runs.

• What does foundational problem logic mean in the context of RAIDT?
• Why does RAIDT need a distinct problem statement rather than relying on generic Responsible AI language?
• What exactly is the governance gap created by day-to-day generative AI use in organisations?
• Why is the run, rather than only the model or policy, the correct unit of governance?
• What problem does run-level evidence solve for managers, supervisors, auditors, and policy stakeholders?
• What kinds of uncertainty, failure, and accountability gaps appear when prompts, tools, retrieved context, or model settings change from one run to another?
• What evidence would prove that a governance system is actually reviewable and auditable in practice?
• How does this logic connect to the run-level evidence pack?
• How does it connect to the five RAIDT pillars: Responsibility, Auditability, Interpretability, Dependability, and Traceability?
• How does this circle help supervisors understand the intellectual contribution of RAIDT across Papers 08, 09, and 10?

• 10–20 min — What is the real governance problem in organisational GenAI use: weak ethics language, poor controls, missing evidence, unstable outputs, or all of these together?
• 20–40 min — If two staff members use the same model but with different prompts, retrieval sources, tools, and checking routines, should governance treat those as the same system or as distinct runs requiring separate evidence?
• 40–60 min — Which RAIDT pillar is most essential for turning Responsible AI from principle into operational practice, and what evidence would a supervisor expect to see?

RAIDT begins from a simple but often neglected observation: most organisational uses of generative AI are not static systems. They are episodes of configured use. A member of staff issues a prompt, selects or inherits a model configuration, may connect a retrieval system, may use tools or external documents, receives an output, and may then revise, approve, reject, or escalate that result. This single episode is what RAIDT calls a run. The foundational problem logic for RAIDT is that governance mechanisms have usually been built above this level or below it, but not at it. Organisations often have broad AI principles, procurement controls, and general model documentation; at the same time, they have local user practices, improvised prompts, ad hoc checking, and uncertain accountability. The run-level space between these two is precisely where many practical governance failures occur.

This matters because generative AI does not behave like a fixed decision rule. Outputs are sensitive to instruction wording, retrieved context, user role, tool access, temperature or related settings, and the quality of post-generation checking. The same model can produce a careful, bounded answer in one run and a misleading or unsafe answer in another. A model card or policy statement therefore tells only part of the story. It may describe the system in general, but it does not show what happened in the specific case that created a recommendation, a summary, a draft, a diagnosis-support output, or a policy briefing. For governance, this is a serious weakness. When something goes wrong, managers need to know not only what model was used, but how it was used, on what basis, with what evidence, and with what controls.

The circle therefore links three traditions that are often discussed separately. The first is Responsible AI, which has helped establish important normative concerns such as fairness, accountability, transparency, human oversight, and safety. The second is Information Systems governance, which focuses on control, assurance, risk ownership, escalation, and organisational accountability. The third is the practical reality of generative AI deployment, where prompt engineering, retrieval-augmented generation, tool use, fine-tuning choices such as PEFT or LoRA, and alignment controls such as RLHF-related guardrails all shape what a user actually receives in a given run. RAIDT argues that these traditions need a common operational unit. The run supplies that unit.

From this perspective, the foundational problem is not simply that AI is risky. It is that organisations often cannot evidence what happened in the exact moment where risk, judgement, and action came together. If a GenAI assistant generates an inaccurate legal summary, a misleading financial recommendation, a weak clinical drafting suggestion, or a biased HR shortlist explanation, post-hoc discussion frequently lacks the evidence needed to reconstruct the event. Which prompt version was used? What retrieved documents were supplied? Was external retrieval enabled? Were any tools called? Which human checks were completed? Was the output accepted, edited, or overridden? Without this level of detail, review becomes impressionistic rather than auditable.

RAIDT responds by treating the run as the unit of governance and by generating two practical outputs. The first is a run-level evidence pack. This pack records the key elements of a specific run: task context, actor role, prompt or instruction, model and tool configuration, retrieved context where relevant, output, checks, decisions, exceptions, and accountability metadata. The second is a five-pillar RAIDT score profile that evaluates the run or workflow in terms of Responsibility, Auditability, Interpretability, Dependability, and Traceability. This does not eliminate uncertainty, but it makes uncertainty governable. Instead of asking whether an AI system is simply trustworthy in the abstract, RAIDT asks whether a specific use instance is evidenced well enough to be reviewed, challenged, improved, and governed.

The importance of this move is practical as well as theoretical. In many organisations, generative AI use is spreading faster than formal control systems. Staff may use large language models for drafting reports, synthesising documents, coding, reviewing contracts, summarising meetings, or generating customer responses. In retrieval-based settings, the output may depend heavily on whatever documents were retrieved. In adapted systems, a PEFT or LoRA layer may shift behaviour in ways not visible to casual users. In aligned systems, RLHF-style controls may reduce some harms while leaving hallucination, overconfidence, or context failure unresolved. The governance problem is therefore dynamic. A run-level approach is needed because the combination of instruction, model, data access, and checking protocol is what produces operational risk.

This is also where the five RAIDT pillars become more than labels. Responsibility asks who owned the task, who reviewed the output, and who had authority to act. Auditability asks whether a later reviewer can reconstruct what happened and judge whether the controls were adequate. Interpretability asks whether users and reviewers can understand why the run produced the type of answer it did, at least to a level sufficient for governance. Dependability asks whether the run was stable, usable, and sufficiently robust for the intended context. Traceability asks whether the run can be linked across inputs, outputs, evidence, decisions, and governance records. In combination, these pillars transform governance from principle declaration to operational assessment.

The note also has a policy dimension. Emerging frameworks such as the EU AI Act, ISO/IEC 42001, and the NIST AI RMF all point, in different ways, towards documented controls, accountability allocation, risk management, and reviewability. RAIDT does not claim to replace these frameworks. Rather, it offers a way to operationalise their intent at the level where organisational use actually happens. This is why Circle 1 matters to Paper 10: policy pathways need translation into evidence practices. It also matters to Paper 09, because empirical validation must test whether run-level evidence and RAIDT scoring improve real governance outcomes such as review quality, escalation, learning, and confidence under uncertainty.

A final strength of this foundational logic is that it clarifies boundaries. RAIDT is not claiming that every run can be made fully transparent, that all uncertainty can be removed, or that scoring alone guarantees safe use. It does claim that organisational GenAI governance becomes materially stronger when the unit of analysis matches the unit of use. By making runs visible, comparable, and reviewable, RAIDT creates a disciplined basis for evidence packs, governance interventions, sector playbooks, and future empirical testing. Circle 1 therefore provides the conceptual bridge from broad Responsible AI concerns to a practical governance architecture that can actually be implemented, challenged, and improved.

Q1. What is meant by foundational problem logic in RAIDT?

Answer:
Foundational problem logic is the explanation of why RAIDT needs to exist at all. It identifies the underlying governance problem created by organisational use of generative AI and shows why existing approaches do not adequately address it. In RAIDT, the problem is not merely that AI can be biased, opaque, or inaccurate. The deeper issue is that organisations often cannot reconstruct, evaluate, or govern the specific run in which a meaningful output was produced.

Practical example:
A policy officer uses a large language model to draft a briefing note. The organisation has an AI policy, but it cannot show what prompt was used, what source documents were retrieved, or what checks were applied before circulation.

Link to RAIDT:
This logic directly motivates the run-level evidence pack and explains why RAIDT scoring must assess real use instances rather than only high-level system claims.

Q2. Why is the run the unit of governance rather than only the model?

Answer:
A model is only one component of the actual governance event. Real organisational outcomes are produced through a combination of prompt, user intent, model settings, tools, retrieved context, and review practice. Governing only the model misses the way risk is created in use. The run is the smallest meaningful unit in which governance-relevant factors come together.

Practical example:
Two analysts use the same model. One asks for a broad market summary with no retrieval and no checking. The other uses a structured prompt, retrieves approved internal reports, and submits the output for manager review. The model is the same, but the governance quality of the two runs is very different.

Link to RAIDT:
RAIDT defines the run as the core evidence unit and then scores that unit across the five pillars to support oversight and intervention.

Q3. What problem does RAIDT solve that Responsible AI frameworks alone do not solve?

Answer:
Responsible AI frameworks are valuable because they define normative aims, but they often remain too abstract for day-to-day organisational control. They may tell an organisation to ensure accountability or transparency without specifying what evidence must be captured when a staff member uses GenAI in practice. RAIDT fills that operational gap.

Practical example:
A team states that humans remain in the loop, yet no record exists of who reviewed the generated output, what they checked, or whether they overrode it. The principle exists, but the evidence is missing.

Link to RAIDT:
RAIDT converts abstract Responsible AI goals into evidential requirements, scoreable criteria, and governance actions at run level.

Q4. How does uncertainty shape the need for RAIDT?

Answer:
Generative AI introduces technical and managerial uncertainty. Technically, outputs may vary across prompts, contexts, and system configurations. Managerially, leaders may not know when staff are using GenAI, how strongly outputs depend on retrieved material, or whether local practices are reliable. RAIDT is needed because governance under uncertainty requires documented evidence, not assumption.

Practical example:
A manager approves an AI-assisted customer response process believing it is low risk. Later, a complaint reveals that staff have been pasting sensitive contextual information into prompts and relying on unverified summaries.

Link to RAIDT:
The evidence pack captures uncertainty-relevant variables, and RAIDT scoring helps identify where governance confidence is weak or conditional.

Q5. How does the run-level evidence pack support governance?

Answer:
The evidence pack supports governance by making the run reviewable after the fact and improvable over time. It captures what was asked, what system configuration was used, what context was supplied, what result was generated, and what checking or approval steps followed. This creates a basis for audit, escalation, learning, and policy refinement.

Practical example:
A hospital administration team uses GenAI to draft patient communication templates. When one output is challenged, the evidence pack shows the instruction template, retrieval source, versioned prompt, reviewer sign-off, and later correction.

Link to RAIDT:
The evidence pack is one of RAIDT's two central outputs and is the practical instrument that allows the five-pillar score profile to be justified.

Q6. How do the five RAIDT pillars arise from the foundational problem logic?

Answer:
The pillars are not arbitrary categories. They emerge from the kinds of governance failure that occur when runs are poorly documented or weakly controlled. Responsibility addresses ownership and decision rights. Auditability addresses reconstruction and review. Interpretability addresses meaningful explanation. Dependability addresses reliability in context. Traceability addresses linkage across the evidence chain.

Practical example:
A procurement chatbot gives inconsistent supplier guidance. Investigation shows there was no clear owner, no record of the retrieved policy version, and no way to trace how the answer was generated.

Link to RAIDT:
The foundational logic explains why each pillar matters and why scoring across all five gives a more actionable picture than a single trust label.

Q7. Why does prompt engineering matter to governance, not just performance?

Answer:
Prompts are governance-relevant because they shape task framing, role instruction, output format, and the boundaries placed on the model. Poor prompting can invite unsupported certainty, incomplete reasoning, or misuse of sources. Strong prompting can reduce ambiguity, improve reviewability, and support safer use.

Practical example:
A legal team switches from an open-ended prompt to a structured prompt that requires source citation, uncertainty flags, and explicit indication of missing evidence. The outputs become easier to review and less likely to be over-trusted.

Link to RAIDT:
RAIDT treats prompts as evidence-bearing artefacts within the run and therefore as part of the basis for scoring and control design.

Q8. How do RAG, PEFT/LoRA, and alignment controls change the governance problem?

Answer:
These mechanisms alter the behaviour of a run by changing what the model can access, how it has been adapted, or how its outputs are shaped. Retrieval-augmented generation changes the evidential basis of the answer. PEFT or LoRA can alter domain behaviour. RLHF-style alignment controls may constrain tone or refusal patterns but do not remove all error modes. Governance must therefore account for the full configuration, not just the base model name.

Practical example:
An internal support assistant appears reliable during testing, but later answers shift after a retrieval index update and a lightweight adaptation. Staff notice the difference, yet the organisation lacks records of the changed configuration.

Link to RAIDT:
RAIDT requires these configuration elements to be captured in the evidence pack so that traceability and dependability can be assessed meaningfully.

Q9. What kind of evidence would prove that governance is working?

Answer:
Good governance is evidenced by the ability to reconstruct important runs, justify decisions, identify control gaps, and show learning over time. Evidence includes run records, reviewer actions, escalation logs, version histories, exception handling, and scored pillar profiles tied to concrete criteria.

Practical example:
A regulator asks how an organisation handled AI-assisted drafting in a sensitive workflow. The organisation can show sample evidence packs, risk thresholds, review procedures, and records of changes made after incidents.

Link to RAIDT:
This is exactly the form of proof RAIDT is designed to produce through evidence packs, score profiles, and governance interventions.

Q10. How does Circle 1 help supervisors understand the overall PhD contribution?

Answer:
Circle 1 gives supervisors the conceptual map of the project. It explains the problem, identifies the governance gap, defines the unit of analysis, and shows why the later methodological, empirical, and policy components are coherent. Without this circle, RAIDT could look like a toolkit in search of a problem. With it, the project has a clear scholarly and practical rationale.

Practical example:
During supervision, a reader asks whether RAIDT is simply another Responsible AI checklist. Circle 1 shows that the contribution is more specific: a run-level evidential governance framework for organisational GenAI use.

Link to RAIDT:
This note anchors the logic behind Paper 08, sets up what Paper 09 must test, and clarifies why Paper 10 focuses on operational policy pathways rather than abstract principle statements.

• AI-assisted policy drafting in central government: A civil servant uses GenAI to draft a ministerial brief. The risk is not only whether the model is generally capable, but whether the specific run used current source material, framed uncertainty correctly, and received appropriate human review. RAIDT would require capture of the prompt, retrieved documents, output, and approval chain.
• RAG-enabled compliance assistant in a bank: Staff ask a chatbot for compliance guidance. The major governance issue is whether the answer came from the correct policy set, whether the retrieval was current, and whether staff can trace the answer back to approved materials. RAIDT makes the evidence chain visible and scoreable.
• HR screening support workflow: Recruiters use a model to summarise candidate materials. Even if no automated decision is made, weak documentation can obscure bias risks, inconsistent prompts, and unclear human accountability. RAIDT would support responsibility allocation, review logging, and challenge routes.
• Internal coding assistant for software teams: Developers use a model connected to tools and repositories. Governance concerns include source provenance, reliability of generated code, and whether security checks occurred before deployment. RAIDT can record the run configuration, tool usage, checks performed, and resulting governance actions.

• Run identifier, date, time, business unit, workflow, and task purpose
• User role, reviewer role, decision owner, and escalation contact
• Prompt or instruction text, template version, and any system prompt constraints
• Model name, provider, version, relevant parameters, and adaptation status such as PEFT or LoRA
• Tool configuration, retrieval setting, connected data sources, and document versions where RAG is used
• Input context classification, including sensitivity, policy relevance, and sector-specific risk markers
• Output content or output reference, confidence or uncertainty markers, and intended use
• Human checks performed, automated checks performed, and whether the output was accepted, edited, rejected, or escalated
• Pillar-level observations for Responsibility, Auditability, Interpretability, Dependability, and Traceability
• Incident flags, exceptions, corrective actions, and lessons for future governance intervention

• Paper 08: foundations and methodological pathways — This note provides the core conceptual justification for RAIDT by defining the problem space, the run as the unit of analysis, and the logic that leads to evidence-pack design and five-pillar scoring.
• Paper 09: empirical validation — The note identifies what must be tested empirically: whether run-level evidence improves reviewability, control quality, supervisory confidence, and practical governance decisions under uncertainty.
• Paper 10: policy pathways — The note shows why standards and regulatory frameworks require operational translation, and why RAIDT can function as a bridge between policy intent and day-to-day evidence practice.
• Sector playbooks — The foundational logic can be adapted into sector-specific playbooks by varying evidence fields, escalation criteria, and acceptable control thresholds for different domains.
• RAIDT scoring — The note explains why the five pillars are necessary and how they emerge from real governance needs rather than from abstract classification.
• RAIDT evidence pack — The note provides the rationale for the evidence pack as a practical artefact for audit, review, contestability, and learning.
• RAIDT governance interventions — The note justifies interventions such as stronger prompt controls, approval thresholds, retrieval restrictions, reviewer sign-off, incident escalation, and policy updates based on run-level findings.

• Responsible AI literature on accountability, transparency, human oversight, and contestability
• Information Systems governance literature on control, assurance, audit trails, and managerial accountability
• Organisational uncertainty literature, especially managerial uncertainty and decision-making under incomplete information
• Generative AI governance literature on hallucination, over-reliance, prompt sensitivity, and socio-technical risk
• Technical literature on prompt engineering, RAG, model adaptation through PEFT or LoRA, and alignment controls such as RLHF
• Standards and policy sources related to the EU AI Act, ISO/IEC 42001, and NIST AI RMF
• Audit and assurance literature relevant to evidence chains, traceability, and reviewable decision processes
• Empirical methods literature on validation of governance frameworks in live organisational settings

• This note does not claim that all generative AI risk can be solved by better documentation alone.
• It does not claim that a run-level evidence pack can fully explain model internals or eliminate opacity.
• It does not assume that every organisational use case requires the same depth of evidence capture.
• It does not replace legal compliance, sector regulation, or formal risk management frameworks.
• It does not argue that scoring is a substitute for human judgement; scoring is a structured aid to governance.
• It does not claim that run-level governance removes the need for upstream model evaluation, procurement review, or policy design.

Circle 1 explains the core problem that RAIDT is trying to solve. The issue is not simply that generative AI can produce errors, but that organisations often lack evidence about the specific run in which an output was produced. Existing governance often sits at the level of broad principles, policies, or model documentation, while actual operational risk emerges in configured episodes of use: a prompt, a model, optional retrieval, optional tools, an output, and some form of checking. RAIDT argues that this run is the correct unit of governance. Once that is accepted, the project becomes much clearer. The run-level evidence pack is needed so that a reviewer can reconstruct what happened, who was responsible, what context was used, and what controls were applied. The five pillars then provide a structured way to assess the quality of governance for that run. So this circle is foundational because it gives the PhD its problem statement, its unit of analysis, and its bridge from Responsible AI and IS governance theory to a practical method that can be empirically tested and translated into policy pathways.