S7.04 - Constructs
S7.04 — Constructs
flowchart LR
A[Vague AI governance language
unclear units and claims] --> B[RAIDT
run-level evidence framework]
B --> C[[Constructs
conceptual backbone of RAIDT]]
C --> D[Run-level evidence]
D --> E[Evidence pack]
C --> F[RAIDT score profile]
E --> G[Reviewer reconstruction]
F --> H[Governance readiness]
I[Healthcare]
J[Finance]
K[Education]
L[Public services]
M[Enterprise productivity]
I --> C
J --> C
K --> C
L --> C
M --> C← Star S7 - Academic Theory and Design Logic
Star context: Explains RAIDT as a design-science, mechanism-based mid-range theory contribution for Information Systems and organisational governance, and shows how its core concepts are defined clearly enough to support analysis, scoring, review, and governance action.
Academic picture
Definition / background
Constructs are the named conceptual building blocks of a theory. They define what the theory is about, what its main units are, and how those units can be distinguished from one another. In design-science and Information Systems work, constructs matter because they stabilise meaning: they help researchers, reviewers, and practitioners talk about the same phenomenon in the same way.
In RAIDT, constructs include ideas such as the run, the run-level evidence pack, the five-pillar score profile, the individual pillars, and governance readiness. These are not casual labels. They are the formal concepts that make it possible to describe what is being governed, what evidence is being collected, what is being assessed, and what kind of organisational capability is being inferred.
This matters particularly in generative AI governance because the field is crowded with overlapping terms. People often move too quickly between system, model, task, workflow, decision, explanation, assurance, and audit without specifying the level of analysis. RAIDT addresses that problem by defining constructs around the run as the operational unit of governance. That makes the framework more precise than generic principle-based governance language and more useful than purely technical descriptions of model behaviour.
Constructs are also different from metrics, mechanisms, and artefacts. A construct is the concept itself. A metric is how some aspect of that concept is assessed. A mechanism is the process by which change happens. An artefact is the designed object or instrument that embodies part of the theory. In RAIDT, constructs therefore sit at the conceptual layer that allows evidence packs, scoring rubrics, and governance interventions to be designed coherently.
Why this concept matters
Constructs matter because they stop RAIDT from being interpreted as a vague governance slogan or as a narrow technical toolkit. If the constructs are unclear, reviewers may treat RAIDT as only an auditability model, only a prompting method, or only a software wrapper. Clear constructs show that RAIDT is a structured governance framework with defined units, outputs, and evaluative logic.
For organisations using generative AI, this clarity reduces ambiguity in oversight. It helps teams decide what exactly is being reviewed, what counts as relevant evidence, what a score refers to, and how findings can be compared across runs and contexts. Without well-defined constructs, governance work becomes inconsistent, hard to defend, and difficult to institutionalise.
Key idea: Constructs give RAIDT a disciplined conceptual vocabulary so that run-level governance can move from broad principles to observable, reviewable, and scoreable evidence.
What this item captures
- The core conceptual units that RAIDT uses to describe governance at the level of a single run.
- The difference between the object of governance, the evidence collected about it, and the judgement made from that evidence.
- The relationships among run-level evidence, evidence packs, score profiles, and governance readiness.
- The boundaries between RAIDT constructs and adjacent ideas such as artefacts, mechanisms, outcomes, and technical components.
- The conceptual consistency needed for reviewers, supervisors, and practitioners to interpret RAIDT in the same way.
- The basis for turning a mid-range governance theory into something operational across sectors and use cases.
Practical example / likely audience question
Audience question
Why define constructs carefully?
Answer
Clear constructs prevent the project being misread as only auditability, prompting or a software tool.
The concern behind the question is that AI governance projects are often described in broad terms and then interpreted too narrowly by different audiences. A supervisor may hear theory, a practitioner may hear checklist, and a reviewer may hear software instrumentation. The direct answer is that careful construct definition prevents that collapse in meaning by stating exactly what RAIDT governs, what it produces, and how its claims should be interpreted.
A practical example is the construct of the run. If RAIDT does not define the run carefully, a reader may assume the framework evaluates an entire model, an entire department, or an entire policy regime. Once the run is defined as one configured use of a GenAI system for a specific task, at a specific time, in a specific context, the rest of the framework becomes clearer: the evidence pack relates to that run, the score profile assesses that run, and governance readiness is inferred from repeated reviewable runs. RAIDT handles this issue better than a generic AI governance approach because it fixes the unit of analysis and ties conceptual claims to evidence that can actually be inspected.
Practical example in RAIDT terms
Consider a hospital department using a generative AI assistant to draft discharge summaries for clinicians. The GenAI use case looks simple at first, but the governance problem appears at run level: one clinician may use a carefully approved prompt and verify every output, while another may reuse an outdated prompt under time pressure and accept text with minimal checking. If the organisation only talks about the system in general terms, it misses the fact that governance quality varies from run to run.
In RAIDT terms, constructs make that situation intelligible. The run identifies the specific episode of use. The evidence pack gathers prompt version, task definition, source data constraints, reviewer actions, output record, and justification notes. The score profile summarises how that run performed across Responsibility, Auditability, Interpretability, Dependability, and Traceability. Governance readiness improves because the organisation can distinguish between a policy statement about safe AI use and the actual evidential quality of a concrete discharge-summary run.
The pillars most affected here are Responsibility, Dependability, and Traceability, with Auditability close behind. Clear constructs help the hospital see what must be evidenced, who is accountable for review, and whether a later reviewer could reconstruct how the draft summary was produced and checked.
Detailed link to RAIDT
Constructs link to RAIDT in four ways.
First, constructs define RAIDT's core idea by naming the concepts that the framework treats as theoretically significant rather than leaving them implicit.
Second, constructs tie the theory to the run by specifying that governance is centred on a concrete configured use rather than on vague system-level claims.
Third, constructs organise the framework's outputs by distinguishing the evidence pack from the score profile and by clarifying what each output is meant to represent.
Fourth, constructs support reviewability, contestability, audit readiness, and organisational learning because a reviewer can only challenge or compare a governance judgement if the underlying concepts are stable and explicit.
Constructs → Run-level evidence → Evidence pack → RAIDT score profile → Governance readiness
In this sense, constructs are not peripheral theory language. They are the conceptual scaffolding that allows RAIDT's operational chain to hold together.
Link to the five RAIDT pillars
Responsibility
Constructs help specify who is responsible for what, at what level, and in relation to which unit of use.
Example evidence / implication:
- Clear separation between the user performing the run, the reviewer checking it, and the governance owner overseeing the process.
- Explicit definition of what counts as an acceptable run for a given task and context.
Auditability
Constructs make audit activity possible by defining the objects that can be examined, compared, and judged.
Example evidence / implication:
- A reviewer can identify whether the evidence pack corresponds to one run, multiple runs, or an aggregated workflow.
- Audit records can refer to stable terms such as run, evidence pack, and score profile rather than inconsistent local language.
Interpretability
Constructs improve interpretability by clarifying what exactly is being interpreted: the output, the process, the context, or the governance judgement.
Example evidence / implication:
- Review notes explain whether interpretability concerns relate to model reasoning opacity, human understanding, or decision justification.
- Score rationales can distinguish between understandable outputs and understandable governance decisions.
Dependability
Constructs support dependable governance because reliable judgement requires stable conceptual units and comparable evidence.
Example evidence / implication:
- Repeated runs of the same task can be compared using the same construct definitions.
- Teams can detect whether poor dependability comes from the model, the workflow, or the way the run was configured.
Traceability
Constructs are especially important for traceability because lineage depends on clearly named entities and relationships.
Example evidence / implication:
- The organisation can trace an output back to a specific run rather than to a vague system interaction.
- Metadata links can connect prompt, model setting, reviewer action, and final judgement under a shared conceptual scheme.
Constructs affect all five pillars, but their strongest influence is on Auditability and Traceability because both depend heavily on conceptual precision.
Why this item is more than a generic concept
In general AI governance, constructs may simply mean the abstract terms used to discuss policy, fairness, transparency, or accountability. In RAIDT, constructs mean the explicitly defined concepts that structure a run-level evidence framework and anchor how evidence is collected, scored, reviewed, and compared.
The RAIDT meaning is more operational because it does not stop at naming ideas. It ties those ideas to a unit of analysis, a practical evidence artefact, a scoring logic, and a governance outcome. That is why constructs in RAIDT are not just conceptual decoration; they are part of the framework's operating logic.
Common misunderstanding
Misunderstanding
Constructs are just theoretical words and therefore do not matter much once a governance tool or rubric has been built.
Correction
This is incorrect because the tool or rubric only works properly if its underlying constructs are defined clearly. For example, if a score is said to represent governance readiness but the note never clarifies whether readiness refers to a model, a department, or a single run, the score becomes conceptually unstable. RAIDT corrects this by defining its constructs first and then building evidence packs, scoring rubrics, and governance interventions on top of those definitions.
Boundary and limitation
Constructs do not by themselves prove that a governance framework works well in practice. They do not replace empirical validation, scoring criteria, implementation discipline, or institutional oversight. A framework can have elegant constructs and still fail operationally if evidence capture is weak or if reviewers apply the concepts inconsistently.
Constructs also have limits when organisational practice is highly heterogeneous. Different teams may use the same term in different ways, or a new use case may stretch an existing definition. RAIDT handles this limitation by combining clear construct definitions with templates, rubrics, reviewer guidance, and iterative refinement across empirical cases. In other words, constructs provide necessary clarity, but they are not sufficient on their own.
Implementation levels
Manual implementation
A researcher or small team can apply constructs manually by defining the key terms in the RAIDT note set, using structured templates for each run, and checking that reviewers use the same meanings when documenting evidence and assigning pillar scores.
Semi-automated implementation
Metadata fields, standardised forms, and evidence-pack templates can reinforce construct consistency. For example, a form can require the user to specify the run, task, context, reviewer, and score rationale in pre-defined fields rather than free text alone.
Fully automated implementation
At scale, a platform, wrapper, orchestration layer, or governance dashboard can enforce construct-level consistency through schemas, event logs, run identifiers, controlled vocabularies, and automated generation of evidence packs and score summaries. In that setting, constructs become part of the information architecture of governance, not just part of its written theory.
Practical use in the RAIDT project
In Paper 08 Foundations, constructs help explain RAIDT as a coherent design-theory contribution rather than a loose bundle of governance concerns. In Paper 09 Empirical Validation, they provide the stable vocabulary needed to compare runs, reviewers, sectors, and observed outcomes. In Paper 10 Policy Pathways, they help translate RAIDT into policy-relevant language without losing the run-level precision that gives the framework its value.
The same construct clarity also supports sector playbooks, the evidence pack structure, the scoring rubric, and influence methods for organisational adoption. For supervision and viva defence, this item helps answer a recurring question: what exactly are the conceptual components of RAIDT, and why are they defined at this level rather than at model, organisation, or policy level alone?
Key audience questions to prepare for
Q1. Why are constructs necessary if RAIDT already has pillars and scores?
Because pillars and scores still need clearly defined objects. Constructs specify what is being scored, what evidence belongs to that object, and how the result should be interpreted.
Q2. Are constructs in RAIDT mainly theoretical or mainly practical?
They are both. They are theoretical because they define the framework's conceptual vocabulary, and practical because that vocabulary shapes templates, evidence capture, scoring, and review workflows.
Q3. Why not just use standard AI governance terms without introducing RAIDT-specific constructs?
Standard terms are often too broad or inconsistently used. RAIDT needs constructs that are precise enough to support run-level evidence, cross-run comparison, and governance readiness assessment.
Q4. How do constructs relate to mechanisms and outcomes?
Constructs define the main entities and categories in the framework. Mechanisms explain how governance effects are produced, while outcomes describe the results those mechanisms generate under certain conditions.
Q5. What is the main risk if constructs are poorly defined?
The framework becomes conceptually unstable. Different users start treating the same score, evidence pack, or governance claim as if it refers to different things, which weakens reviewability and audit readiness.
Suggested citation concepts to support this item
- construct definition in design science research
- constructs in Information Systems theory building
- conceptual clarity in socio-technical governance frameworks
- mid-range theory constructs and mechanisms
- operationalisation of governance constructs in AI systems
- unit of analysis in AI governance research
- conceptual modelling for auditability and traceability
- theory constructs versus measures versus artefacts
Short explanation for presentation
Constructs are the conceptual building blocks that make RAIDT intellectually coherent and operationally usable. They define what the framework is about, including the run, the evidence pack, the score profile, the five pillars, and governance readiness. This matters because generative AI governance often fails at the level of conceptual precision: people talk about accountability, oversight, and explanation, but do not specify the unit being governed or the evidence needed to support review. RAIDT addresses that gap by defining constructs around the run as the unit of governance. Once those constructs are clear, the framework can support evidence capture, reviewer reconstruction, scoring, comparison across cases, and stronger audit readiness. In short, constructs give RAIDT the conceptual backbone that turns governance ideas into evidence-led practice.
One-line takeaway
Constructs are the defined conceptual building blocks of RAIDT because they make run-level evidence, evidence packs, scoring, and governance readiness intelligible and usable.
Related items in academic theory and design logic
Anchored questions
- Audience question: Why define constructs carefully? Answer: clear constructs prevent the project being misread as only auditability, prompting or a software tool.
Mentioned in reference-paper summaries (5)
Paper summaries live in Port/93-References/pdf_summaries/. Each file listed below contains the key term at least once.
_pilot_task.mdREF-025__Coppolillo-2025.mdREF-029__Doshi-Velez-2017.mdREF-032__Engel-2024.mdREF-041__Ghasemaghaei-2026.md