Boundaries, Limitations and Future Questions

Defines the outer limits of RAIDT as a run-level governance framework, clarifies what its evidence and scores can legitimately support, and prevents conceptual or policy overclaiming when RAIDT is used in research, supervision, implementation, and organisational decision-making.

This star plays a boundary-setting role across the whole RAIDT programme. It sits at the intersection of foundations, governance design, empirical validation, and policy translation. In practical terms, it explains where RAIDT is strong, where it is necessarily partial, and which future research questions remain open. That makes it especially important for Paper 08, where methodological and conceptual claims must be carefully scoped; for Paper 09, where empirical testing must distinguish measurable governance readiness from broader claims about system quality; and for Paper 10, where policy relevance depends on showing both alignment potential and remaining gaps.

S11 also helps supervisors and workshop participants understand that RAIDT is not simply another general Responsible AI checklist. It is a run-level evidence framework for governing configured uses of generative AI in organisational work. Its contribution lies in making particular AI uses inspectable, documentable, and governable at the level of the run. This note therefore protects the intellectual coherence of the project by showing what RAIDT can evaluate, what it can only signal indirectly, and what lies outside its immediate scope.

• What does it mean to define boundaries and limitations for RAIDT?
• Why does RAIDT need an explicit boundary note rather than relying on implicit assumptions?
• What problem does this star solve in relation to overclaiming, policy translation, and academic scrutiny?
• What can RAIDT assess reliably at run level, and what can it not determine on its own?
• What is the difference between output correctness and governance readiness?
• How should proportionality shape evidence capture, controls, and scoring?
• What evidence is needed to justify claims about responsibility, auditability, interpretability, dependability, and traceability?
• How does this star connect to the run-level evidence pack?
• How does it connect to the five-pillar RAIDT score profile?
• How does it help supervisors understand the methodological contribution of the project?
• What future questions arise for multimodal, agentic, and evolving GenAI systems?
• What kinds of empirical validation are still required before RAIDT can be generalised across sectors?

• S11.01 - Boundary conditions
• S11.02 - Limitations
• S11.03 - Correctness vs governance readiness
• S11.04 - Proportionality
• S11.05 - Privacy and data protection
• S11.06 - Metric overreach
• S11.07 - Evidence capture feasibility
• S11.08 - Component drift
• S11.09 - Future extension: multimodal AI
• S11.10 - Future extension: agentic AI

• 10-20 min - Where should RAIDT stop making claims: at run documentation, governance readiness, organisational assurance, or broader claims about AI quality and safety?
• 20-40 min - How should the project distinguish evidence of process quality from evidence of output truth, legal compliance, and social acceptability?
• 40-60 min - Which future extensions are methodologically defensible next steps for RAIDT: multimodal runs, agentic runs, sector-specific playbooks, or policy alignment pathways?

Any governance framework becomes weaker, not stronger, if it claims to solve more than it can actually demonstrate. This is especially true in the governance of generative AI, where organisations often face pressure to move quickly from experimentation to operational use while regulators, auditors, managers, and staff all ask slightly different questions. Some want to know whether a system is safe. Others want to know whether it is lawful, fair, accurate, explainable, or useful. RAIDT does not answer all of these questions in a total sense. Its value lies in answering a narrower but highly practical question: how can a specific use of a generative AI system in organisational work be governed through evidence captured at the level of the run?

In RAIDT, the run is the unit of governance. 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 prompt or instruction, model and tool configuration, retrieved context where used, output, and human or automated checks. This framing matters because many governance failures are not failures of abstract model design alone. They arise from how a system is configured, what context it receives, which tools it can call, how outputs are reviewed, and whether evidence exists to reconstruct what happened. RAIDT addresses that practical governance gap through two outputs: a run-level evidence pack and a five-pillar RAIDT score profile covering Responsibility, Auditability, Interpretability, Dependability, and Traceability.

The purpose of this star is to clarify the boundaries of that contribution. RAIDT is not a universal theory of AI safety, not a proof of correctness, and not a substitute for domain regulation, legal advice, or broader organisational governance. It is a framework for producing structured evidence about a run and using that evidence to assess governance readiness. That distinction between correctness and governance readiness is central. A model may generate a factually correct answer in one instance while still being poorly governed because prompts are not recorded, retrieval sources are unstable, reviewer responsibilities are unclear, or audit trails are missing. Equally, a run may be well documented and well controlled yet still produce an incorrect answer. RAIDT helps organisations see and manage these conditions, but it does not collapse them into one metric.

