Operator design goal
An operator library should not only list mutation mechanics. It should state the positive purpose of each operator: teach better, run cheaper, preserve privacy, increase coverage, or make the system easier to maintain.
Positive operators
| Operator | Positive purpose |
|---|---|
| Distill | Move capability into a smaller runtime. |
| Adapter merge | Combine frequently paired skills. |
| Quantize | Make local deployment practical. |
| Split specialist | Improve clarity and niche performance. |
| Retire duplicate | Reduce cost and cognitive load. |
| Generate explanation card | Improve human learning and auditability. |
FUNCTION choose_positive_operator(goal, candidate_pool)
IF goal == "lower cost"
RETURN [quantize, distill, retire_duplicate]
END IF
IF goal == "teach better"
RETURN [train_explainer_adapter, generate_lesson_card]
END IF
IF goal == "combine skills"
RETURN [adapter_merge, task_vector_merge, distill_ensemble]
END IF
RETURN [no_op]
END FUNCTIONArchitecture implication
Every operator should declare its positive purpose before it runs. That makes the lab easier to audit and easier to explain.
Source reports used for this guide
These reports are preserved verbatim in the site archive. The guide above is an editorial synthesis and may narrow, qualify, or reorganize claims from the source material.
Model merging and adaptersModel Merging: Definitions, Taxonomy, Algorithms, Tooling, and Production Pipeline DesignEmerging practice · 35.7 KB
Model merging and adaptersTiny-LLM Adapters and LoRA: Breeding Operators, Compatibility, Evaluation, and PromotionEmerging implementation practice · 15.3 KB
Positive mutualism and governanceMutualist Persistence — Uploaded EditionGovernance synthesis · 15.7 KB