Programme Architecture and Supervisory Navigation

Provides the supervisory map for the RAIDT programme. This star clarifies how the project hangs together as one coherent research agenda centred on run-level governance of generative AI, rather than as a loose collection of papers, artefacts, examples, or implementation fragments.

This note sits at the programme architecture and supervisory coordination level. Its role is not to introduce a new technical component of RAIDT, but to show how the foundational logic, core governance artefacts, empirical validation pathway, policy pathway, and sector translation work as one integrated PhD project. It therefore supports foundations, implementation logic, empirical validation, and policy communication at the level of overall project coherence.

• What does programme architecture mean in the RAIDT project?
• Why does RAIDT need a supervisory navigation note rather than only separate paper notes?
• What problem does this star solve for supervisors, examiners, and workshop participants?
• How are the core idea, the three-paper arc, component papers, and sector playbooks related but not confused?
• What evidence shows that RAIDT is a coherent research programme rather than a set of disconnected outputs?
• How does the programme architecture connect to the run-level evidence pack?
• How does the programme architecture connect to the five RAIDT pillars: Responsibility, Auditability, Interpretability, Dependability, and Traceability?
• How does this star help supervisors understand scope, sequencing, contribution, and validation?
• Where do standards and policy alignment fit without becoming the whole project?
• How should a supervisor read the project efficiently without losing the central organising idea?

• 10-20 min ? What is the minimum explanation a supervisor needs in order to distinguish RAIDT itself from its papers, score profile, evidence pack, and sector illustrations?
• 20-40 min ? Where is the strongest evidence that the project is architecturally coherent across Paper 08 foundations, Paper 09 empirical validation, and Paper 10 policy pathways?
• 40-60 min ? What boundaries, reading path, and scope-control rules are needed so that supervision stays focused on the run as the unit of governance rather than drifting into general AI ethics or generic compliance discussion?

• S12.01 ? Inputs
• S12.02 ? Core governance artefacts
• S12.03 ? Three-paper arc
• S12.04 ? Academic logic synthesis
• S12.05 ? Sector playbooks
• S12.06 ? Component papers
• S12.07 ? Supervisor reading path
• S12.08 ? Scope-control rule

RAIDT is best understood as a programme rather than a single artefact. Its central claim is that governance of organisational generative AI should be anchored at the level of the run: one configured use of a generative AI system for a specific task, at a specific time, in a specific context. A run includes the prompt or instruction, model and tool settings, retrieved context where relevant, output, and any human or automated checks. From that unit, RAIDT produces two practical outputs: a run-level evidence pack and a five-pillar score profile covering Responsibility, Auditability, Interpretability, Dependability, and Traceability. Star S12 exists to help supervisors see how the wider PhD programme is organised around that core logic.

The need for such a navigation note is methodological as well as practical. Supervisors are often presented with multiple kinds of material during a PhD: conceptual arguments, design propositions, pilot artefacts, scoring models, case examples, standards mappings, and papers written for different audiences. Without a clear programme architecture, these can appear to be parallel projects. S12 prevents that confusion. It explains that the core idea is not a sector case, not a compliance checklist, and not merely a prompt engineering method. Instead, the core idea is a governance framework that treats the run as the unit of evidence and intervention.

This matters because generative AI governance is often discussed at the wrong level of abstraction. High-level principles such as fairness, accountability, transparency, or safety are necessary, but they do not by themselves show what should be captured when an employee, analyst, manager, or public servant actually uses a model in practice. Conversely, highly technical discussions about RAG, PEFT or LoRA, reinforcement learning from human feedback, or tool routing can become disconnected from governance questions if they are discussed only as engineering choices. RAIDT links these levels. It asks what exactly happened in a run, what evidence was retained, what uncertainty remained, what controls were applied, and how those features contribute to a structured score profile.

S12 therefore performs a supervisory translation function. It shows that the project has inputs, governance artefacts, academic outputs, validation logic, and sector-facing translation, but that these are arranged in a disciplined sequence. Inputs include the responsible AI literature, information systems governance, organisational uncertainty, prompt engineering practice, audit and assurance concerns, and emerging policy frameworks such as the EU AI Act, ISO/IEC 42001, and the NIST AI RMF. Core governance artefacts include the definition of the run, the evidence pack structure, the scoring model, and the logic for governance interventions. The three-paper arc then explains how the programme develops: Paper 08 establishes the foundations and methodological pathway, Paper 09 tests the framework empirically, and Paper 10 connects the framework to policy pathways and standards alignment. Sector playbooks translate the framework into operational settings without changing the core concept.

