Influence Methods as Governance Interventions

Explains how prompting, RAG, PEFT/LoRA, RLHF-type controls, and stacked influence methods function as governance interventions around a run, rather than as substitutes for RAIDT itself. This star clarifies how these methods shape the evidence that should be captured in a run-level evidence pack and how they affect the five-pillars profile for Responsibility, Auditability, Interpretability, Dependability, and Traceability.

This star sits in the operational governance layer of RAIDT. Its role is to connect technical mechanisms that shape model behaviour with the governance logic that evaluates a specific organisational run. It therefore supports foundations and theory by defining what counts as an intervention, supports implementation by identifying what should be logged and reviewed, supports empirical validation by making interventions comparable across cases, and supports policy pathways by showing how concrete controls can be aligned with standards and emerging regulation.

• What does an influence method mean in the RAIDT project?
• Why does RAIDT need a category for governance interventions at run level?
• What problem is created if prompting, RAG, LoRA, or RLHF-type controls are discussed only as performance techniques?
• How do these interventions change the evidence that should be captured for a run-level evidence pack?
• How do they connect to the five RAIDT pillars and score profile?
• What kind of uncertainty do influence methods reduce, and what uncertainty remains?
• What evidence would demonstrate that an intervention improved governance quality rather than only output fluency?
• How does this star help supervisors understand the technical scope of the project without mistaking the project for prompt engineering alone?

• 10-20 min ? Which influence methods materially change what evidence can be captured for a run, and which merely change style or convenience?
• 20-40 min ? Where should organisations draw the boundary between a useful intervention and an opaque intervention that weakens auditability or contestability?
• 40-60 min ? How can prompting, RAG, PEFT/LoRA, and RLHF-type controls be evaluated as governance interventions within RAIDT without allowing the project to collapse into a technical optimisation exercise?

• S6.01 ? Governance interventions
• S6.02 ? Baseline prompting
• S6.03 ? Prompting
• S6.04 ? Structured prompting
• S6.05 ? Role-based prompting
• S6.06 ? Zero-shot prompting
• S6.07 ? Chain-of-thought controlled use
• S6.08 ? RAG
• S6.09 ? Provenance-first RAG
• S6.10 ? PEFT / LoRA
• S6.11 ? Adapter lineage
• S6.12 ? RLHF-type / DPO controls
• S6.13 ? Stacked influence

Generative AI governance is often discussed at the level of the model, the vendor, or the policy statement. RAIDT takes a different unit of analysis: the run. A run is one configured use of a GenAI system for a specific task, at a specific time, in a specific organisational context. That means governance must pay attention not only to which model is used, but also to how that model is influenced during that run. Star S6 exists to make that point precise. It gathers together prompting, retrieval-augmented generation, PEFT/LoRA adapters, RLHF-type or DPO-style alignment controls, and combinations of these methods under the heading of influence methods as governance interventions.

The key idea is straightforward. These techniques do not simply improve performance. They change the conditions under which outputs are produced. A prompt frames the task. Structured prompting constrains the response format. Role-based prompting shapes perspective and tone. Zero-shot prompting assumes prior capability without added examples. Controlled chain-of-thought policies influence whether reasoning is exposed, hidden, or summarised. RAG changes the information available at generation time. Provenance-first RAG adds source transparency. PEFT/LoRA changes model behaviour through lightweight adaptation. RLHF-type or DPO-style controls shape preference behaviour and safety tendencies. When several of these are used together, the run is governed by stacked influence rather than by the base model alone.

This matters because organisational users often talk about these methods as if they were merely engineering choices. In RAIDT they are governance-relevant interventions because they alter what can be evidenced, audited, contested, and trusted. If a team changes from an unstructured prompt to a structured prompt with mandatory citation fields, that is not only a usability improvement. It is a governance move that may improve Auditability and Interpretability. If the team adds provenance-first RAG, the run becomes easier to trace and contest because the system can show which documents were retrieved and which parts of the answer depended on them. If a model is paired with a domain adapter through LoRA, then adapter version, training scope, and deployment status become part of the governance record. If a vendor has applied RLHF-type controls, the organisation still needs to know what behavioural tendencies those controls introduce, even if it cannot inspect the full training pipeline.

The problem that S6 solves is therefore conceptual and practical. Conceptually, it prevents the RAIDT project from drifting into a false choice between technical methods and governance theory. RAIDT is not a prompt engineering project, a RAG project, or a fine-tuning project. It is a governance framework that evaluates the run-level consequences of those methods. Practically, S6 gives the project a disciplined way to describe interventions that managers and supervisors repeatedly encounter in real deployments. Without this star, discussions about performance, uncertainty, evidence, and risk become blurred. With it, the project can ask a sharper question: which intervention was used, what uncertainty was it meant to reduce, what new uncertainty did it create, and what evidence was captured to support that claim?

