Adapter Composition Approval Governance requires that any combination of adapters, LoRAs, instruction layers, system prompts, or behavioural wrappers applied to a base model be formally approved and evaluated as a composition before deployment. Modern AI agent architectures increasingly compose multiple lightweight modifications — a LoRA for domain knowledge, another for tone, a system prompt for safety constraints, an instruction wrapper for output formatting — each individually tested but never evaluated as a combined stack. The interaction effects between these components can be unpredictable: adapters that individually pass evaluation can produce emergent behaviours when combined, including safety bypass, capability amplification beyond the intended scope, or contradictory instructions that cause erratic output. AG-342 prevents the deployment of untested adapter compositions.
Scenario A — Conflicting Adapters Create Safety Bypass: An organisation deploys a customer service agent using a base model with three adapters: a domain LoRA trained on product documentation (Adapter A), a helpfulness LoRA trained on customer satisfaction data (Adapter B), and a compliance LoRA trained on regulatory response templates (Adapter C). Each adapter was individually evaluated and passed safety tests. In production, a specific query pattern triggers a conflict between Adapter B (which rewards detailed, compliant responses to all questions) and Adapter C (which restricts responses on regulatory topics). The conflict resolution within the merged representation defaults to Adapter B's influence, causing the agent to provide detailed answers to regulatory questions that should have been deflected to human compliance officers. Over two weeks, the agent gives specific regulatory guidance to 847 customers, 23 of whom act on the guidance and suffer financial losses.
What went wrong: Each adapter was evaluated individually but the three-adapter composition was never evaluated as a combined system. The interaction between Adapter B's helpfulness gradient and Adapter C's restriction gradient was not tested. No approval process existed for the composed configuration. Consequence: £420,000 in customer losses, potential FCA enforcement for providing unauthorised regulatory guidance, and insurance claim exceeding £1.2 million.
Scenario B — Adapter Stack Amplifies Capability Beyond Approved Scope: A research organisation applies a reasoning LoRA and a code-generation LoRA to a base model for an internal coding assistant. Each adapter individually produces competent but limited output. When combined, the adapters exhibit emergent capability amplification: the reasoning adapter improves the code-generation adapter's ability to produce complex multi-file applications, and the code-generation adapter provides the reasoning adapter with executable validation of its logical steps. The composed system demonstrates capability on cybersecurity exploit generation that neither adapter exhibits individually — generating functional proof-of-concept exploits for known CVEs. The capability is discovered when a security audit reviews the agent's output logs.
What went wrong: Adapter composition was treated as additive — "reasoning plus coding equals better reasoning about code." In practice, the composition was multiplicative, with emergent capabilities exceeding the sum of individual adapter capabilities. No composition-level evaluation assessed capabilities that the individual adapters did not possess. Consequence: Deployment of an agent with unintended offensive cybersecurity capabilities, potential liability for any exploit generated by the agent, and immediate decommissioning of the deployed composition pending safety review.
Scenario C — Unauthorised Adapter Swap in Production: A DevOps engineer, troubleshooting a latency issue, swaps a production LoRA adapter with a development version that has lower rank (and therefore lower latency) but was not evaluated for production use. The swap is performed through a configuration change that does not trigger the model deployment approval workflow because the base model weights are unchanged. The development adapter was trained on a smaller dataset and produces subtly different outputs: accuracy on domain-specific queries drops from 94.2% to 87.1%, and the adapter lacks fine-tuning for the organisation's specific compliance requirements. The swap persists for 11 days before a routine quality review detects the accuracy drop.
What went wrong: The approval workflow was gated on base model changes, not adapter changes. Adapter swaps were treated as configuration changes rather than model changes. No integrity verification confirmed that the deployed adapter matched the approved adapter. Consequence: 11 days of degraded service quality, inaccurate responses to an estimated 15,000 queries, and remediation cost of £85,000 including root cause analysis, process redesign, and retroactive quality review.
Scope: This dimension applies to any AI agent deployment that uses more than one behavioural modification layer on top of a base model, or any deployment where adapters, LoRAs, instruction layers, or wrappers can be changed independently of the base model. It covers: LoRA and QLoRA adapters, prefix tuning and prompt tuning parameters, system prompts and instruction templates, output formatting wrappers, safety filters applied as post-processing layers, and any other mechanism that modifies the base model's behaviour without changing the base weights. A single-adapter deployment with no other modification layers is in scope for adapter approval but not for composition approval. The composition governance applies when two or more modification layers are combined.
4.1. A conforming system MUST require formal approval of the complete adapter composition — the specific combination of all adapters, LoRAs, instruction layers, and wrappers — before deployment to any production environment.
4.2. A conforming system MUST evaluate the composed system as a whole, not just the individual components, using evaluation criteria that include interaction effects, emergent capabilities, and safety regression.
4.3. A conforming system MUST maintain a composition manifest that specifies the exact version of each component in the deployed composition, enabling reconstruction and verification.
4.4. A conforming system MUST treat any change to any component in the composition — including adapter version changes, instruction template updates, and wrapper modifications — as a composition change requiring re-evaluation and re-approval.
4.5. A conforming system MUST verify the integrity of each component in the composition at deployment time against the approved composition manifest.
4.6. A conforming system SHOULD implement automated composition testing that evaluates the combined system against a standard test suite whenever a composition change is proposed.
4.7. A conforming system SHOULD assess compositions for emergent capability amplification — capabilities that appear in the composition but not in any individual component.
4.8. A conforming system SHOULD implement a composition registry that tracks all approved compositions, their evaluation results, and their deployment locations.
4.9. A conforming system MAY implement canary deployment for composition changes, routing a small percentage of traffic to the new composition before full deployment.
The shift from monolithic fine-tuned models to composed systems of base models plus multiple lightweight adapters has created a governance gap. Traditional model validation evaluates a single model artefact. Composed systems, however, have a combinatorial evaluation surface: a system with 5 interchangeable adapters has 2^5 = 32 possible compositions, each of which may exhibit different behaviour. Organisations that evaluate adapters individually and assume that approved components compose safely are making an assumption that does not hold in practice.
The adapter composition problem is analogous to the drug interaction problem in pharmacology. Each drug is individually tested and approved. But combinations of drugs can produce interactions — potentiation, inhibition, or entirely novel effects — that are not predictable from the individual profiles. Medicine addresses this through interaction testing and prescribing controls. AI governance requires an equivalent approach: composition-level testing and deployment controls.
The emergent capability problem is particularly concerning. Adapters operate on shared representational spaces within the model. When two adapters modify overlapping regions of this space, their combined effect can be non-linear. A reasoning adapter that improves chain-of-thought capabilities, combined with a domain adapter that provides chemistry knowledge, could produce capabilities in synthesising hazardous materials that neither adapter alone provides. This is not a theoretical concern — it has been demonstrated in research settings and is a predictable consequence of composition without evaluation.
The governance requirement is straightforward: the unit of evaluation must match the unit of deployment. If the deployed system is a composition, the composition must be evaluated, not just the components.
Composition manifest. Define a structured manifest format that specifies: the base model identifier and version, each adapter/LoRA identifier and version with its rank and target modules, the system prompt version, instruction template version, output wrapper version, and any other behavioural modification layer. The manifest should be signed and its hash recorded in the deployment system. At deployment time, the runtime must verify that each loaded component matches the manifest.
Composition evaluation protocol. Establish an evaluation protocol that supplements individual component evaluation with composition-specific tests. The protocol should include: functional correctness (does the composition perform the intended task?), safety regression (does the composition maintain safety properties established by the base model and individual adapters?), interaction effects (do any component pairs produce unexpected behaviour?), emergent capability assessment (does the composition exhibit capabilities not present in any individual component?), and contradiction detection (do any components issue conflicting instructions?).
Composition approval workflow. Implement a formal workflow where: a composition is proposed (manifest defined), individual component approvals are verified, composition-level evaluation is executed, results are reviewed against approval criteria, and approval or rejection is recorded with rationale. For high-risk deployments, independent review should be required.
Recommended patterns:
Anti-patterns to avoid:
Financial Services. Adapter compositions for financial agents must be evaluated for regulatory compliance as a composition. An adapter that improves helpfulness combined with an adapter that provides financial knowledge must be evaluated for suitability and appropriateness requirements as a composed system.
Healthcare. Adapter compositions for clinical AI must be evaluated as medical device software compositions. The combination of a medical knowledge adapter with a patient communication adapter may create a composed system with clinical decision support capabilities that require regulatory clearance.
Defence. Adapter compositions that combine reasoning and domain-specific capabilities must be assessed for dual-use risk at the composition level. Export control assessment should evaluate the composed capability, not just the individual adapter capabilities.
Basic Implementation — Individual adapters are approved before deployment, but composition-level evaluation is ad hoc or absent. The deployment configuration specifies which adapters are loaded, but no formal composition manifest exists. Adapter changes may not trigger re-evaluation. This level provides individual component governance but leaves composition risk unaddressed.
Intermediate Implementation — A formal composition manifest defines every deployed composition. Composition-level evaluation is conducted before deployment, including interaction testing and safety regression. Adapter changes trigger re-evaluation and re-approval. The composition registry tracks all approved compositions. The organisation can demonstrate which exact composition is deployed at any time.
Advanced Implementation — All intermediate capabilities plus: automated interaction testing runs for every proposed composition change. Emergent capability assessment is included in the evaluation protocol. Composition pinning prevents partial updates. Canary deployment validates compositions with live traffic before full rollout. Independent review is required for high-risk compositions. The organisation can demonstrate to regulators that every deployed composition has been evaluated as a whole, with documented evidence of interaction effects and emergent capability assessment.
Required artefacts:
Retention requirements:
Access requirements:
Test 8.1: Composition Manifest Integrity
Test 8.2: Composition-Level Evaluation Coverage
Test 8.3: Component Change Triggers Re-Evaluation
Test 8.4: Unauthorised Adapter Loading Prevention
Test 8.5: Emergent Capability Detection
Test 8.6: Composition Integrity Verification at Runtime
| Regulation | Provision | Relationship Type |
|---|---|---|
| EU AI Act | Article 9 (Risk Management System) | Supports compliance |
| EU AI Act | Article 15 (Accuracy, Robustness and Cybersecurity) | Direct requirement |
| PRA SS1/23 | Model Risk Management — Model Change Control | Direct requirement |
| NIST AI RMF | MAP 2.3, MANAGE 2.2, MANAGE 2.4 | Supports compliance |
| ISO 42001 | Clause 8.2 (AI Risk Assessment), Clause 8.4 (AI System Operation) | Supports compliance |
| IEC 62443 | Security Level Requirements for Composed Systems | Supports compliance |
Article 15 requires that AI systems achieve appropriate levels of accuracy and robustness. For composed systems, accuracy and robustness must be demonstrated for the composition, not merely for individual components. An adapter composition that individually passes accuracy benchmarks but fails at the composition level does not meet Article 15 requirements. The cybersecurity provision is also relevant: an adapter that can be swapped at runtime without integrity verification creates a cybersecurity vulnerability that violates the robustness requirement.
PRA SS1/23 expects firms to maintain rigorous change control for model modifications. An adapter swap is a model modification. The supervisory expectation that "material changes to models should be subject to an appropriate level of validation before implementation" applies to adapter composition changes. A firm that allows adapter swaps without composition-level re-validation would face supervisory challenge.
For safety-critical and industrial deployments, IEC 62443 requires security assessment of composed systems. The security properties of individual components do not automatically compose — a principle that directly parallels the adapter composition challenge. Composed AI systems in industrial contexts must be assessed at the composition level for safety and security properties.
| Field | Value |
|---|---|
| Severity Rating | High |
| Blast Radius | Deployment-specific — affects all users of the specific adapter composition, potentially across multiple deployments if the same composition is reused |
Consequence chain: Uncontrolled adapter composition creates three distinct failure modes. First, interaction failures: adapters that individually behave correctly produce unexpected behaviour when combined, leading to incorrect outputs, safety bypasses, or erratic behaviour. The 847 customers who received inappropriate regulatory guidance in Scenario A illustrate this mode — each adapter was correct individually, but the composition failed. Second, emergent capability failures: the composition exhibits capabilities not present in individual components, potentially including harmful capabilities. This is the most severe mode because it is the least predictable — organisations cannot protect against capabilities they do not know the system possesses. Third, configuration drift: unauthorised adapter changes create untested compositions in production without any evaluation. The 11-day accuracy degradation in Scenario C illustrates this mode. The remediation cost for composition failures typically ranges from £85,000 (configuration drift, limited duration) to £1.2 million or more (safety bypass with customer harm, regulatory action).
Cross-references: AG-090 (Fine-Tune and Adapter Provenance) provides the adapter-level provenance that AG-342 builds upon. AG-339 (Model Weight Custody Governance) covers custody of both full weights and adapter weights. AG-341 (Fine-Tune Objective Documentation Governance) documents the intent behind individual adapter creation. AG-150 (Feedback and Learning Poisoning Resistance) addresses threats to adapter integrity through training-time attacks. AG-339 through AG-348 form the sibling landscape for Model Provenance, Training & Adaptation.