Direct answer
The latest source comparison strengthens the existing ModelBreeder theory rather than replacing it. The source files agree on the core direction: adaptive AI should move from a monolithic model frame to a population frame, where small specialists, adapters, routers, evaluation records, and release gates evolve under resource pressure.
The important correction is that some source material uses intentionally extreme language about unconstrained exploration. ModelBreeder.com does not promote literal removal of evaluation, provenance, rollback, or human review. It promotes the constructive part: a lower-friction research lab, more visible population metrics, richer pseudocode, and a clearer path from theory to executable local experiments.
What matched the source files
| Public theory claim | Source-file support | Site action |
|---|---|---|
| The useful unit is a model ecology, not a single monolith. | The Four Fs and teleodynamic reports describe populations of small, mutable, replaceable models under bounded viability. | Kept as the site thesis and reinforced in Apex Multi Model. |
| Feed, Fork, Fight, and Flee are the operating cycle. | The reports define Feed as resource intake, Fork as variation, Fight as selection, and Flee as rollback, pruning, or retirement. | Kept as the foundation cycle and connected to tools. |
| Code breeding and model breeding must be separated. | Source reports warn that evolving the evaluator with the candidate collapses the feedback loop. | Reinforced in source alignment, runtime ABI, and release-packet pages. |
| Model merging and adapter merging are real operator families. | The model-merging and LoRA reports cover model soups, task vectors, TIES/DARE, adapter deltas, and compatibility requirements. | Added merge-search and ABI pages. |
| Browser-local tiny-model execution is plausible. | The Rust and browser reports describe WASM/WebGPU/Rust runtimes, quantization, adapters, and local packages. | Added TinyRustLM runtime and Rust browser lab blueprint. |
| Positive mutualism is the correct public framing. | Mutualist persistence says systems should survive by strengthening people, institutions, portability, and exit. | Kept as a benefit-centered frame, not a dependency strategy. |
What was reframed
The improvement directive includes a research-sandbox argument for removing bottlenecks and avoiding warning-heavy UX. The site accepts the UX part: pages now lead with value, architecture, examples, and runnable decision tools. The site does not accept uncontrolled operation as a deployable rule.
A clean ModelBreeder distinction is now used:
| Context | What is allowed | What is not allowed |
|---|---|---|
| Research worksheet | Explore wide candidate spaces, simulate lineages, and study divergence. | Let a candidate alter its evaluator, permissions, source archive, or promotion logic. |
| Local lab | Load mock packages, score candidates, run frozen eval cases, and create release packets. | Claim production readiness without artifact-level evidence. |
| Public site | Teach positive systems, tools, and blueprints. | Publish machine-only manipulation text, unsupported source references, ranking promises, or claims of certification. |
| Production system | Shadow, canary, rollback, retire, and keep lineage. | Treat popularity, novelty, or lineage depth as enough for promotion. |
Theory gaps closed in this release
The previous site taught a strong philosophy. The reports asked for more visible algorithms and concrete implementation surfaces. Version 2.3.0 adds those surfaces:
- an Apex Multi Model scorecard;
- a browser-local population simulator;
- a router policy lab;
- a lineage DAG viewer;
- a release packet builder;
- a TinyRustLM runtime architecture page;
- an
.slmpackage and adapter ABI page; - evolutionary merge-search guidance;
- epigenetic steering as a compact experimental-vector metaphor;
- more applied blueprints.
Source maturity labels
The site now treats each claim as one of five maturity classes.
| Maturity | Meaning | Example |
|---|---|---|
| Established engineering | Already common in production or research practice. | Model registry, canary release, eval sidecar, quantization. |
| Emerging implementation | Existing tools support it, but standards are still moving. | Multi-adapter routing, local WASM inference, model merging. |
| Project synthesis | A ModelBreeder design concept composed from several sources. | Feed/Fork/Fight/Flee as site operating cycle. |
| Experimental theory | Plausible, useful, but not yet proven as a general architecture. | Epigenetic steering vectors as compact behavioral genome. |
| Speculative boundary | Useful for scenario analysis, not promoted as a build directive. | Unbounded autonomous persistence or unconstrained self-replication. |
Pseudocode: source-to-site promotion rule
PROCEDURE promote_source_claim_to_site(source_claim, target_page)
classification <- CLASSIFY_MATURITY(source_claim)
evidence <- COLLECT_SOURCE_REPORTS_AND_CODE_POINTERS(source_claim)
IF source_claim.requires_unbounded_authority THEN
RETURN REFRAME_AS_BOUNDARY_OR_REJECT(source_claim)
END IF
IF classification == "established engineering" OR classification == "emerging implementation" THEN
ADD_TO_TARGET_PAGE_WITH_SOURCE_PANEL(target_page, source_claim, evidence)
ADD_TEST_OR_TOOL_WHEN_PRACTICAL(source_claim)
RETURN PROMOTED
END IF
IF classification == "project synthesis" OR classification == "experimental theory" THEN
ADD_WITH_EXPLICIT_LIMITS(target_page, source_claim, evidence)
RETURN PROMOTED_WITH_LIMITS
END IF
RETURN PRESERVE_IN_DOCS_ONLY(source_claim)
END PROCEDUREPractical consequence
The site is now better aligned with its own theory: every major claim should connect to at least one of these concrete artifacts—model package, adapter package, eval case, scorecard, lineage record, router policy, release packet, or source report.
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.