• integrated_82#Q3.20

Prompt engineering, as presented in the RAIDT papers, is a governance intervention because it deliberately designs the textual controls through which a model is steered. It specifies instructions, roles, schemas, uncertainty cues, refusal rules, and escalation language so that outputs better reflect institutional duties and stakeholder needs. In that sense, prompt engineering is not cosmetic phrasing. It is a way of embedding policy and oversight logic directly into model interaction. The prompt paper explicitly treats zero-shot, instructional, and role-based patterns as governed artefacts, while the wider corpus frames influence methods as governance interventions whose value depends on the evidence they generate across RAIDT.

Prompting is not enough on its own because prompt-only systems leave important governance gaps. The papers show that prompts can raise Interpretability and Responsibility, and sometimes partial Auditability when registry and logging discipline are strong. Yet prompt-only cannot, by itself, guarantee provenance or stable behaviour. Even perfect prompt logs do not show the external source basis of a claim, so Traceability remains limited unless retrieval is added. Zero-shot controls are also described as fragile, with greater variance and drift, which constrains Dependability. This is why the corpus consistently recommends stacked designs: prompting as the behavioural scaffold, RAG for source-linked provenance, LoRA for modular stability and domain idiom, and RLHF only where annotation governance and reward provenance are mature. Prompt engineering is therefore necessary but insufficient for audit-ready governance.

In public-service policy drafting, an instructional prompt may require the model to produce a brief with a neutral tone, a short rationale, explicit uncertainty, and a section highlighting policy risks. That is prompt engineering as governance: the prompt is crafted to make duties visible and outputs easier to scrutinise.

Yet if the brief cites no source material, an auditor still cannot determine whether a claim came from legislation, internal guidance, or the model?s prior training. RAIDT would therefore judge the prompt useful but incomplete. Adding RAG would ground claims in versioned policy documents, while a domain adapter could stabilise language across repeated runs. The prompt remains important because it structures the output and governs tone, but audit-ready performance depends on the stack rather than on prompting alone.

• 04-RAIDT_Prompt_Eng_V2
• 06-RAIDT_RAG_V1
• 07-RAIDT_RLHF_V1