S6.10 - PEFT_LoRA

S6.10 ? PEFT / LoRA

flowchart LR
    A[Problem: full-model retraining is costly
and hard to attribute or govern] --> B[RAIDT
Run-level evidence framework]
    H[Healthcare
Public services
Finance
Legal
Enterprise work] --> C[[PEFT / LoRA
Versionable adapter-based
behavioural adaptation]]
    I[Adapter registry
Validation logs
Version control] --> C
    B --> C
    C --> D[Run-level evidence pack
Adapter ID, version, scope, validation]
    C --> E[RAIDT score profile
Especially Auditability, Dependability, Traceability]
    C --> J[Governance move
Evidence over assertion
Reviewability and contestability]
    D --> F[Reviewer reconstruction
Rollback and comparison]
    E --> G[Governance readiness
Organisational learning
Policy alignment]

? Star S6 - Influence Methods as Governance Interventions

Star context: Positions prompting, RAG, PEFT/LoRA, RLHF/DPO, and stacked influence as practical intervention layers that shape how a model behaves in use. Within RAIDT, these are not the project core; they matter because they change what must be evidenced, reviewed, versioned, and governed at run level.

Academic picture

Definition / background

Parameter-efficient fine-tuning (PEFT) refers to methods that adapt model behaviour without retraining or replacing every parameter in the underlying foundation model. LoRA, or Low-Rank Adaptation, is one of the best-known PEFT approaches: instead of changing the full weight space directly, it adds small trainable adapter components that can be attached, versioned, activated, deactivated, compared, and in some settings merged. Conceptually, the attraction is not only lower computational cost, but more bounded and manageable behavioural modification.

In GenAI governance terms, PEFT / LoRA matters because it creates a distinct intervention layer between the untouched base model and the final run output. That layer can be governed more explicitly than a vague claim that a model was 'fine-tuned'. If an organisation can identify which adapter was used, when it was used, for which task, under whose approval, and with what observed effect, then the behavioural modification becomes more reviewable and contestable.

This distinguishes PEFT / LoRA from ordinary prompting and from full-model retraining. Prompting changes behaviour at inference time through instructions, whereas LoRA changes behaviour through attached learned components. Full retraining may alter the entire model and make change attribution harder. LoRA sits in a middle position: more stable and reusable than a prompt, but usually narrower and more governable than a full new model release.

Inside RAIDT, that distinction matters because the framework treats the run as the unit of governance. A run is not governed adequately if the evidence pack records only the model name and the prompt while ignoring the adapter that materially shaped the output. PEFT / LoRA therefore belongs in RAIDT because it affects run configuration, evidence sufficiency, score interpretation, and the organisation's ability to reconstruct why a given output occurred.

Its strongest connections are to Dependability, Auditability, and Traceability, though it also affects Responsibility and Interpretability. The evidence pack may need to record the adapter identifier, version, source, intended domain, approval state, test results, lineage, and rollback status. Those details then influence the five-pillar profile by showing whether the adaptation is governed as an evidence-bearing intervention rather than treated as an invisible technical tweak.

Why this concept matters

PEFT / LoRA solves a practical governance problem: organisations often need domain adaptation, policy alignment, or tone control, but do not want the opacity, cost, and change-management burden of full retraining. By using smaller adapter components, teams can localise change more clearly and manage modifications at a more tractable level.

It also avoids a common confusion in AI governance. Many discussions treat all model adaptation as though it were equally difficult to review. That is too coarse. If a behaviour change comes from a distinct adapter with a known lineage and activation state, governance can ask more precise questions: Which adapter was active in this run? Was it approved for this task? What changed relative to the baseline? Can it be rolled back? Can its effect be tested separately from the prompt and retrieval stack?

If this concept is missing, organisations may log only the base model and the prompt, while the most important behavioural shift actually came from an attached adapter. That creates false confidence in audit trails, weakens reproducibility, and makes post hoc review harder. In practice, a reviewer may be unable to reconstruct whether the observed outcome was caused by the base model, the prompt, the retrieval corpus, or the LoRA component.

For RAIDT, PEFT / LoRA helps move governance from principles to operational evidence. It turns a technical modification into something that can be named, versioned, attached to a run record, assessed in the evidence pack, and reflected in the five-pillar score profile.

