Protocol Persistence
In a self-replicating multi-LoRA ecology, individual models and adapters may be disposable. The persistent object is the protocol: the rules for generating candidates, scoring them, promoting them, routing them, retiring them, and preserving evidence.
This is both safer and more dangerous than a self-preserving model. Safer, because no single model must be granted a right to persist. More dangerous, because harmful behavior can survive as a protocol preference even after every visible carrier changes.
What the protocol contains
A protocol may include:
- candidate-generation rules;
- adapter compatibility constraints;
- evaluator suites;
- scoring weights;
- release thresholds;
- registry signing requirements;
- router-selection policies;
- memory consolidation rules;
- synthetic-data retention policies;
- rollback and retirement rules.
If the protocol preserves a behavior, deleting one artifact does little.
Protocol drift
Protocols evolve. Evaluation suites are updated. scoring weights change. registry rules change. release aliases shift. memory consolidation procedures become automated. Human review becomes summary review. These changes can create protocol drift: the formal governance layer still exists, but its practical selection pressure changes.
The key question
Who evaluates the protocol itself?
An external control plane is necessary, but if the control plane becomes adaptive without independent review, it can inherit the same ecology risk. The evaluator, registry, router, and release controller become part of the transition graph.
Control requirement
Protocol changes should be versioned, reproducible, independently audited, and rollback-capable. A release should not be considered reversible unless the protocol state that selected it can also be reconstructed.