This boundary is methodologically important for the PhD project. In academic terms, RAIDT contributes to Information Systems governance by proposing a governance object that is concrete enough to inspect yet flexible enough to travel across use cases. It also contributes to Responsible AI debates by shifting attention from broad principles to operationally auditable evidence. However, this does not mean that run-level evidence fully captures ethical quality, legal sufficiency, or social legitimacy. A run can be traceable without being fair. It can be auditable without being optimal. It can be interpretable in workflow terms without revealing the full internal logic of a foundation model. S11 exists to state those limits explicitly.

The star also addresses proportionality. Not every run requires the same intensity of evidence capture or the same governance intervention. A low-risk drafting assistant for internal brainstorming should not necessarily be governed in the same way as a clinical triage assistant, legal advice generator, or public-sector benefits support tool. RAIDT therefore needs a proportionality logic: governance should match task criticality, uncertainty, sensitivity of data, degree of automation, and consequences of error. This makes the evidence pack more practical, because the framework becomes adaptable rather than uniformly burdensome. At the same time, proportionality creates its own challenge. If organisations reduce evidence capture too far in the name of efficiency, the score profile may become weak precisely where assurance is most needed.

Privacy and data protection introduce another important limitation. RAIDT can specify what evidence would ideally be captured, but not all evidence should always be stored in full. Prompts may contain personal data, retrieved documents may be confidential, and tool traces may expose sensitive workflow information. The framework therefore has to distinguish between evidence existence, evidence accessibility, and evidence retention. In some settings, strong traceability may require cryptographic hashes, metadata, controlled access logs, or redacted artefacts rather than unrestricted raw storage. This means the evidence pack is not a simple archive of everything. It is a governed record designed to support accountability without creating avoidable privacy or security risks.

Metric overreach is a further concern. RAIDT produces scores across five pillars, but those scores should not be misread as direct measures of truth, quality, morality, or legal compliance. They are structured indicators of governance conditions. A high Auditability score suggests that a run can be reconstructed and reviewed. A high Dependability score suggests that controls, checks, and workflow stability are stronger. Yet even a strong score profile does not eliminate uncertainty. Generative AI remains probabilistic, context-sensitive, and dependent on changing components such as models, retrieval pipelines, prompt templates, moderation layers, and human review practices. S11 therefore insists that scores are aids to governance judgement, not replacements for it.

This becomes even more important when systems drift. Component drift may arise because a model provider updates a model silently, retrieval corpora change, prompts are revised, tools are added, or reviewers adopt different checking habits. Since RAIDT governs runs rather than merely static systems, it is well placed to detect some forms of drift through evidence capture and comparison over time. But it cannot guarantee that all relevant changes are visible, especially in opaque vendor environments. This is one reason why empirical validation in Paper 09 matters. The project must test whether the evidence pack and score profile remain reliable, usable, and discriminating across real organisational cases.

S11 also frames future questions. Multimodal AI introduces inputs and outputs that are harder to interpret and archive, such as images, audio, video, and mixed-media prompts. Agentic AI creates longer action chains, delegated decisions, dynamic tool use, and more complex accountability boundaries. These developments do not invalidate RAIDT, but they do place pressure on its current design. The run remains a useful governance unit, yet the evidence model may need extension to capture chaining, delegation, autonomy thresholds, and intervention points. Likewise, sector playbooks may be required because acceptable evidence and governance thresholds differ across education, healthcare, finance, government, and professional services.

Overall, this star supports the RAIDT project by making its claims more precise and defensible. It shows that RAIDT should be understood as a practical governance framework for documenting and assessing the quality of control around particular GenAI uses. That is a substantial contribution, but not an unlimited one. By naming its boundaries, RAIDT becomes more credible for supervisors, more useful for organisations, and more adaptable for future research, policy alignment, and sector-specific implementation.

Q1. What is the main purpose of boundaries and limitations in RAIDT?

