Enter your search text in the box above

Select a result to preview

C0.12 - What_RAIDT_is_not

#raidt/C0

C0.12 — What RAIDT is not

flowchart LR
    A[Common misframings
prompt engineering only
RAG system
auditability only
model card
generic checklist
compliance guarantee] --> B[RAIDT
run-level evidence framework]
    H[Practical contexts and fields
task context, prompt, retrieval, outputs
human review, decision notes, escalation] --> C[[What RAIDT is not
boundary definition for correct scope]]
    B --> C
    C --> D[Evidence pack]
    C --> E[RAIDT score profile]
    D --> F[Reviewer reconstruction
contestability
audit readiness]
    E --> G[Governance readiness
organisational learning
policy alignment]

← Star C0 - RAIDT Core, Definition, Values, Claims and Innovation

Star context: Clarifies the project boundary by defining RAIDT through contrast: a run-level evidence framework for responsible governance of GenAI in organisational work, rather than a narrow technical tool, a generic checklist, or a legal guarantee.

Academic picture
Definition / background

"What RAIDT is not" is a boundary-definition item. It specifies the conceptual limits of the framework so that RAIDT is not confused with adjacent but different approaches to governing or using generative AI. In this sense, the item performs an academic and practical function: it prevents category error. A framework is often understood not only by what it includes, but also by what it explicitly excludes.

In RAIDT, this matters because generative AI governance is crowded with overlapping vocabularies. Prompt engineering concerns how prompts are designed to improve outputs. RAG systems concern architectural methods for connecting models to external information sources. Auditability-only frameworks concentrate mainly on trace and review. Model cards describe models at a general level. Generic checklists provide broad governance prompts. Legal compliance frameworks focus on legal obligations and liability. RAIDT intersects with all of these, but it is reducible to none of them.

RAIDT belongs in this space as a run-level evidence framework. Its unit of governance is the run: one configured use of a GenAI system for a specific task, at a specific time, in a specific organisational context. From that run, RAIDT seeks to assemble an evidence pack and justify a five-pillar score profile across Responsibility, Auditability, Interpretability, Dependability, and Traceability. The negative definition matters because if RAIDT is mistaken for a prompt study, a RAG architecture, or a checklist, its evidential and governance contribution becomes obscured.

This item therefore belongs inside RAIDT Core because it secures the framework's identity. It explains what RAIDT should not be conflated with, why that distinction matters for governance, and how run-level evidence keeps the project anchored in operational accountability rather than abstract description or narrow technical optimisation.

Why this concept matters

This concept matters because new frameworks are often misunderstood through familiar categories. An examiner may assume RAIDT is mainly about prompting. A practitioner may assume it is a compliance checklist. A reviewer may treat it as an audit trail with a new label. Without a clear boundary statement, those interpretations weaken the theoretical positioning of the project and dilute its practical value.

The item also avoids a serious governance risk: false sufficiency. If an organisation believes that prompt tuning, model documentation, or legal sign-off alone is enough, it may miss the need for run-specific evidence about how GenAI was actually used. RAIDT is designed precisely to address that gap. It does not reject adjacent methods; it situates them within a broader governance logic grounded in reconstructable use.

For organisations using GenAI, the value of this clarification is operational. It helps them understand that responsible governance is not achieved by possessing one artefact or one assurance claim. Governance becomes stronger when a real use event can be evidenced, reviewed, challenged, scored, and improved. This is why the boundary statement is not defensive wording. It is part of how RAIDT moves from principles to operational governance.

Key idea: This item matters because RAIDT can only function as a governance framework if it is not mistaken for a narrower technique, document type, or compliance promise.

What this item explains
Practical example / likely audience question

Audience question

Why not focus only on auditability or prompting, since those seem easier to explain and implement than a broader RAIDT framework?

Answer

The concern behind this question is that narrower concepts often appear more manageable. Prompting is tangible, auditability is familiar, and both are valuable. The direct answer, however, is that RAIDT is intended to govern organisational uses of GenAI, not merely improve output quality or retain a record of events. If the framework focused only on prompting, it would neglect issues such as accountability, interpretability of use, process dependability, and end-to-end traceability. If it focused only on auditability, it would narrow governance to retrospective inspection rather than broader operational readiness.

A practical example is a university using GenAI to help staff draft student-support communications. Good prompting may improve tone and relevance, and audit logging may preserve the interaction. Yet governance still requires more: clarity about who approved use, whether the content was checked for appropriateness, whether outputs were dependable across similar cases, and whether the use can be traced to a specific task context and decision pathway. RAIDT addresses those questions together because it works across all five pillars at the level of the run.