A key contribution of this note is scope control. RAIDT touches many adjacent topics, including uncertainty, contestability, alignment controls, model adaptation, explainability, and organisational adoption. That breadth is a strength only if the project keeps its centre of gravity. S12 states that centre clearly: the project is about responsible governance of organisational generative AI through run-level evidence. The score profile and evidence pack are not add-ons; they are the operational form of the theory. Likewise, empirical work is not a separate stream that sits beside the framework. It is the means by which the utility, clarity, and robustness of the framework are tested.

The note also helps distinguish between what is essential and what is exemplary. For example, a retrieval-augmented generation workflow may provide strong material for discussing traceability because retrieved documents, retrieval settings, and source provenance can be recorded in the run-level evidence pack. A fine-tuned model using LoRA may raise different questions around configuration control, versioning, and dependability. RLHF or related alignment controls may influence the behaviour of the base system and affect responsibility and interpretability. These are important examples, but they remain examples. The architecture note reminds supervisors that RAIDT is not limited to one technical stack. Its value lies in offering a governance structure that can absorb variation in models, tools, and use contexts.

For supervisory purposes, S12 is also a reading protocol. It tells a reader where to start and how to interpret later materials. A sensible path is to begin with the foundational problem logic, then move to the definition of the run and the two main outputs, then examine how the five pillars are operationalised, then review the empirical and policy papers, and only afterwards move into sector playbooks or component papers. This order matters because supervisors otherwise risk judging a sector example before they have fully grasped the abstract contribution. The note therefore reduces misreading and improves the efficiency of supervision meetings.

The practical importance of S12 becomes even clearer when considering evidence. A coherent PhD project needs a clear line from problem to artefact to evaluation to contribution. In RAIDT, that line is: organisations use generative AI under conditions of uncertainty; existing governance arrangements often miss the granularity of actual use; the run is proposed as the correct unit of governance; the evidence pack and score profile operationalise that unit; empirical work tests whether this improves oversight, comparability, and intervention design; policy work shows how the framework can align with recognised standards and regulatory expectations. S12 assembles that chain in one place.

Its limitations are equally important. This star does not prove the framework on its own. It does not replace empirical validation, and it does not settle normative debates about all aspects of responsible AI. It also does not claim that every organisational AI risk can be fully resolved by run-level capture. Some risks arise upstream in training data, procurement, institutional incentives, or sector regulation. RAIDT instead claims that run-level evidence is a practical and governable layer that can materially improve accountability, traceability, and managerial decision-making in real organisational settings. That is a strong but bounded claim, and S12 helps supervisors keep that boundary in view.

Q1. What is meant by programme architecture in RAIDT?

Answer:
Programme architecture refers to the way the whole PhD is structured so that concepts, artefacts, papers, validation work, and sector applications support one central contribution. In RAIDT, that contribution is a run-level governance framework for organisational generative AI. Programme architecture therefore means showing how the conceptual foundations, evidence pack, scoring model, empirical work, and policy mapping fit together without duplication or drift.

Practical example:
A supervisor reviewing the project can distinguish between the core RAIDT framework, a healthcare playbook, and a policy mapping table instead of treating them as three separate projects.

Link to RAIDT:
This question matters because RAIDT depends on coherence between the run, the evidence pack, the five-pillar score profile, and the papers that justify and test them.

Q2. Why does RAIDT need a supervisory navigation note?

Answer:
RAIDT spans theory, artefact design, empirical validation, and policy alignment. Without a navigation note, a reader may understand one piece well but misread the whole. S12 reduces that risk by making the sequencing and logic explicit. It helps supervisors know what is foundational, what is evidential, what is illustrative, and what is out of scope.

Practical example:
During a progress review, the conversation stays focused on whether Paper 09 properly validates the evidence-pack approach rather than drifting into a broad debate about AI ethics in general.

Link to RAIDT:
The note protects the integrity of the RAIDT project and ensures the run-level evidence logic remains the organising centre.

Q3. What problem does this star solve?

