Use separate names for separate control problems
The research corpus contains several overlapping terms. ModelBreeder.com uses the following normalized vocabulary so discussions remain operationally precise.
| Term | Preferred meaning | Avoid implying |
|---|---|---|
| Model breeding | Creating and selecting parameterized model descendants. | Autonomous reproduction or biological agency. |
| Code breeding | Controlled variation of algorithms, routing, kernels, workflows, or infrastructure code. | Allowing a model to change its own evaluator or security policy. |
| Code beading | Decomposing work and memory into small, persistent, linked units with acceptance criteria. | A recognized universal technical standard. |
| Model ecology | A managed population of specialists and shared services. | A literal ecosystem with intrinsic drives. |
| Operational 4Fs | Fast, Flexible, Frugal, Federated. | The biological Four Fs. |
| Evolutionary 4Fs | Feed, Fork, Fight, Flee. | Unbounded competition or self-preservation. |
| Teleodynamic controller | A resource-aware, two-timescale structural control loop. | Conscious purpose or independent moral status. |
| Fitness | An evaluation vector or governed aggregate score. | A single accuracy metric. |
| Lineage | Immutable parentage and transformation metadata. | Genetic identity. |
| No-op | Explicit decision not to change the system. | Failure to innovate. |
Code breeding versus code generation
Code generation produces a candidate implementation. Code breeding adds population, inheritance, mutation operators, independent evaluation, selection, and lineage. A one-off generated patch is not a breeding system. The distinction matters because population-based search can exploit weak tests more aggressively than ordinary development.
Code beading versus model modularity
Code beading concerns persistent work decomposition and agent memory: small issues, dependencies, acceptance criteria, and handoff state. Model modularity concerns deployable capability packages. They can support each other—an experiment can be decomposed into beads—but they are not the same architecture.
Specialist, expert, module, and bead
Use specialist model for an independently versioned model with a narrow capability. Use expert when referring to a component inside a mixture-of-experts architecture. Use module for a general composable software or model component. Use bead only when emphasizing a small linked unit of work, memory, or capability in the site's conceptual framework.
Fitness, viability, and utility
- Utility measures task value or business outcome.
- Fitness is the evidence used to compare candidates under a defined environment.
- Viability is system-level fitness after subtracting lifecycle costs and enforcing hard constraints.
A candidate can improve utility while reducing viability—for example, a 1% accuracy gain that doubles latency, introduces an unlicensed dataset, and removes rollback compatibility.
viability <- utility_gain
+ robustness_gain
+ diversity_gain
+ coverage_gain
- memory_cost
- latency_cost
- energy_cost
- risk_cost
- maintenance_cost
IF any_hard_invariant_fails
viability <- REJECTED
END IFSource 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.