S4.13 - Adapter_ID_PEFT_lineage

S4.13 — Adapter ID / PEFT lineage

flowchart LR
    A[Background problem:
base model label alone
does not reveal adapter behaviour] --> B[RAIDT
run-level evidence framework]
    H[Practical fields:
adapter ID, PEFT method,
checkpoint hash, dataset reference,
deployment state, reviewer notes] --> C[[Adapter ID / PEFT lineage
behavioural layer provenance for one run]]
    B --> C
    C --> D[Evidence pack]
    C --> E[RAIDT score profile]
    D --> F[Reviewer reconstruction
and rollback decisions]
    E --> G[Governance readiness
and organisational learning]

← Star S4 - Evidence Architecture and Artefacts

Star context: Specifies the concrete fields and artefacts that make a run record inspectable, especially where model behaviour depends not only on the base model but on attached adaptation layers, checkpoints, and fine-tuning history.

Academic picture

Definition / background

Adapter ID / PEFT lineage records the specific parameter-efficient fine-tuning component associated with a run and the provenance chain that makes that component intelligible. In practice, this can include the adapter identifier, the PEFT method used, the base model to which it was attached, the checkpoint or commit hash, the relevant training dataset reference, and any version link needed to distinguish one behavioural layer from another.

Conceptually, this item sits between a simple model version label and a full training-history dossier. A base-model identifier alone tells a reviewer what underlying model family was used, but it may not explain why the run behaved in a domain-specific or task-specific way. Adapter lineage narrows that gap by documenting the additional learned layer that materially alters behaviour without requiring a wholly new foundation model release.

This matters in GenAI governance because PEFT methods such as LoRA and related techniques make model adaptation cheaper, faster, and more modular. That is operationally useful, but it also creates a governance challenge: behaviour can change through the swapping of lightweight adapters even when the base model label remains constant. Without recording adapter lineage, organisations can mistake a technically distinct system state for the same model instance.

Inside RAIDT, the item belongs in Evidence Architecture and Artefacts because it helps define what must be captured for one run to be meaningfully reconstructable. It contributes directly to run-level evidence, strengthens the evidence pack, and improves the defensibility of a RAIDT score profile across Responsibility, Auditability, Interpretability, Dependability, and Traceability. It is therefore not just engineering provenance; it is governance-relevant provenance.

Why this concept matters

Adapter ID / PEFT lineage solves a specific governance problem: in contemporary GenAI systems, behaviour is often shaped by modular fine-tuning artefacts that are easier to change than the base model itself. If those artefacts are not recorded, a reviewer may know which model family was used but still be unable to explain why a run produced a particular style, error pattern, or domain-specific judgement.

The concept also prevents confusion between model identity and model behaviour. Two runs can both be logged as using the same foundation model yet differ because one relied on a medically tuned LoRA adapter, another on a compliance-oriented adapter, and a third on no adapter at all. From a RAIDT perspective, those are not governance-equivalent runs, because the evidential conditions of use differ in ways that matter for review, comparison, and accountability.

If this item is missing, organisations face several avoidable risks: weak incident reconstruction, poor rollback capability, difficulty validating whether an approved adapter was used, and limited ability to learn from output drift across versions. More broadly, governance remains too dependent on broad model labels and too weakly connected to the actual technical artefacts shaping a run.

Key idea: Adapter ID / PEFT lineage matters because RAIDT needs evidence of the actual behavioural layer used in a run, not only the name of the underlying base model.

What this item captures

The identifier of the adapter or PEFT artefact used in the run.
The PEFT method or adaptation type, such as LoRA, QLoRA, prefix tuning, or another lightweight fine-tuning approach.
The relationship between the adapter and the underlying base model version.
The checkpoint, commit, hash, or registry reference needed to distinguish one adapter release from another.
The training dataset reference or lineage marker associated with the adapter, where relevant and available.
The deployment or activation status showing whether the adapter was applied, swapped, stacked, or disabled for the run.
The evidential link needed to compare outputs across runs, investigate drift, and support rollback or review.
The provenance detail required to justify scoring and governance judgements in RAIDT.

Practical example / likely audience question

Audience question

If the base model version is already recorded, why do we also need Adapter ID / PEFT lineage?

Answer

The concern behind this question is that recording both may appear duplicative. The direct answer is that the base model and the adapter do different explanatory jobs. The base-model identifier tells us the underlying model family and release. Adapter lineage tells us which additional behavioural layer was attached to that base model for the run under review.

A practical example makes the difference clear. Suppose an organisation uses the same base model across several internal tasks but attaches different LoRA adapters for legal drafting, customer-service tone control, and cybersecurity triage. If a problematic output emerges, the base-model label alone will not reveal which specialised adaptation shaped the run. A reviewer needs to know whether the issue arose from the base model, from the specific adapter, from the training lineage of that adapter, or from an unauthorised version swap.

RAIDT handles this better than a generic AI governance approach because it ties the answer to a specific run and its evidence pack. Instead of asking only whether the organisation had an approved model, RAIDT asks whether the actual behavioural configuration used in the run can be reconstructed and scrutinised. That makes governance operational rather than merely declarative.

Practical example in RAIDT terms

Consider a healthcare trust using a GenAI drafting assistant to produce first-pass clinic letters. The trust deploys a common base model but applies a PEFT adapter trained to follow local clinical style, abbreviations, and redaction conventions. The run-level issue is that one generated letter includes an unsafe summary of medication changes, and the reviewer needs to determine whether the problem reflects the clinician prompt, the base model, or the domain adapter.

The evidence needed includes the run ID, timestamp, prompt version, base-model identifier, adapter ID, PEFT method, checkpoint hash, training dataset reference for the adapter, generated output, clinician edits, and reviewer notes. Responsibility is affected because the trust must show who approved the use of that adapter in clinical communication. Auditability is affected because investigators need to reconstruct the exact technical configuration. Interpretability is affected because the adapter helps explain why the output took a particular domain-specific form. Dependability is affected because repeated errors may indicate adapter drift or poor fine-tuning quality. Traceability is affected because the run must be linked to the precise artefact that influenced behaviour.

By capturing adapter lineage, RAIDT improves governance readiness. The trust can distinguish an isolated prompting issue from a wider adapter problem, justify rollback if necessary, compare runs across versions, and show that governance review extends to the real technical artefacts shaping clinical outputs.

Detailed link to RAIDT

Adapter ID / PEFT lineage links to RAIDT in four ways.

First, it supports RAIDT's core idea that GenAI governance should be based on evidence from real use rather than high-level declarations about an approved model estate.

Second, it sharpens the run as the unit of governance by identifying the precise adaptation layer active in that run, not merely the underlying model family.

Third, it strengthens both the run-level evidence pack and the score profile because reviewers can test whether model provenance, change control, and behavioural explanation are adequately evidenced.

Fourth, it improves reviewability, contestability, audit readiness, and organisational learning by making it possible to reconstruct how adapter changes affected outputs across time and tasks.

Adapter ID / PEFT lineage → Run-level evidence → Evidence pack → RAIDT score profile → Governance readiness

Link to the five RAIDT pillars

Responsibility

This item supports Responsibility by showing whether the organisation can identify who authorised, deployed, or approved the adapter used in a run and whether its use matched the intended task and governance boundary.