S6.11 - Adapter_lineage

S6.11 ? Adapter lineage

flowchart LR
    A[Background problem:
adapted behaviour hidden behind
generic base-model labels] --> B[RAIDT:
run-level evidence framework]
    B --> C[[Adapter lineage:
exact base model + adapter + checkpoint
+ training-data reference + deployment config]]
    H[Healthcare, finance, public services,
enterprise productivity, cybersecurity] --> C
    I[MLOps registry, deployment logs,
release metadata, wrapper records] --> C
    C --> D[Evidence pack]
    C --> E[Score profile]
    C --> F[Reviewer reconstruction]
    D --> G[Reviewability and contestability]
    E --> J[Governance readiness]
    F --> J
    C --> K[Organisational learning and policy alignment]

? Star S6 - Influence Methods as Governance Interventions

Star context: Positions prompting, RAG, PEFT/LoRA, RLHF/DPO and stacked influence as governance-relevant influence methods whose effects should be evidenced at run level inside RAIDT, rather than treated as the project core in themselves.

Academic picture

Definition / background

Adapter lineage is the documented chain that links a specific run to the exact adapted model state used in that run. In practice, it records the base model, adapter identifier, checkpoint or version, relevant training-data reference, and deployment configuration. The concept matters because many contemporary GenAI systems are not used in their original base form: they are altered through PEFT, LoRA-style adapters, domain tuning, task tuning, safety tuning, or other parameter-efficient interventions that change behaviour without necessarily changing the headline model name.

Conceptually, adapter lineage sits between model provenance and deployment provenance. It is narrower than full data lineage because it does not attempt to describe every historical transformation in a model pipeline. It is also more precise than simply logging a model version, because two runs may use the same base model but materially different adapters and therefore exhibit different behaviour, risk profiles, and governance implications.

Inside RAIDT, this belongs squarely within run-level evidence because RAIDT treats the run as the unit of governance. If a run is to be reviewable, then the reviewer must know not only what prompt was used or what retrieval source was attached, but also which adapted behavioural layer was active. Adapter lineage therefore strengthens the integrity of the evidence pack and improves the defensibility of the resulting score profile across the five pillars.

Why this concept matters

Adapter lineage solves a common governance failure: organisations often document that they used ?Model X? while omitting the adapter or checkpoint that actually shaped the generated output. That creates confusion when outputs are challenged, when performance drifts, when different teams report inconsistent results, or when a regulator or internal reviewer asks what exactly was deployed.

Without adapter lineage, it becomes harder to distinguish whether an issue arose from the base model, the adapter, the prompt, the retrieval context, or the surrounding workflow. That weakens accountability and makes remediation slower and less credible. With adapter lineage, organisations can move from broad claims about responsible AI to specific, inspectable evidence about which behavioural modification was active at the moment of use.

Key idea: Adapter lineage matters because RAIDT can only govern an adapted model run properly if the exact behavioural modification applied in that run is explicitly evidenced.

What this item captures

The identity of the base model from which the deployed behaviour derives.
The exact adapter artefact, identifier, or configuration attached to that base model.
The checkpoint, version, or release state of the adapter at run time.
The reference to the training dataset, tuning corpus, or learning source associated with the adapter.
The deployment configuration that determines how the adapter was invoked in practice.
The behavioural delta likely to be attributable to the adapter rather than to the base model alone.
The evidence needed for later reconstruction, comparison, rollback, review, or challenge.

Practical example / likely audience question

Audience question

Why log it?

Answer

The concern behind the question is often that logging adapter information sounds like an overly technical detail with little governance value. The direct answer is that adapter lineage is what allows a reviewer to know exactly which behavioural delta was active in the run. If a system produced an unsafe recommendation, a biased summary, or an unexpectedly confident answer, it is not enough to know only the base model family. The adapted layer may be the decisive factor.

A practical example is a domain-tuned assistant built on a common base model for internal policy interpretation. Two departments may both report using the same base model, yet one uses an adapter tuned on legacy policy documents and the other uses a newer compliance-focused adapter. If a disputed output appears, RAIDT handles the issue better than a generic AI governance approach because RAIDT expects the run-level evidence pack to distinguish those two configurations explicitly, rather than hiding them inside a vague ?model used? field.

Practical example in RAIDT terms

Consider a healthcare administration setting where a GenAI assistant drafts referral-priority summaries from clinician notes. The organisation uses a base model combined with a lightweight adapter trained to reflect local triage language and referral conventions. A problematic run occurs when the assistant overstates urgency for a non-urgent case.

The run-level issue is not simply whether the base model is suitable. The governance question is whether a specific adapter checkpoint introduced an over-assertive behavioural pattern after a recent tuning cycle. The evidence needed therefore includes the base model ID, adapter ID, adapter checkpoint, training-data reference for the tuning set, deployment timestamp, and any wrapper configuration showing which adapter was loaded.

The most affected RAIDT pillars are Auditability, Dependability, and Traceability, with secondary relevance to Responsibility and Interpretability. Adapter lineage improves governance readiness because reviewers can isolate whether the problem should trigger prompt redesign, adapter rollback, retraining review, or stronger human oversight, instead of relying on speculation.

Detailed link to RAIDT

Adapter lineage links to RAIDT in four ways.

First, it supports RAIDT's core idea that governance should focus on the actual configured use of GenAI rather than abstract descriptions of a system.
Second, it connects directly to the run by recording which adapted model state was active in that specific use event.
Third, it strengthens the evidence pack and informs the score profile by making model-configuration evidence inspectable rather than assumed.
Fourth, it improves reviewability, contestability, audit readiness, and organisational learning because later reviewers can reconstruct and compare runs with greater precision.

Adapter lineage ? Run-level evidence ? Evidence pack ? RAIDT score profile ? Governance readiness

Link to the five RAIDT pillars

Responsibility

Adapter lineage supports responsibility by showing who approved, selected, or deployed a specific behavioural modification and under what governance conditions. It helps prevent responsibility from being blurred behind a generic model label.