Multi-LoRA Composition Chains

The chain is the artifact

A multi-LoRA runtime is not “base plus adapters” in the abstract. It is a specific chain:

base family → adapter A → adapter B → safety adapter C → router-selected prompt policy → memory state → tool profile

Changing one edge can change the behavior. Changing the order can change the behavior. Changing the base can change the behavior. Changing the evaluator can change what gets promoted.

Higher-order interaction

Pairwise tests can miss the unsafe path. Adapter A may pass with the base. Adapter B may pass with the base. The safety adapter may pass with the base. The risky behavior may require A, B, and C loaded together under a specific route.

That makes the composition chain the minimum unit of evaluation.

Safety adapters are not magic shields

A safety adapter can reduce risk in one tested context while interacting unpredictably in another. It may conflict with a capability adapter, be bypassed by a route that invokes a different stack, or fail under a quantized inference setting. The correct claim is never “the stack is safe because it includes a safety adapter.” The correct claim is “this exact stack was evaluated for these behaviors under these conditions.”

Required manifest fields

A multi-LoRA composition manifest should record:

• base model hash and base family;
• adapter identifiers, hashes, source registries, and authors;
• load order;
• merge coefficients or activation weights;
• compatibility constraints;
• prompt-policy version;
• router version and route condition;
• memory snapshot identifier;
• tool permission profile;
• evaluator version and evaluator family;
• inference and quantization configuration;
• UTC deployment timestamp.

Without those fields, later investigators cannot reconstruct the actual chain that produced an incident.