This framing is particularly important in settings of managerial uncertainty. Managers do not usually need a full account of a foundation model's internal parameters. They need defensible assurance about whether a specific run was appropriately configured, evidence-backed, and reviewable for the task at hand. Influence methods affect that assurance. Prompting can reduce ambiguity but may also embed hidden assumptions. RAG can improve factual grounding but can also import poor-quality or stale documents. LoRA adapters can increase domain fit but may reduce transparency if adapter lineage is weak. RLHF-type controls can suppress harmful behaviour patterns but may also create opaque refusals or preference distortions. Stacked influence can produce strong operational performance while making causal attribution harder. RAIDT helps by requiring each of these interventions to be documented as part of the run-level evidence pack rather than treated as invisible background.

The connection to the five pillars is direct. Responsibility concerns who selected and approved the intervention, and whether its use is proportionate to the task risk. Auditability concerns whether the intervention can be inspected after the event through logs, versions, prompts, retrieval records, or adapter metadata. Interpretability concerns whether a reviewer can understand how the intervention shaped the output, even if the underlying model remains partly opaque. Dependability concerns whether the intervention improves consistency, robustness, and error handling in repeated use. Traceability concerns whether the organisation can reconstruct the path from task definition to output, including sources, configurations, and checks. S6 is therefore not an optional technical annex. It is a bridge between intervention design and RAIDT scoring.

Practical examples make the point clearer. In a policy drafting run, a structured prompt requiring source labels and uncertainty flags can transform a vague output into one that supports review. In a university administration run, provenance-first RAG can ensure that answers are tied to current internal regulations rather than general web patterns. In a specialised healthcare coding support run, a LoRA adapter may improve domain language handling, but the governance question becomes whether the adapter's lineage, intended scope, and validation evidence are available. In a customer service deployment using vendor-supplied alignment controls, the organisation still needs evidence of refusal patterns, escalation rules, and known behavioural boundaries. In each case, the governance issue is not whether the method is fashionable. The issue is whether the method makes the run more governable.

S6 also supports empirical work. Paper 09 needs comparable cases, and comparable cases require a stable vocabulary for what kinds of intervention are present in each run. If one case uses only baseline prompting, another uses RAG plus structured prompting, and another adds a domain adapter, RAIDT needs a way to compare their evidence packs and score profiles without confusing intervention complexity with governance quality. This star provides that vocabulary. It also supports Paper 10 by translating technical intervention choices into policy-relevant categories such as provenance, documentation, human oversight, and controllability, which align more naturally with frameworks such as the EU AI Act, ISO/IEC 42001, and NIST AI RMF.

The boundaries are equally important. S6 does not claim that influence methods guarantee trustworthy outputs. It does not claim that better prompting removes the need for human review. It does not claim that RAG automatically produces truth, that LoRA adaptation is inherently safer, or that RLHF-type controls are fully transparent. Nor does it claim that every organisation should use all of these methods. The point is narrower and stronger: when such methods are used, they should be treated as governance-relevant interventions whose presence, configuration, rationale, and effects are evidenced at run level.

For supervisors, this star helps explain why RAIDT can remain conceptually coherent while still engaging with technical detail. The project does not reduce governance to a checklist of tools. It shows that real organisational governance of GenAI happens through concrete intervention choices made around specific runs. S6 is the note that names those choices, classifies them, and ties them back to evidence, scoring, uncertainty, and policy alignment.

Q1. What is an influence method in RAIDT?

Answer:
An influence method is any technique that materially shapes how a GenAI system produces an output in a specific run. In RAIDT this includes prompt design, retrieval setup, adapters such as PEFT/LoRA, alignment controls, and combinations of these. The term is useful because it focuses attention on governance-relevant configuration choices rather than treating the model as a fixed black box.

Practical example:
A legal support team changes from a free-text prompt to a structured prompt that requires issue, rule, evidence, and confidence sections.

Link to RAIDT:
The intervention becomes part of the run record and affects the evidence pack by making the run easier to review, compare, and score on Auditability and Interpretability.

Q2. Why does RAIDT need this category at run level?

Answer:
RAIDT needs it because governance failures often arise from how a model is used rather than from the base model alone. A run may be safe or unsafe, well-documented or opaque, depending on its specific interventions. Run-level analysis captures that variation.

Practical example:
The same model may be acceptable for internal brainstorming with baseline prompting but unsuitable for formal policy advice unless RAG, source logging, and human checks are added.

