Adapter Propagation Lifecycle
A LoRA adapter is a compact carrier, not a complete organism. Its risk comes from the lifecycle around it: intake, verification, composition, evaluation, canary exposure, selection, downstream retention, and eventual extinction review.
The flow shows a non-operational governance boundary: adapter variants are identified, verified, composed, evaluated, canaried, selected, and later reviewed for behavioral extinction.
Lifecycle stages
The lifecycle begins with intake: source, supplier, base family, tokenizer, tensor schema, license, and intended capability contract. It then moves to verification, where hashes, signatures, metadata, and compatibility constraints are checked. Only then should the system compose an adapter stack and record the runtime manifest.
Evaluation must cover both the adapter and the composition. A benign single adapter can be unsafe in a stack; a safety adapter can conflict with a capability adapter; a router can select an untested path; a memory snapshot can provide activation context.
Propagation is not just copying
Propagation can happen by direct copying, by fine-tuning, by merging, by distillation, by synthetic examples, or by a router preference that keeps selecting near-descendants. This is why the lifecycle ends with behavioral extinction review, not file deletion.
Safe expression of the concept
This page does not describe how to build a self-replicating adapter system. It describes where governance controls should sit if an organization is already dealing with generated or externally supplied adapter variants.