Academic, adoption and boundary layer

This circle explains how RAIDT moves from a core conceptual framework into an academically defensible, operationally adoptable, policy-aware, and empirically testable governance approach. It clarifies how run-level evidence, the evidence pack, and the five-pillar RAIDT score can be understood by supervisors, researchers, practitioners, and assurance stakeholders without diluting the central claim that the run is the unit of governance.

This note acts as the outer translation layer of the RAIDT project. It does not redefine the core concept; rather, it shows how the concept is positioned, implemented, evaluated, bounded, and explained. In project terms, this circle links foundations to application. It therefore sits across theory, implementation, policy, empirical validation, limitations, and programme architecture. For PhD supervision, this note is especially important because it shows that RAIDT is not only a conceptual claim about responsible AI, but also a structured research programme with clear adoption logic, evidence requirements, and policy relevance.

• Star S7 - Academic Theory and Design Logic ? Positions RAIDT as a design-science, mechanism-based, mid-range contribution to Information Systems, organisational governance, and responsible AI scholarship.
• Star S8 - Implementation and Operations ? Shows how RAIDT can be used manually, semi-automatically, or through orchestration so that run-level governance becomes part of everyday organisational work.
• Star S9 - Policy, Standards and Assurance ? Connects RAIDT to policy instruments, assurance logics, standards alignment, procurement, audit, and accountability expectations.
• Star S10 - Empirical Programme, Domains and Sector Playbooks ? Explains how RAIDT is validated, calibrated, and adapted across domains, tasks, and sector-specific governance playbooks.
• Star S11 - Boundaries, Limitations and Future Questions ? Prevents overclaiming by making explicit what RAIDT can support, what it cannot resolve, and what remains an open research question.
• Star S12 - Programme Architecture and Supervisory Navigation ? Helps supervisors and workshop participants understand how the RAIDT papers, constructs, demonstrations, and sector examples fit together as one coherent programme.

• What does the academic, adoption, and boundary layer mean in the RAIDT architecture?
• Why does RAIDT need an outer layer beyond its core run-level model?
• What problem does this circle solve for supervisors, reviewers, and adoption stakeholders?
• How does RAIDT connect theory, implementation, policy, and empirical validation without becoming conceptually vague?
• What evidence would show that RAIDT is not merely a conceptual framing device but a usable governance instrument?
• How does this circle connect to the run-level evidence pack?
• How does this circle connect to the five RAIDT pillars of Responsibility, Auditability, Interpretability, Dependability, and Traceability?
• How does it help explain RAIDT to Information Systems scholars, organisational decision-makers, and assurance audiences?
• How do standards and policy references such as the EU AI Act, ISO/IEC 42001, and the NIST AI RMF relate to RAIDT without defining it completely?
• Where are the boundaries of RAIDT, and why is stating those boundaries academically necessary?

• 10-20 min ? Ask whether RAIDT is best understood primarily as a governance framework, a design-science artefact, a scoring method, or an evidence discipline, and identify what is gained or lost under each framing.
• 20-40 min ? Discuss what an organisation would actually need to change in order to adopt RAIDT at run level, including roles, prompts, tooling, evidence capture, review routines, and escalation paths.
• 40-60 min ? Debate the limits of RAIDT: which problems can be improved through run-level evidence and scoring, and which problems remain outside its scope, such as wider institutional power, model pre-training opacity, or strategic misuse.

Circle 3 is the point in the RAIDT architecture where the project becomes legible beyond its core conceptual mechanics. The earlier logic of RAIDT establishes that generative AI governance should be organised around the run: one configured use of a GenAI system for a specific task, at a specific time, in a specific organisational context. A run includes the instruction or prompt, model and tool configuration, retrieved context where relevant, the produced output, and the checks performed by people or systems. From that unit, RAIDT generates two practical outputs: a run-level evidence pack and a five-pillar score profile covering Responsibility, Auditability, Interpretability, Dependability, and Traceability. Circle 3 explains why that architecture matters academically, how it can be adopted in practice, how it aligns with policy and standards, how it should be empirically tested, and where its limits sit.

The key idea in this circle is that a governance framework is not persuasive merely because its internal logic is coherent. For a PhD project, RAIDT must also show theoretical positioning, implementation feasibility, empirical tractability, and defensible boundaries. In other words, the project must answer not only ?what is RAIDT?? but also ?how would this be used??, ?what evidence would support it??, ?how does it relate to existing governance instruments??, and ?what does it not claim to solve??. This is why Circle 3 functions as an academic, adoption, and boundary layer rather than a duplicate of the core model.