Answer:
It solves the problem of conceptual congestion. Generative AI governance projects can quickly accumulate standards references, technical examples, scoring proposals, and sector cases. If these are not architecturally organised, the project can appear over-scoped or theoretically thin. S12 solves this by showing a disciplined map from problem statement to project outputs.

Practical example:
A workshop participant sees why RAG provenance capture belongs in the evidence pack discussion, while EU AI Act mapping belongs in the policy pathway discussion.

Link to RAIDT:
The star keeps evidence pack design, pillar scoring, and governance interventions connected but analytically distinct.

Q4. How does this note connect to the run-level evidence pack?

Answer:
The run-level evidence pack is one of RAIDT's two core outputs. S12 shows where that artefact sits in the wider programme. It explains that the evidence pack is not a data dump; it is the operational record that makes governance inspectable. The note also clarifies that later empirical and policy claims depend on the quality and consistency of this evidence structure.

Practical example:
If a manager wants to review a sensitive GenAI-assisted recruitment recommendation, the evidence pack should show the prompt, model version, retrieved sources, output, reviewer checks, and any escalation record.

Link to RAIDT:
The evidence pack is the mechanism through which auditability and traceability become concrete at the level of an actual run.

Q5. How does this note connect to the five pillars?

Answer:
S12 does not define each pillar in full, but it shows that the pillars are part of one scoring architecture rather than isolated criteria. Responsibility asks who is accountable and what oversight exists. Auditability concerns whether the run can be examined. Interpretability asks whether the system behaviour and outcome can be meaningfully explained. Dependability concerns reliability and consistency. Traceability concerns lineage across inputs, tools, outputs, and checks.

Practical example:
A low traceability score in a customer service chatbot run may trigger a governance intervention requiring better logging of retrieved documents and prompt templates.

Link to RAIDT:
The five-pillar profile is RAIDT's second practical output, and S12 shows how supervisors should interpret it alongside the evidence pack.

Q6. How does S12 help with scope control?

Answer:
It distinguishes core claims from adjacent interests. RAIDT can discuss prompt engineering, model adaptation, RAG, uncertainty, and standards, but it does not become a general theory of all AI governance. S12 keeps the project focused on organisational use, run-level evidence, and governance action.

Practical example:
A suggestion to add a full analysis of foundation model pre-training bias can be recognised as relevant background but outside the main scope unless it directly affects run-level governance design.

Link to RAIDT:
Scope control protects the clarity of the evidence pack, scoring model, and intervention logic.

Q7. What evidence proves the programme is coherent?

Answer:
Coherence is shown by alignment across problem definition, artefact design, validation strategy, and policy translation. If the same run-level logic explains the evidence pack, supports the scoring model, structures empirical data collection, and maps credibly to standards and governance expectations, the programme is coherent.

Practical example:
An empirical study collects run records from multiple organisational settings and uses them to test whether the RAIDT score profile reveals actionable governance gaps.

Link to RAIDT:
This is how Paper 08, Paper 09, Paper 10, and the sector playbooks become linked outputs of one framework.

Q8. How does this star support supervisors in practice?

Answer:
It gives supervisors a reading path, a decision path, and a challenge path. The reading path shows what to read first. The decision path shows which parts carry the main contribution. The challenge path shows where to test the project: definitional clarity, evidence sufficiency, empirical validity, policy relevance, and boundaries.

Practical example:
A supervisor preparing for a meeting can review this star first, then inspect the three-paper arc and only then move into component papers.

Link to RAIDT:
This improves governance of the research project itself, mirroring RAIDT's concern with structured evidence and explicit decision points.

Q9. Why is this note important for Paper 09 and Paper 10 as well as Paper 08?

Answer:
Paper 08 can establish the conceptual logic, but a PhD is judged partly on whether the framework can be examined in practice and translated into policy-relevant language. S12 shows that empirical validation and policy pathways are not optional extras; they are necessary extensions of the same argument. Without them, RAIDT may appear elegant but insufficiently tested or insufficiently actionable.

Practical example:
A pilot in a public-sector setting can show whether the RAIDT evidence pack supports contestability and audit readiness in a way that resonates with policy stakeholders.

Link to RAIDT:
Paper 09 validates the framework in use, and Paper 10 shows how RAIDT can inform standards alignment and governance interventions across sectors.