Link to RAIDT:
The category helps RAIDT compare runs fairly and ties configuration choices to the evidence pack and score profile.

Q3. Why are prompting and RAG not the core of the project?

Answer:
They are not the core because RAIDT is a governance framework, not a method-specific optimisation study. Prompting and RAG matter only insofar as they change governability, evidence quality, and the conditions of responsible use.

Practical example:
A workshop participant may ask whether better prompts solve the governance problem. The answer is no: better prompts can help, but they still need logging, review, accountability, and policy alignment.

Link to RAIDT:
S6 keeps these methods in their proper place as inputs into governance evaluation rather than replacements for RAIDT's five pillars.

Q4. How does RAG change governance requirements?

Answer:
RAG changes governance requirements because it introduces an additional evidence chain. Reviewers need to know what corpus was searched, what was retrieved, how relevance was determined, whether provenance was preserved, and whether stale or conflicting documents were present.

Practical example:
An HR chatbot retrieves an outdated leave policy and gives an incorrect answer. Without retrieval logs and document timestamps, the organisation cannot explain the error.

Link to RAIDT:
RAG directly affects Traceability, Auditability, and contestability within the run-level evidence pack.

Q5. What is the governance significance of PEFT or LoRA?

Answer:
PEFT and LoRA are governance-significant because they alter model behaviour while often being deployed as lightweight technical additions. This means organisations need to record adapter provenance, intended purpose, version history, validation approach, and deployment boundaries.

Practical example:
A finance team uses a LoRA adapter for internal reporting language. The adapter improves terminology, but no one can later identify which adapter version produced a questionable output.

Link to RAIDT:
Adapter lineage becomes evidence. Without it, Traceability and Dependability scores should be lower.

Q6. Why do RLHF-type or DPO-style controls still matter to organisations that did not train the model?

Answer:
They matter because these controls shape refusal patterns, politeness, safety behaviour, and response preferences that appear during organisational use. Even when the training details are external, their effects still influence the run and should be acknowledged in governance analysis.

Practical example:
A model repeatedly refuses benign but sensitive internal audit questions because of vendor safety tuning, causing operational friction.

Link to RAIDT:
RAIDT records the known behavioural boundaries of the deployed system and treats them as part of the interpretive context for the run.

Q7. What is stacked influence?

Answer:
Stacked influence means that multiple interventions operate together in one run, such as a structured prompt on top of RAG on top of a domain adapter on top of vendor alignment controls. The output is shaped by the combination, not by one method alone.

Practical example:
A compliance assistant uses a policy-specific prompt template, provenance-first RAG, and a domain adapter trained for regulatory phrasing.

Link to RAIDT:
Stacked influence increases the need for evidence because the run-level pack must show the intervention chain and support scoring across all five pillars.

Q8. How do influence methods relate to uncertainty?

Answer:
They are used to reduce some forms of uncertainty, such as ambiguity in task framing or factual uncertainty in retrieval, but they can also create new uncertainty about hidden assumptions, retrieval quality, or interaction effects. Governance therefore requires both intervention and evidence.

Practical example:
Adding RAG reduces uncertainty about source access, but if the retrieval corpus is incomplete the system may express confidence built on a partial evidence base.

Link to RAIDT:
RAIDT uses the evidence pack to distinguish between uncertainty reduction claims and actual evidential support for those claims.

Q9. What evidence would show that an intervention improved governance rather than only performance?

Answer:
Useful evidence includes clearer provenance, stronger reproducibility, better reviewer understanding, lower error rates in validation, improved escalation behaviour, and more consistent documentation across similar runs. Purely subjective claims of better answers are not enough.

Practical example:
After introducing a structured prompt with mandatory citations, reviewers can consistently identify unsupported statements and challenge them before use.

Link to RAIDT:
This kind of evidence supports stronger scoring on Auditability, Interpretability, and Dependability and is directly suitable for the evidence pack.

Q10. How does this star help supervisors understand the RAIDT project?

Answer:
It shows that RAIDT engages technical detail without becoming technically reductionist. Supervisors can see how concrete intervention choices connect to governance theory, empirical comparison, and policy relevance.

Practical example:
In a supervision meeting, this note can explain why a case study records prompt templates, retrieval logs, and adapter versions instead of discussing only abstract ethical principles.

Link to RAIDT:
S6 helps position Papers 08, 09, and 10 as a coherent programme linking foundations, evidence, and policy pathways around the run.

1. Procurement evaluation assistant
   A public-sector team uses structured prompting plus provenance-first RAG to draft supplier comparison notes. The intervention improves source visibility and makes later challenge more feasible.