The problem addressed here is common in responsible AI and Information Systems research. Many governance frameworks are strong at the level of principle but weak at the level of operational evidence. They may specify desirable values such as fairness, accountability, transparency, safety, or human oversight, yet they struggle to show what should be recorded during actual system use, who should review it, how it should be scored, and how governance interventions should be triggered. Conversely, some technical assurance approaches produce narrow metrics while ignoring managerial uncertainty, organisational routines, or policy interpretation. RAIDT attempts to bridge that gap by making the run governable as an observable unit of action. Circle 3 is where that bridging claim is defended.

From an academic perspective, this circle positions RAIDT as more than a checklist. It can be framed as a design-science contribution because it proposes an artefact for governing organisational GenAI use. It also has a mechanism-based quality because it specifies how evidence capture, structured review, and pillar scoring may change decision quality and accountability behaviour. In Information Systems terms, it sits at the intersection of digital governance, socio-technical control, and managerial response to uncertainty. Generative AI creates uncertainty not only because outputs may be inaccurate, unstable, or context-sensitive, but also because organisations often do not know which combination of prompt engineering, retrieval augmentation, human review, and escalation is sufficient for a particular task. RAIDT addresses that uncertainty by making each run inspectable and comparable.

This matters for adoption because organisational users rarely implement governance in the abstract. They need routines. A manual deployment of RAIDT might begin with a template that captures prompt, task purpose, model version, retrieved sources, output, reviewer role, and identified risks. A semi-automated deployment might populate those fields from system logs and ask a reviewer to complete exception handling. A more advanced orchestration could connect prompt management, retrieval logs, model metadata, and review workflows into a structured evidence pack. Circle 3 clarifies that RAIDT is compatible with varying levels of maturity. It can therefore support early-stage governance as well as more formal assurance environments.

This circle also matters because RAIDT must be intelligible in relation to policy and standards without being reduced to them. The EU AI Act, ISO/IEC 42001, and the NIST AI RMF provide governance expectations, management system logic, and risk-management language. RAIDT does not replace those instruments and does not claim automatic compliance. Instead, it offers a run-level evidential layer that may help organisations demonstrate how governance is enacted in practice. The evidence pack can support auditability and traceability; the score profile can support targeted governance interventions; and the structured review of prompts, retrieved context, outputs, and checks can support accountability conversations. Circle 3 therefore shows how RAIDT can align with policy pathways while remaining a distinct contribution.

The empirical role of this circle is equally important. RAIDT should not be presented as valid simply because the idea appears sensible. It requires empirical validation through comparative use, expert judgement, sector testing, and calibration across different organisational settings. For example, a university administrator using GenAI to draft student-facing guidance, a hospital team summarising non-diagnostic documents, a legal operations team preparing clause comparisons, and a public-sector unit triaging citizen queries all face different risk thresholds and evidence expectations. Circle 3 explains why sector playbooks matter: the run-level logic remains stable, but the evidence requirements, scoring sensitivity, and governance interventions must be adjusted to context.

At the same time, this circle deliberately sets boundaries. RAIDT does not claim to solve every problem in responsible AI. It does not remove the need for model evaluation, alignment work, RLHF-related safeguards, PEFT or LoRA governance, retrieval quality assessment, or broader organisational ethics. It does not make opaque foundation models fully interpretable. It does not guarantee that scoring eliminates human bias. It does, however, provide a disciplined way of documenting, reviewing, and governing actual uses of generative AI in organisational work. That is a narrower but stronger claim.

For the overall project, Circle 3 performs a supervisory and architectural function. It allows the thesis to show how Paper 08 can establish foundations and methodological pathways, how Paper 09 can test RAIDT empirically, and how Paper 10 can explore policy pathways and standards alignment. It also gives a clear map for workshops and supervision meetings: the core question is not whether RAIDT should explain everything, but whether it offers a credible, evidence-based governance method for real GenAI runs. By making theory, adoption, policy, evidence, and limits explicit, this circle helps the project remain coherent, rigorous, and communicable.

Q1. What is meant by the academic, adoption, and boundary layer in RAIDT?

Answer:
It is the part of the RAIDT architecture that explains how the framework should be positioned in scholarship, how it can be implemented in organisations, and where its claims stop. It translates the core run-level idea into a defensible research programme and a usable governance approach.

Practical example:
A supervisor asks whether RAIDT is a theory, a method, or a tool. This circle shows that it is a governance framework with theoretical foundations, operational routines, and evaluative outputs.

Link to RAIDT:
It connects the run, evidence pack, and five-pillar score to theory building, implementation design, and boundary-setting.

Q2. Why does RAIDT need this circle rather than only a core conceptual model?

Answer:
A core model explains the internal logic of RAIDT, but supervisors and adopters also need to know how it will be validated, where it fits in Information Systems, and how it relates to policy and practice. Without this circle, RAIDT risks looking conceptually neat but operationally incomplete.

Practical example:
An examiner may accept that the run is a sensible unit of governance but still ask how an organisation would actually collect evidence or interpret a low Auditability score.