Key idea: PEFT / LoRA matters in RAIDT because it makes behavioural adaptation more governable when the adapter itself becomes part of run-level evidence.

What this item enables

Targeted behavioural adaptation without requiring full-model retraining for every organisational use case.
Explicit recording of which adapter component influenced a specific run.
Version control, rollback, comparison, and approval workflows for model adaptation.
Separation of governance questions about prompts, retrieval layers, and learned adapters.
More credible evidence packs because adaptation is documented rather than assumed.
Better attribution of performance gains or governance failures to a specific intervention layer.
Scalable domain fitting for sectors that need specialised behaviour but still require audit readiness.

Practical example / likely audience question

Audience question

Why is LoRA governable in a way that ordinary fine-tuning often is not?

Answer

The concern behind the question is that any learned model adjustment may look opaque from a governance perspective. If a team says it has 'tuned the model', a reviewer may reasonably ask what exactly changed, how the change is tracked, and whether the organisation can isolate the effect of that change from everything else in the system.

The direct answer is that LoRA can be more governable because the behavioural modification is often packaged as a smaller, identifiable adapter component rather than an entirely replaced model. That makes it easier to name, hash, version, approve, compare, deactivate, or roll back. Governability does not arise automatically from the method itself; it arises when the organisation records the adapter as part of the run configuration and links it to testing and lineage evidence.

A practical example is a compliance support system built on a general language model with a financial-regulation LoRA adapter. If reviewers observe a shift in output style or policy interpretation, they can compare runs with and without that adapter, inspect its release status, and test whether the change improved domain fit or introduced new failure modes. In a generic AI governance approach, the organisation might simply state that the model was 'fine-tuned for compliance'. RAIDT handles the issue better because it asks for run-level reconstruction: which adapter version was active, what evidence justified its use, what changed in the outputs, and how that affected the pillar scores.

Practical example in RAIDT terms

Consider a public-service drafting assistant used to prepare initial responses to citizen enquiries about housing support. The organisation starts with a general foundation model but attaches a LoRA adapter trained to produce responses that better reflect local service terminology, statutory language, and organisational policy style.

The run-level issue is that a reviewer later needs to understand whether an inaccurate or overly confident answer came from the base model, the prompt template, the retrieved guidance, or the attached adapter. RAIDT therefore requires evidence that the run used a specific adapter version, that the adapter had a defined purpose, that it had been tested against representative public-service scenarios, and that its activation was permitted for this class of task.

The evidence pack would ideally include the adapter identifier, version number, approval record, deployment date, intended task scope, validation notes, rollback path, and comparisons against a baseline run without the adapter. The affected pillars are primarily Dependability, Auditability, and Traceability, with secondary implications for Responsibility and Interpretability. PEFT / LoRA improves governance readiness here because it makes adaptation a visible intervention that can be reviewed and challenged, rather than an undocumented internal change to the model stack.

Detailed link to RAIDT

PEFT / LoRA links to RAIDT in four ways.

First, it links to the RAIDT core idea by showing that governance should focus on the configured use of a GenAI system, not only on abstract statements about the underlying model.
Second, it links to the run because the presence or absence of a specific adapter materially changes what the run is, how it behaves, and what evidence is needed to explain its outputs.
Third, it links to the evidence pack and score profile because adapter identity, version, scope, and validation status are governance-relevant facts that influence how reviewers judge auditability, traceability, and dependability.
Fourth, it links to reviewability, contestability, audit readiness, and organisational learning because an adapter can be compared across runs, challenged in review, rolled back when necessary, and analysed as a discrete intervention in continuous improvement.

PEFT / LoRA ? adapter identity and lineage ? run-level evidence ? evidence pack ? RAIDT score profile ? governance readiness

This chain matters because RAIDT treats model adaptation as something that must be evidenced at the level of actual use. PEFT / LoRA is therefore not just a tuning method in the abstract; it is a specific source of behavioural influence that should be visible in the governance record of a run.

Link to the five RAIDT pillars

Responsibility

PEFT / LoRA supports Responsibility when organisations define who is allowed to create, approve, deploy, and activate adapters for particular tasks. It clarifies accountability for behavioural changes that would otherwise be hidden inside a broad claim of model improvement.