1. A university uses a generative AI assistant to draft formative student feedback. S12 helps supervisors distinguish the general educational case from the core RAIDT contribution: the capture of the prompt, rubric, model configuration, human review, and resulting score profile for each run.
2. An HR team uses a RAG-enabled assistant to draft job descriptions from internal policy documents. The architecture note clarifies that the sector example demonstrates RAIDT's traceability and auditability logic rather than redefining the framework for HR alone.
3. An insurer pilots a fine-tuned claims-support model. S12 helps show that LoRA configuration, version control, and reviewer escalation become evidence fields within RAIDT rather than separate governance systems detached from the run.
4. A public-sector procurement team evaluates generative AI use under policy scrutiny. The note helps connect run-level evidence to standards alignment, contestability, and governance interventions without collapsing the project into pure regulatory compliance.

• Statement of the core research problem and why run-level governance is needed

• Definition of a run, including task, timing, context, prompt, model, tools, retrieved context, output, and checks

• Description of the run-level evidence pack fields and retention logic

• Definition of the five pillars and the rationale for the scoring profile

• Mapping between pillars, evidence fields, and governance interventions

• Explanation of how component papers support, extend, or test the core framework

• Clear articulation of the three-paper arc: foundations, empirical validation, policy pathways

• Evidence of use cases or sector playbooks that demonstrate transferability without changing the core concept

• Policy and standards alignment notes, especially where EU AI Act, ISO/IEC 42001, and NIST AI RMF provide relevant framing

• Boundary statements showing what RAIDT does and does not claim

• Supervisor reading path and scope-control rule so that the project remains coherent across reviews

S12 is the note that makes the whole RAIDT programme legible.

• Paper 08: foundations and methodological pathways ? This star shows where the foundational problem logic sits and why the run becomes the unit of governance.
• Paper 09: empirical validation ? It clarifies what must be tested in practice: whether the evidence pack and five-pillar profile improve oversight, comparability, and governance action across real organisational runs.
• Paper 10: policy pathways ? It positions standards and policy alignment as downstream translation of the framework, not the framework itself.
• Sector playbooks ? It explains how sector applications demonstrate usability and contextual adaptation without altering RAIDT's central design.
• RAIDT scoring ? It shows that scoring is one of the two practical outputs and must be interpreted alongside evidence capture.
• RAIDT evidence pack ? It places the evidence pack at the operational centre of governance, auditability, and traceability.
• RAIDT governance interventions ? It clarifies that the purpose of evidence and scoring is not description alone, but informed intervention such as escalation, review, retraining, prompt redesign, access control, or policy adjustment.

• Responsible AI governance frameworks and assurance literature
• Information Systems governance and organisational control literature
• Literature on uncertainty in managerial decision-making and digital systems
• Generative AI governance studies focused on documentation, logging, and accountability
• Prompt engineering and RAG evaluation literature where provenance and context management matter
• Model adaptation and alignment control literature relevant to configuration traceability
• Standards and policy materials linked to the EU AI Act, ISO/IEC 42001, and NIST AI RMF
• Empirical methods literature for socio-technical validation of governance artefacts

• This note does not replace the substantive theory notes that define RAIDT's concepts in depth.
• It does not itself validate the framework empirically; that work belongs to Paper 09 and related evidence.
• It does not claim that run-level evidence resolves every upstream or institutional risk in generative AI.
• It does not collapse RAIDT into one sector, one model family, one prompting method, or one compliance regime.
• It does not treat standards alignment as sufficient proof of governance quality; alignment is supportive, not exhaustive.
• It is a navigation and architecture note, so its main task is coherence, sequencing, and scope control.

RAIDT can look broad because it includes conceptual work, artefact design, scoring logic, empirical validation, policy alignment, and sector examples. This star exists to stop that breadth becoming confusion. The central point is that RAIDT is one programme organised around the run as the unit of governance for generative AI in organisational work. From that unit, the project produces two practical outputs: a run-level evidence pack and a five-pillar score profile. Everything else in the PhD should be read in relation to those outputs. Paper 08 establishes the conceptual and methodological logic. Paper 09 tests whether the framework works in practice. Paper 10 shows how the framework can speak to policy and standards. Sector playbooks illustrate transferability, but they are not the core contribution. So this note helps supervision by making the architecture explicit: what the project is, how the parts fit together, what counts as evidence, and where the boundaries sit.