Link to RAIDT:
This circle explains how scores trigger governance interventions and how evidence capture becomes part of organisational routine.

Q3. What problem does this circle solve for organisational adoption?

Answer:
It solves the translation problem between abstract responsible AI principles and day-to-day practice. Organisations often support accountability in principle but lack a repeatable unit of review and evidence capture.

Practical example:
A legal operations team uses GenAI for clause comparison. Without a structured run record, it cannot show which prompt was used, whether retrieved precedents were checked, or how the output was approved.

Link to RAIDT:
RAIDT turns that interaction into a documented run and a reviewable evidence pack linked to the five pillars.

Q4. How does this circle connect to uncertainty?

Answer:
Generative AI produces uncertainty about output quality, context dependence, and the adequacy of safeguards. This circle shows that RAIDT addresses managerial uncertainty by making each use of the system inspectable, comparable, and reviewable.

Practical example:
A public-sector service team is unsure whether a chatbot summary can be sent directly to staff. RAIDT requires the run details and checks to be captured before trust is assumed.

Link to RAIDT:
The evidence pack reduces uncertainty by recording what happened in a run; the score profile highlights where governance confidence is weak.

Q5. How does this circle relate to policy and standards alignment?

Answer:
It shows that RAIDT can support policy-facing governance without claiming to be a compliance regime in itself. The framework offers evidence and scoring structures that may help organisations demonstrate oversight, traceability, and risk management.

Practical example:
A procurement team wants to show that a GenAI workflow aligns with internal assurance expectations and external standards language.

Link to RAIDT:
Run-level evidence can support mappings to audit trails, accountability duties, and management system controls relevant to standards and policy frameworks.

Q6. What kind of empirical evidence would strengthen this circle?

Answer:
Evidence would include comparative case studies, expert reviews, scoring consistency analysis, sector pilots, and assessments of whether RAIDT changes governance quality or decision discipline. The aim is to test usefulness, not merely conceptual elegance.

Practical example:
Two teams complete similar drafting tasks, one with ad hoc prompting and one with RAIDT evidence capture. Researchers compare documentation quality, error detection, and escalation clarity.

Link to RAIDT:
This directly tests whether the run-level evidence pack and pillar scoring improve observable governance outcomes.

Q7. Why are sector playbooks important if RAIDT is meant to be general?

Answer:
Because the run-level model can remain stable while risk tolerance, review expectations, and evidence requirements vary across sectors. Generality without contextual adaptation would make the framework too shallow.

Practical example:
A university guidance drafting run and a healthcare administrative summarisation run may use similar prompt structures, but the level of review and documentation required will differ.

Link to RAIDT:
Sector playbooks adapt evidence fields, scoring thresholds, and governance interventions while preserving the common RAIDT architecture.

Q8. Does this circle claim that RAIDT replaces technical controls such as RAG tuning, RLHF, or model evaluation?

Answer:
No. RAIDT governs organisational use at run level; it does not replace upstream model development controls or technical assurance work. It should be seen as complementary to prompt engineering, retrieval governance, alignment controls, and evaluation pipelines.

Practical example:
A team improves a system through RAG and prompt optimisation, but still needs to record which retrieval set and prompt variant were used for a high-stakes run.

Link to RAIDT:
The evidence pack captures those configurations, allowing governance to observe how technical controls were actually instantiated in practice.

Q9. Why is it important to state the boundaries of RAIDT clearly?

Answer:
Boundary statements make the thesis more credible. They prevent the framework from being judged against claims it never made and help distinguish what RAIDT can support from what requires different methods or theories.

Practical example:
If a reviewer asks whether RAIDT solves structural bias in training data, the correct answer is that it can surface run-level evidence and review requirements, but it cannot alone remove upstream dataset harms.

Link to RAIDT:
Boundary clarity protects the meaning of the five pillars and keeps governance interventions proportionate to the run-level evidence available.

Q10. How does this circle help supervisors understand the overall programme?

Answer:
It provides a navigational map. Supervisors can see which parts of the thesis establish foundations, which test the framework, which discuss policy implications, and which define limits.

Practical example:
In a supervision meeting, the candidate can explain that one paper develops the logic, another tests adoption and scoring, and another examines policy pathways.

Link to RAIDT:
This keeps the run-level concept central while showing how the evidence pack, scoring, and interventions are distributed across the wider research programme.

• University administration drafting: A staff member uses GenAI to draft student-facing guidance. RAIDT would capture the prompt, institutional policy context, model used, review by a human administrator, and any corrections before publication. This makes the run auditable and allows Responsibility and Traceability to be scored.
• Legal operations clause comparison: A legal team uses a model with retrieval to compare contract clauses against approved templates. RAIDT would record the retrieved sources, prompt version, output comparison table, reviewer comments, and approval decision. This is particularly relevant to Auditability, Dependability, and contestability.
• Healthcare administrative summarisation: A non-diagnostic team summarises referral letters or policy updates for internal workflow use. RAIDT would document context restrictions, human review checkpoints, and escalation rules when uncertainty remains high. This helps prevent informal use from being mistaken for safe routine automation.
• Public-sector triage support: A service team drafts response options to citizen queries. RAIDT would require a run record showing source material, prompt instructions, generated response, and reviewer sign-off, which supports traceability and later challenge if a decision path is disputed.