Answer:
The main purpose is to define the legitimate scope of RAIDT's claims. RAIDT is designed to assess the governance readiness of a specific GenAI run through evidence and scoring. It is not designed to prove that every output is correct, lawful, or ethically ideal. By stating this clearly, the framework avoids conceptual inflation and becomes more methodologically robust.

Practical example:
An organisation uses a large language model to draft internal policy summaries. RAIDT can capture the prompt, model version, retrieved sources, reviewer checks, and approval steps. It can show whether the run was governable and reviewable, but it cannot by itself prove that every policy summary is legally flawless.

Link to RAIDT:
This distinction protects the integrity of the run-level evidence pack and ensures that pillar scores are interpreted as governance indicators rather than absolute truth claims.

Q2. Why does RAIDT need an explicit boundary note?

Answer:
Responsible AI frameworks are often criticised for vagueness or overreach. An explicit boundary note helps RAIDT explain where it fits in relation to Responsible AI, AI risk management, and Information Systems governance. It makes the framework easier to defend in supervision, publication, and implementation settings.

Practical example:
During a workshop, a supervisor asks whether RAIDT can determine fairness across all user groups. The boundary note allows a clear answer: RAIDT can require evidence relevant to fairness assessment in a run, but broader fairness analysis may require additional datasets, impact assessment methods, and domain expertise.

Link to RAIDT:
This note supports the interpretive use of the evidence pack and prevents the five-pillar profile being oversold.

Q3. What problem does this star solve?

Answer:
It solves the problem of overclaiming. Without explicit boundaries, users may assume that a structured score profile is equivalent to proof of safety, correctness, or compliance. S11 prevents that misunderstanding by clarifying what RAIDT can evidence directly and what must remain a matter for further judgement or supplementary governance.

Practical example:
A procurement team sees a high RAIDT score and wants to treat it as automatic approval for enterprise-wide deployment. S11 clarifies that the score should instead inform a decision, alongside legal review, risk assessment, and sector-specific controls.

Link to RAIDT:
It safeguards the governance function of scoring and anchors governance interventions in evidence rather than misplaced certainty.

Q4. What is the difference between correctness and governance readiness?

Answer:
Correctness concerns whether an output is substantively right for the task. Governance readiness concerns whether the run was configured, documented, checked, and controlled in a way that supports accountability and appropriate use. These dimensions may overlap, but they are not identical.

Practical example:
A chatbot returns the right answer to a customer question by chance, but no reviewer checks were recorded and the source trace is missing. The answer may be correct, yet governance readiness is weak.

Link to RAIDT:
RAIDT captures this distinction through evidence fields and pillar scoring, especially Auditability, Dependability, and Traceability.

Q5. How does proportionality affect RAIDT?

Answer:
Proportionality determines how much evidence, review, and control are appropriate for a run. Higher-stakes tasks require stronger evidence capture, clearer accountability, and more robust checks. Lower-stakes tasks may justify lighter controls to avoid unnecessary governance burden.

Practical example:
An internal brainstorming prompt may only require prompt logging, model identification, and basic user acknowledgement. A healthcare discharge summary assistant may require source capture, reviewer sign-off, escalation rules, and restricted deployment conditions.

Link to RAIDT:
Proportionality shapes the design of the evidence pack, the interpretation of score thresholds, and the selection of governance interventions.

Q6. Why is privacy a limitation for run-level evidence capture?

Answer:
Because the evidence that improves accountability may also increase exposure of sensitive data. Effective governance therefore requires selective capture, redaction, access controls, and retention rules rather than indiscriminate logging.

Practical example:
A human resources assistant uses GenAI to draft employee communications. Full prompt capture might reveal personal or contractual information. The organisation may need to store redacted prompts, metadata, and access logs instead of raw text.

Link to RAIDT:
This shapes how the evidence pack is designed and ensures Traceability and Auditability are balanced against privacy and data protection duties.

Q7. What is metric overreach in the context of RAIDT?

Answer:
Metric overreach occurs when RAIDT scores are treated as if they measure more than they actually do. The five pillars indicate the quality of governance conditions around a run, not the total value or legitimacy of the AI system.