2. University policy helpdesk
   A student-facing assistant retrieves internal regulations and answer templates. Governance depends on document version control, retrieval logs, and human escalation for ambiguous cases.

3. Clinical administration support
   A healthcare administration tool uses a LoRA adapter to match local terminology. The governance question is whether adapter scope, validation evidence, and prohibited uses are documented.

4. Internal audit drafting tool
   A vendor model with RLHF-type controls produces cautious summaries but sometimes over-refuses. RAIDT treats refusal tendencies, override rules, and review pathways as part of the run-level evidence.

5. Compliance reporting workflow
   A stacked setup combines role-based prompting, RAG, and a domain adapter. Performance may improve, but the organisation must still document which layer influenced the final output and how reviewers checked it.

• Run identifier, task description, date, user role, and organisational context.
• Prompt text, prompt template version, and any structured fields or role instructions.
• Model name, version, provider, temperature, tool settings, and deployment environment.
• Whether zero-shot, few-shot, role-based, or controlled reasoning guidance was used.
• Retrieval status, corpus definition, retrieval query, retrieved documents, timestamps, and provenance links.
• Whether provenance-first RAG was enforced and how citations were rendered.
• Adapter or LoRA identifier, version, lineage, intended scope, and validation status.
• Known RLHF-type or DPO-style behavioural controls, refusal tendencies, and documented limitations.
• Sequence of stacked interventions applied in the run.
• Human checks, automated checks, escalation decisions, and acceptance or rejection outcome.
• Error notes, uncertainty flags, and post-run reflections relevant to scoring.
• Pillar scores with justification for Responsibility, Auditability, Interpretability, Dependability, and Traceability.

• Paper 08: foundations and methodological pathways
  S6 provides a conceptual category for influence methods and explains why run-level governance must account for technical interventions without becoming reducible to them.

• Paper 09: empirical validation
  S6 supports case comparison by giving a stable vocabulary for intervention types, evidence requirements, and expected score effects across different runs and sectors.

• Paper 10: policy pathways
  S6 translates technical configuration choices into policy-relevant governance categories such as documentation, provenance, oversight, controllability, and contestability.

• Sector playbooks
  This star helps sector guides specify which interventions are acceptable, what evidence must be captured, and where additional human review is mandatory.

• RAIDT scoring
  Influence methods shape pillar scores because they affect explainability of the run, reproducibility of the evidence, and accountability for configuration choices.

• RAIDT evidence pack
  This note identifies the concrete fields that allow a run to be reconstructed and assessed after the event.

• RAIDT governance interventions
  S6 is the hub note that names, organises, and differentiates the main intervention classes used around GenAI runs.

• Responsible AI governance literature on documentation, accountability, and contestability.
• Information Systems governance literature on controls, assurance, and managerial decision support.
• Prompt engineering studies that discuss structured prompting, role prompting, and reliability limits.
• RAG literature focused on retrieval quality, provenance, and factual grounding.
• PEFT and LoRA literature on lightweight adaptation, deployment efficiency, and model modification traceability.
• RLHF and DPO literature on alignment controls, preference shaping, and behavioural side effects.
• Standards and policy sources on documentation and oversight, especially EU AI Act, ISO/IEC 42001, and NIST AI RMF.
• Empirical evaluation studies comparing intervention setups across tasks, sectors, or risk levels.

• This star does not claim that influence methods are sufficient for trustworthy AI governance.
• It does not treat prompt quality as a substitute for accountability, audit, or human oversight.
• It does not assume that RAG guarantees truth or that source retrieval is always reliable.
• It does not assume that LoRA or other adapters are transparent simply because they are lightweight.
• It does not assume that vendor alignment controls are fully observable or normatively correct.
• It does not offer a complete causal explanation of model internals.
• It focuses on run-level governance relevance, not on exhaustive technical optimisation.

This star explains how RAIDT handles the main techniques people usually discuss when they talk about controlling generative AI behaviour. The key point is that prompting, RAG, LoRA-style adaptation, and RLHF-type controls are not the project itself. They are governance interventions that shape what happens in a specific run and therefore shape what evidence should be captured. RAIDT treats the run as the unit of governance, so if an organisation changes the prompt template, adds retrieval, deploys an adapter, or relies on vendor alignment controls, those are not background details. They alter responsibility, auditability, interpretability, dependability, and traceability. This note helps keep the project conceptually disciplined. It lets us discuss technical mechanisms in a precise way without collapsing the thesis into prompt engineering or model tuning. It also supports the empirical and policy papers because it gives us a shared vocabulary for comparing cases, specifying evidence packs, and translating technical intervention choices into governance categories that supervisors, practitioners, and policy audiences can all understand.