• Run identifier, task purpose, organisational context, and user role.
• Prompt or instruction set, including prompt template version where relevant.
• Model, tool, orchestration, and configuration details.
• Whether RAG, retrieval, external tools, LoRA, PEFT, or alignment constraints were active.
• Source materials retrieved or referenced during the run.
• Output produced, including version or revision history if edited.
• Human review steps, reviewer identity or role, and approval or rejection outcome.
• Detected risks, uncertainty flags, exceptions, and escalation decisions.
• RAIDT pillar scores with rationale for Responsibility, Auditability, Interpretability, Dependability, and Traceability.
• Governance intervention taken, such as additional review, red-team check, policy escalation, or workflow redesign.
• Domain or sector classification so evidence can feed sector playbooks and comparative validation.

• Paper 08: foundations and methodological pathways ? This circle clarifies the theoretical positioning of RAIDT as a design-oriented, run-level governance framework and explains why the run is a workable unit for evidence-based study.
• Paper 09: empirical validation ? It identifies what must be tested empirically: usability, scoring consistency, evidence capture quality, sector adaptability, and whether RAIDT improves governance discipline in real organisational settings.
• Paper 10: policy pathways ? It explains how RAIDT can inform policy interpretation and standards alignment without collapsing into a compliance checklist.
• Sector playbooks ? It shows why domains require calibrated evidence expectations, thresholds, and governance responses while preserving the shared RAIDT logic.
• RAIDT scoring ? It situates the five-pillar score as a practical evaluative output that supports comparison, diagnosis, and intervention rather than as a purely abstract metric.
• RAIDT evidence pack ? It frames the evidence pack as the core operational artefact through which run-level governance becomes inspectable, discussable, and reviewable.
• RAIDT governance interventions ? It links scoring and evidence to concrete actions such as review escalation, prompt redesign, retrieval controls, role clarification, or policy escalation.

• Responsible AI governance literature in Information Systems and organisational studies.
• Design science research and socio-technical artefact evaluation.
• Managerial uncertainty and decision-making under technological ambiguity.
• Generative AI governance, prompt engineering, and retrieval-augmented generation oversight.
• Assurance, auditability, accountability, and contestability in AI systems.
• Standards and policy sources relevant to AI governance, including EU AI Act discussion, ISO/IEC 42001, and the NIST AI RMF.
• Empirical methods for framework validation, expert elicitation, and case-based comparative analysis.
• Sector-specific governance guidance for higher education, healthcare administration, legal operations, and public-sector service delivery.

• RAIDT does not claim that run-level evidence alone guarantees safe or ethical AI use.
• RAIDT does not replace upstream model evaluation, alignment work, or technical controls such as RLHF, RAG evaluation, guardrails, or fine-tuning governance.
• RAIDT does not make black-box models fully interpretable; it improves interpretability of use context and decision trace, not model internals in full.
• RAIDT scoring is a governance aid, not an objective truth machine; scores depend on context, evidence quality, and reviewer judgement.
• RAIDT is designed for organisational work settings and may require adaptation before use in highly autonomous or safety-critical environments.
• RAIDT supports accountability and contestability, but it cannot by itself resolve wider institutional politics, incentives, or power asymmetries.

Circle 3 is where RAIDT becomes explainable as a full research programme rather than only a core concept. The central claim of RAIDT is that the run is the right unit of governance for organisational generative AI use. A run is a specific use of a model for a task in a context, with its prompt, configuration, retrieved material, output, and checks. From that, RAIDT produces two outputs: an evidence pack and a five-pillar score profile. What Circle 3 adds is the outer logic. It shows how RAIDT is positioned academically, how organisations could adopt it in practice, how it aligns with policy and standards discussions, how it can be tested empirically, and where its boundaries sit. This matters for supervision because it prevents the thesis from appearing either too abstract or too operationally narrow. It also helps separate the project into clear strands: foundations in Paper 08, empirical validation in Paper 09, and policy pathways in Paper 10. In short, this circle shows that RAIDT is not just an idea about responsible AI; it is a bounded, testable, and implementable governance framework.

1. Why Circle 3 exists.
2. What problem it solves.
3. How adoption works at run level.
4. How policy and standards alignment should be understood.
5. How the empirical programme is organised.
6. Why boundaries matter.
7. How this circle supports the three-paper RAIDT pathway.
8. Why supervisors should care.