Practical example:
A team reports that a tool is 'safe' because it achieved a strong RAIDT profile. In reality, the profile shows that the use was well documented and controlled; safety still depends on the task, users, domain, and broader risk context.

Link to RAIDT:
S11 protects the meaning of RAIDT scoring and supports responsible communication of evidence-pack results.

Q8. How does component drift challenge RAIDT?

Answer:
Component drift means that a run environment can change over time even if the use case appears stable. Models, retrieval sources, tool permissions, moderation settings, and human review practices may all shift. This makes governance evidence time-sensitive.

Practical example:
A vendor updates the underlying model behind an API. Outputs change subtly, even though the organisation did not revise its prompt template. Prior evidence may no longer represent current behaviour.

Link to RAIDT:
Because RAIDT treats the run as the unit of governance, it can record time-stamped configurations and make drift more visible, but it cannot eliminate vendor opacity.

Q9. Why are multimodal and agentic systems future questions rather than simple extensions?

Answer:
They introduce new governance complexities. Multimodal systems create evidence types that are harder to store, inspect, and interpret. Agentic systems create longer chains of action, more dynamic decision points, and blurred responsibility boundaries. These features require extension of the current evidence model.

Practical example:
An agentic research assistant retrieves sources, writes a draft, queries a database, and sends a report for approval. Governance now concerns not only one prompt-output pair but a sequence of actions with checkpoints and intervention points.

Link to RAIDT:
These questions point to future development of the evidence pack, scoring logic, and governance interventions for more complex run structures.

Q10. What evidence would help justify claims made using RAIDT?

Answer:
Useful evidence includes run identifiers, timestamps, task purpose, user role, prompt text or prompt hash, model and tool configuration, retrieved context metadata, output artefacts, review actions, exception logs, and approval status. Evidence should be sufficient to reconstruct key governance decisions without breaching privacy unnecessarily.

Practical example:
For a procurement drafting run, the evidence pack might contain the template used, the policy corpus version, the model provider, review comments, and whether the output was accepted, revised, or rejected.

Link to RAIDT:
This is the core of the RAIDT evidence pack and underpins all five pillars.

Q11. How does this star help supervisors understand the project?

Answer:
It gives a concise answer to a common supervisory concern: what exactly is the contribution, and what is not being claimed? By making the limits explicit, the project becomes easier to position against Responsible AI, governance theory, and empirical validation literature.

Practical example:
In a supervision meeting, S11 can be used to explain that RAIDT is not claiming to solve alignment in the broad technical sense. It is claiming to make organisational GenAI uses more governable through run-level evidence.

Link to RAIDT:
This strengthens the conceptual framing for Paper 08, the testing logic for Paper 09, and the policy translation in Paper 10.

Q12. Why do future research questions strengthen rather than weaken RAIDT?

Answer:
A framework is stronger when it identifies the next questions needed for extension and validation. Future questions show that RAIDT is designed as a research programme, not a finished universal solution. This is appropriate for a PhD project that aims to build a defensible foundation and a pathway for empirical and policy development.

Practical example:
If early case studies show that evidence capture is feasible in text-based advisory tasks but difficult in multimodal settings, that result does not invalidate RAIDT. It identifies a clear research frontier.

Link to RAIDT:
This links directly to empirical validation, sector playbooks, policy alignment, and future refinements to scoring and evidence design.

• A university uses GenAI to help staff draft course guidance. RAIDT can assess whether prompts, source documents, reviewer checks, and approvals are captured, but it cannot guarantee pedagogical quality or legal compliance on its own.
• A hospital pilots a discharge-summary assistant. RAIDT can support stronger run-level evidence, escalation rules, and traceable review, while also showing that clinical safety still requires domain governance beyond the framework itself.
• A law firm uses retrieval-augmented generation to draft internal research notes. RAIDT can capture which sources were retrieved and how outputs were reviewed, helping assess auditability and traceability while acknowledging that legal correctness remains a matter for qualified human judgement.
• A local authority tests a citizen-facing benefits assistant. RAIDT can structure evidence and scoring for accountability, but fairness, accessibility, and public-law obligations require additional policy and service-design assessment.
• A company adopts a vendor chatbot whose model updates frequently. RAIDT can expose the need for version logging, change alerts, and periodic re-scoring, but it may still be constrained by the opacity of the vendor platform.

