S2.03 - Control

S2.03 ? Control

flowchart LR
    A1[Policy without operational constraint]
    A2[Undocumented prompt variation]
    A3[Untracked tool and model settings]
    A4[Weak retrieval boundaries]
    A5[Inconsistent reviewer intervention]

    B[RAIDT - run-level evidence framework]
    C[[Control - bounded, approved, and reviewable run conditions]]
    D[Governance move - evidence over assertion, reviewability, contestability, audit readiness]

    E1[Evidence pack]
    E2[RAIDT score profile]
    E3[Reviewer reconstruction]
    E4[Organisational learning]
    E5[Policy alignment]

    F1[Healthcare discharge drafting]
    F2[Finance reporting support]
    F3[Education feedback generation]
    F4[Prompt registry]
    F5[Configuration log]
    F6[Retrieval whitelist]
    F7[Reviewer checkpoint]

    A1 --> B
    A2 --> B
    A3 --> B
    A4 --> B
    A5 --> B

    B --> C
    C --> D
    C --> E1
    C --> E2
    C --> E3
    C --> E4
    C --> E5

    F1 --> C
    F2 --> C
    F3 --> C
    F4 --> C
    F5 --> C
    F6 --> C
    F7 --> C

? Star S2 - Governance Meaning and Problem Context

Star context: Clarifies governance as oversight, control, accountability, reviewability, and continuous improvement rather than a vague ethics label. Within RAIDT, control makes governance operational by showing how a run is deliberately bounded, configured, and checked.

Academic picture

Definition / background

Control refers to the extent to which a GenAI run is intentionally constrained, directed, and governed through approved prompts, policies, tool settings, retrieval boundaries, model configurations, access conditions, and review rules. In governance terms, it answers a basic question: what prevented this run from becoming an unconstrained, opaque, or improvised interaction?

Conceptually, control sits close to ideas such as oversight, assurance, internal governance, compliance, and quality management, but it is not identical to any of them. Oversight concerns who watches and intervenes. Accountability concerns who is answerable. Reviewability concerns whether a run can be examined. Control is more immediate: it concerns the mechanisms that shape the run before, during, and after execution so that the system behaves within an authorised envelope.

This matters especially in GenAI settings because the same model can produce very different outputs depending on prompt phrasing, tool invocation, retrieval context, temperature or decoding settings, and human intervention. Without explicit control, organisational use easily drifts from approved purpose into local improvisation. A policy may exist, but the run may still be effectively uncontrolled. RAIDT addresses this by treating the run itself as the unit of governance and asking what evidence shows that this specific use was properly bounded.

Within RAIDT, control belongs directly to run-level evidence. It is reflected in the evidence pack through configuration records, prompt registries, policy mappings, approval states, reviewer actions, and logs showing what was enabled or disabled. It also affects the five-pillar score profile because weak control tends to degrade responsibility, auditability, dependability, and traceability simultaneously. Control therefore links governance intent to operational proof.

Why this concept matters

Control matters because organisations often talk about governing AI at the level of principles while actual risk emerges at the level of concrete use. The problem is not only whether a model is generally safe or approved, but whether a particular run was performed under the right conditions for the right task with the right constraints.

This concept avoids a common confusion between having a policy and having a controlled process. A team may have an AI policy, approved tooling, and named owners, yet still allow staff to alter prompts freely, bypass retrieval restrictions, change model settings, or use outputs without required review. In that case, governance exists on paper but not in practice.

If control is missing, several risks appear: outputs become harder to justify, harmful drift becomes easier, audit trails become thinner, reviewers cannot tell whether non-compliance was due to policy failure or execution failure, and continuous improvement becomes guesswork rather than evidence-led learning. For organisations using GenAI in operational settings, this is not a minor issue. It determines whether governance can be defended to supervisors, auditors, regulators, partners, and internal decision-makers.

RAIDT uses control to move from broad principles to operational governance. It asks what controlled the run, how that control was documented, whether it was followed, and whether deviations can be identified and reviewed.

Key idea: Control matters because responsible GenAI governance is credible only when each run is visibly constrained by evidence-backed rules, settings, and review conditions.

What this item controls

The authorised purpose and task boundary of a run.
The prompt template, system instruction, or approved input structure used in execution.
The model, model version, parameter settings, and tool configuration allowed for the task.
The retrieval sources, knowledge boundaries, and external data inputs that may influence outputs.
The human review checkpoints, escalation rules, and sign-off conditions attached to the run.
The extent to which users can override, improvise, or bypass approved governance settings.
The evidential traces needed to show that the run remained within an approved operational envelope.

Practical example / likely audience question

Audience question

Where is control in RAIDT, and how is it different from simply having an AI policy or a named reviewer?

Answer

The concern behind this question is usually that governance is being treated too abstractly. Many organisations can point to a policy, a committee, or a responsible manager, but none of those automatically shows that a particular GenAI run was actually controlled. The direct answer is that, in RAIDT, control is evidenced through the artefacts that shaped the run: approved prompt versions, policy-linked configuration records, model and tool settings, retrieval permissions, reviewer checkpoints, and logs of any deviations or overrides.

A practical example is a team using a GenAI assistant to draft internal policy summaries. A generic governance approach may state that staff must use approved tools and comply with policy. RAIDT goes further by showing whether the specific run used the approved prompt template, the authorised model configuration, the permitted document set, and the required reviewer decision before circulation. That makes control inspectable rather than assumed.

RAIDT handles this better than generic AI governance because it treats control as a run-level evidential property. Instead of asking only whether governance exists somewhere in the organisation, it asks whether this run can be shown to have been governed in a reconstructable way.

Practical example in RAIDT terms

Consider a healthcare setting in which a GenAI system helps draft discharge-summary language for clinicians. The use case appears routine, but the run-level issue is whether the system was used with the approved clinical prompt, the approved model version, the restricted patient data context, and mandatory clinician review before anything entered the record.

The evidence needed would include the prompt template version, model and temperature settings, retrieval boundaries, patient-data access conditions, the identity and role of the reviewer, and a record of whether the draft was accepted, amended, or rejected. If an unauthorised retrieval source or unapproved prompt variant was used, the run may no longer count as properly controlled even if the final text looked acceptable.

In RAIDT pillar terms, this strongly affects Responsibility, Auditability, Dependability, and Traceability, with a secondary effect on Interpretability. Good control improves governance readiness because it lets the organisation show not just that clinical AI use is governed in theory, but that this specific draft was produced under approved conditions and can be defended if challenged.

Detailed link to RAIDT

Control links to RAIDT in four ways.

First, it links to RAIDT's core idea by making governance concrete at the level of the run rather than leaving it at the level of abstract policy.
Second, it links to run-level evidence because control must be demonstrated through artefacts such as prompt versions, configuration states, tool permissions, and reviewer decisions.
Third, it links to the evidence pack and score profile because strong or weak control directly changes what evidence can be assembled and how confidently the run can be scored.
Fourth, it links to reviewability, contestability, audit readiness, and organisational learning because a controlled run is easier to reconstruct, challenge, compare, and improve.

Control ? Run-level evidence ? Evidence pack ? RAIDT score profile ? Governance readiness

In this sense, control is one of the mechanisms through which RAIDT converts organisational intent into inspectable governance practice.

Link to the five RAIDT pillars

Control has its strongest effects on Responsibility, Auditability, Dependability, and Traceability, but it also supports Interpretability by clarifying the conditions under which outputs were produced.

Responsibility

Control supports responsibility by showing that roles, permissions, and decision rights were translated into actual run conditions rather than left implicit.