• integrated_82#Q3.7

Adapter IDs matter because they convert a hidden technical variation into a reviewable governance object. The technical foundation paper argues that two uses of the same model family can differ materially in evidentiary quality, accountability, and governance risk when prompt structure, retrieved context, settings, or adaptation layers change. In RAIDT terms, an adapter ID is therefore a crucial part of configuration provenance: it identifies which specialised behaviour was active in a particular run, rather than leaving reviewers with only a generic model name. This is especially important for PEFT and LoRA components, because they can alter outputs while preserving the appearance of the same underlying model family.

Adapter IDs also matter operationally. They support comparison across runs and configurations, incident review, rollback, and audit sampling. A run-level evidence pack with a stable adapter identifier can be linked to prompt versions, retrieval snapshots, oversight actions, and output hashes, allowing reviewers to test whether a governance issue is concentrated in one adapted checkpoint rather than in the whole service. That improves the quality of the score profile because evidence can be attributed to the actual configuration that shaped the output. By contrast, if the adapter is unnamed or ambiguously versioned, provenance remains fragmented: the organisation may have logs, but not a bounded record that explains what happened. In RAIDT, adapter IDs matter precisely because influence methods as governance interventions must leave an intelligible evidence trail if governance claims are to be inspectable, comparable, and contestable.

In a cybersecurity alert triage workflow, a team deploys a generative-AI assistant to draft priority assessments for incoming alerts. The base model remains unchanged, but the engineering team introduces a LoRA adapter intended to improve domain-specific consistency. A month later, reviewers discover that some medium-severity alerts were being framed too confidently, affecting analyst workload and escalation decisions.

If each run records the adapter ID and checkpoint lineage, the team can isolate whether the problem began with the new adapter, reproduce the affected runs, compare repeat-run behaviour, and roll back the precise component that changed governance performance. The evidence is then usable by security leads, internal audit, and risk teams. Without adapter IDs, the organisation might know only that the same model family was used, which is insufficient for determining which adapted configuration produced the problematic triage recommendations.

• 18-RAIDT-Technical-Foundation_M_v04
• 13-RAIDT-Evidence-Review_M_v10