Where relevant, this star implies the need to capture or reference:

• Unique run identifier and timestamp
• Task description, organisational context, and intended use
• User role, reviewer role, and accountability owner
• Prompt text, prompt template version, or prompt hash where full storage is inappropriate
• Model provider, model version, temperature, tool settings, and moderation or alignment controls
• Retrieval status, corpus version, source identifiers, and RAG configuration metadata
• Output artefact or secure reference to the output
• Human review actions, automated checks, and exception handling
• Decision outcome: accepted, revised, rejected, escalated, or deferred
• Retention, redaction, privacy, and access-control rules
• Re-run or drift indicators for changing components over time
• Justification for proportional governance intensity

This note connects to the wider RAIDT project in several explicit ways.

• Paper 08: foundations and methodological pathways - S11 sharpens the conceptual boundary of RAIDT by distinguishing run-level governance from broader claims about AI truth, ethics, or safety. It helps define the framework's unit of analysis, methodological contribution, and limits.
• Paper 09: empirical validation - S11 identifies what needs testing: whether evidence capture is feasible, whether pillar scores are reliable and meaningful, whether proportional governance can be operationalised, and how drift affects repeated assessment.
• Paper 10: policy pathways - S11 shows how RAIDT may align with policy instruments without claiming to replace them. It supports translation into governance guidance relevant to the EU AI Act, ISO/IEC 42001, and NIST AI RMF while preserving scope discipline.
• Sector playbooks - S11 justifies why sector-specific profiles are needed. Different domains require different evidence thresholds, reviewer roles, and escalation practices.
• RAIDT scoring - The star explains that scores are governance signals, not universal judgments of quality, safety, or legality.
• RAIDT evidence pack - The star clarifies why evidence should be sufficient, proportionate, privacy-aware, and time-sensitive.
• RAIDT governance interventions - S11 helps determine when to strengthen controls, add review stages, limit use, escalate decisions, or defer deployment because governance evidence is insufficient.

• Responsible AI principle-to-practice literature
• Information Systems governance and accountability literature
• AI uncertainty, socio-technical risk, and managerial uncertainty scholarship
• Auditability and traceability literature for digital systems
• RAG governance and prompt engineering assurance discussions
• RLHF, alignment controls, and model-card or system-card style documentation ideas
• Policy and standards materials linked to the EU AI Act, ISO/IEC 42001, and NIST AI RMF
• Empirical evaluation literature on human-AI oversight, logging, and assurance cases
• Sector-specific governance guidance in healthcare, public services, education, and legal practice

• RAIDT does not claim to prove that a model output is true, fair, safe, or lawful in every case.
• RAIDT does not replace domain expertise, legal advice, risk assessment, or organisational accountability structures.
• RAIDT does not require that all raw evidence be stored without restriction; privacy, confidentiality, and security constraints still apply.
• RAIDT scores should not be treated as complete proxies for compliance, ethical acceptability, or business value.
• RAIDT is strongest for configured runs that can be meaningfully documented; highly opaque vendor environments reduce visibility.
• RAIDT currently fits text-centred and bounded workflow uses more easily than complex multimodal or agentic systems.
• RAIDT can indicate governance readiness and control quality, but broader social impacts may require additional evaluative methods.
• RAIDT does not remove uncertainty; it structures how uncertainty is evidenced and managed.

RAIDT needs a boundary note because the framework becomes more defensible when it is explicit about what it does and does not claim. The core contribution is not that RAIDT proves generative AI outputs are always correct or compliant. Rather, it governs the run as the unit of analysis. That means one configured use of a GenAI system for a particular task, with its prompt, model and tool settings, retrieved context, output, and checks. From that, RAIDT produces an evidence pack and a five-pillar score profile. S11 explains that these outputs indicate governance readiness, not absolute truth or safety. It also shows why proportionality, privacy, metric overreach, and component drift matter. This is important for the PhD because it sharpens the methodological contribution in Paper 08, defines what must be tested in Paper 09, and prevents policy overclaiming in Paper 10. In short, S11 makes RAIDT more credible by specifying the framework's scope, limits, and future research path.