RAIDT therefore handles this issue better than a generic AI governance approach because it does not rely on a single artefact or technique as a proxy for responsible practice. It asks whether one real use event can be reconstructed, evaluated, and justified in a way that supports organisational learning and governance readiness.

Practical example in RAIDT terms

Consider a finance team using a GenAI assistant to draft an internal credit-risk briefing for a lending committee. The use case is not unusual: the analyst provides notes, portfolio data, and a drafting prompt, and the system generates a first-pass summary for human review.

The run-level issue arises when a manager assumes that the organisation is already well governed because it has prompt templates, a vendor model card, and a standard compliance checklist. Those resources are useful, but they do not by themselves show what happened in this specific run. The evidence needed includes the task purpose, the prompt and any retrieval context used, the model or tool version, the source materials, the generated text, analyst edits, reviewer comments, approval status, and any escalation if the output contained unsupported claims.

Responsibility is affected because the organisation must identify who relied on the draft and who checked it before committee use. Auditability is affected because reviewers must be able to reconstruct the event. Interpretability is affected because the team needs to understand why the draft took the form it did. Dependability is affected because repeated drafting quality and control performance matter for credit processes. Traceability is affected because the run must be linked to time, actor, artefacts, and downstream decision use. By clarifying what RAIDT is not, the team avoids mistaking prompt quality or checklist completion for full governance readiness.

Detailed link to RAIDT

What RAIDT is not links to RAIDT in four ways.

First, it protects the RAIDT core idea by ensuring the framework is understood as governance through evidence from actual organisational use rather than as a narrow technical method.

Second, it points back to the run and run-level evidence by showing that RAIDT's distinctiveness comes from what can be shown about one concrete GenAI event, not from generic claims alone.

Third, it clarifies why the evidence pack and RAIDT score profile are necessary. If RAIDT were only a checklist or a compliance label, these structured outputs would be unnecessary. Their presence shows that RAIDT is operational and evidential.

Fourth, it strengthens reviewability, contestability, audit readiness, and organisational learning because a correctly scoped framework supports scrutiny of real practice rather than confidence based on slogans or category confusion.

What RAIDT is not -> Run-level evidence -> Evidence pack -> RAIDT score profile -> Governance readiness

Link to the five RAIDT pillars

Responsibility

This item supports Responsibility by clarifying that responsible governance cannot be delegated to prompts, vendors, or generic compliance statements alone. Human and organisational accountability still need to be evidenced at run level.

Example evidence / implication:

Auditability

This item strongly affects Auditability because it rejects the idea that a thin audit trail or broad assurance document is enough. RAIDT requires enough evidence to reconstruct and assess one actual use event.

Example evidence / implication:

Interpretability

This item supports Interpretability by making clear that RAIDT is not merely about whether a model is described, but whether a particular use can be understood in context.

Example evidence / implication:

Dependability

This item supports Dependability because it prevents governance from being reduced to one-off documentation. Reliable practice requires evidence that controls work repeatedly across actual runs.

Example evidence / implication:

Traceability

This item supports Traceability by insisting that RAIDT governance must connect the run to actors, tools, artefacts, timing, and downstream use, rather than stopping at generic descriptions.

Example evidence / implication:

This item affects all five pillars, but it is especially important for Auditability and Traceability because misunderstanding RAIDT as a generic governance artefact immediately weakens the ability to reconstruct practice.

Why this item is more than a generic concept

In general AI governance, a boundary statement may simply clarify scope at the level of a framework description. In RAIDT, "what RAIDT is not" has a more operational role. It determines what kinds of evidence must exist if the framework is to function as claimed.

The RAIDT meaning is therefore more practical than a generic definitional disclaimer. It says that RAIDT should not be confused with neighbouring concepts precisely because RAIDT is tied to run-level evidence, evidence packs, five-pillar scoring, and governance readiness. The distinction is not rhetorical. It affects how the framework is implemented, evaluated, defended in scholarship, and used in organisations.

Common misunderstanding

Misunderstanding

If RAIDT is not a compliance guarantee, then it does not really help with compliance.

Correction

RAIDT does not guarantee legal compliance because compliance depends on legal interpretation, sector rules, jurisdiction, organisational conduct, and facts beyond the framework itself. However, RAIDT can materially improve compliance-relevant governance by making GenAI use more reviewable, traceable, and evidentially defensible. For example, a public-sector team may still need legal advice about data protection or administrative law, but RAIDT can provide the run-level record showing what data were used, what output was produced, who reviewed it, and what control steps were followed. That does not replace legal judgement; it strengthens the evidential basis on which legal and governance judgement can be made.

Boundary and limitation

This item does not claim that RAIDT replaces prompt engineering, RAG design, model documentation, legal review, procurement checks, sector regulation, security assurance, or organisational policy. Nor does it claim that RAIDT alone proves that a system is lawful, fair, safe, or effective in every context. RAIDT is a governance framework with a particular evidential unit and output structure.

The limitation is that boundary definition on its own does not deliver governance performance. An organisation may describe RAIDT correctly and still implement it poorly. Equally, some adjacent tools may do important work that RAIDT depends upon without being part of RAIDT itself. RAIDT handles this limitation by positioning itself as a coordinating evidential framework: it incorporates relevant outputs from neighbouring practices where useful, but it does not collapse into them.

Implementation levels

Manual implementation

A researcher or small team can apply this item manually by including an explicit scope statement in notes, templates, workshops, and supervision materials. Each RAIDT assessment can require a short check that the exercise is not being treated merely as prompt optimisation, a vendor description, or a compliance tick-box.

Semi-automated implementation

Semi-automated implementation can use structured templates, form fields, or review checklists that ask assessors to classify the artefacts present in a run and identify what remains missing for full RAIDT treatment. For example, a template may distinguish between prompt data, model documentation, policy controls, and run-level evidence.

Fully automated implementation

At scale, a governance platform, wrapper, or orchestration layer can enforce this boundary by separating architectural metadata, prompt artefacts, legal flags, and run-level evidence into distinct but linked records. Dashboards can then show that RAIDT assessments are based on reconstructable runs and five-pillar scoring rather than on generic documentation alone.

Practical use in the RAIDT project

Within the RAIDT project, this item is especially useful for Paper 08 Foundations because it sharpens theoretical positioning. It helps explain that RAIDT is not just another vocabulary for prompt engineering, documentation, or compliance, but a distinct governance framework centred on the run as the unit of governance.

For Paper 09 Empirical Validation, the item helps define what counts as a valid test of RAIDT. If an evaluation examines only prompts, only logs, or only policy artefacts, it is not yet testing the full framework. For Paper 10 Policy Pathways, the item is important because policy audiences often search for checklists or compliance guarantees; this note clarifies that RAIDT instead offers evidence structures that can support policy implementation and accountability.

The item also matters for sector playbooks, evidence-pack design, scoring rubrics, influence methods, and governance interventions. In supervision meetings and viva defence, it helps answer a likely challenge: whether RAIDT is genuinely novel or merely a relabelling of familiar AI governance tools. The answer is that RAIDT draws on adjacent practices but is defined by its run-level evidential architecture and five-pillar governance logic.

Key audience questions to prepare for

Q1. If RAIDT is not a generic checklist, why does it still use structured questions and scoring?

Because structure alone does not make something a checklist in the reductive sense. In RAIDT, questions and scoring are tied to evidence from one actual run, so they function as part of an evidential assessment rather than a purely declarative tick-box exercise.

Q2. Does saying "RAIDT is not prompt engineering" understate the importance of prompts?

No. Prompts remain important as part of many runs, but they are only one component of governance. RAIDT includes prompt-related evidence where relevant without allowing prompting to define the whole framework.

Q3. Why distinguish RAIDT from model cards or system documentation?

Because model cards and similar artefacts describe models in general terms, whereas RAIDT evaluates situated use in organisational context. Both can be useful, but they answer different governance questions.

It should be presented as a governance-readiness and evidence framework that strengthens reviewability, contestability, and audit preparedness. It supports compliance work, but it does not substitute for legal judgement or regulatory interpretation.

Q5. What is the main danger if this boundary is not made explicit?

The main danger is conceptual collapse. RAIDT may be misread as a narrow technique or a generic assurance artefact, which weakens both its academic contribution and its practical implementation.

Suggested citation concepts to support this item
Short explanation for presentation

This item explains RAIDT by defining its boundaries. RAIDT is not a prompt-engineering study, not a RAG system, not an auditability-only framework, not a model card, not a generic checklist, and not a guarantee of legal compliance. Those are all relevant neighbouring ideas, but none captures RAIDT's core contribution. RAIDT is a run-level evidence framework for responsible governance of generative AI in organisational work. Its distinctiveness is that it treats the run as the unit of governance, builds an evidence pack from that run, and uses the evidence to justify a five-pillar score profile across Responsibility, Auditability, Interpretability, Dependability, and Traceability. Defining what RAIDT is not therefore protects the framework from being reduced to narrower tools and makes its academic and practical contribution easier to defend.

One-line takeaway

What RAIDT is not is the boundary definition that keeps RAIDT identifiable as a run-level evidence framework rather than a narrower technique, artefact, or compliance claim.

Related items in RAIDT core, definition, values, claims and innovation
Anchored questions
Powered by Forestry.md