The five pillars
ModelBreeder.com uses five pillars to keep the concept practical and positive. Each pillar turns the breeding metaphor into an engineering question.
| Pillar | Simple definition | Engineering meaning | Example | Design question |
|---|---|---|---|---|
| Compounding | Useful descendants become reusable parents. | Successful adapters, fine-tunes, merges, routes, and evidence records are preserved as starting points. | A legal summarizer specialist becomes the parent for a citation-checking descendant. | What improvement should be preserved so the next generation starts ahead? |
| Local-first | Private work can stay on controlled hardware. | Browser, edge, workstation, and organization-local execution are first-class deployment targets. | A personal knowledge model processes notes before any external API is considered. | Which tasks can run locally with acceptable quality and latency? |
| Frugal | Small specialists handle common tasks efficiently. | Budget-aware routing avoids using a large generalist for every repeated operation. | A tiny classifier routes documents before a stronger model drafts summaries. | What is the smallest capable model for this request class? |
| Generative | Human skill becomes durable capability. | Feedback, examples, corrections, style preferences, and review decisions become reusable training or evaluation material. | A team’s code-review comments become a local review-specialist dataset. | Which human judgment should become reusable evidence? |
| Mutualist | The ecology earns continuity through benefit. | The system persists because it strengthens people, teams, products, and local systems. | An education tutor helps learners understand, not merely outsource answers. | How does this ecology leave users more capable? |
Why these pillars matter
The pillars prevent model breeding from becoming vague automation. They keep the system grounded in useful work: stronger local workflows, better evidence, less compute waste, clearer lineage, and reusable improvements. A descendant does not need to be larger to matter. It needs to earn a place under a declared budget.
Practical checklist
PROCEDURE review_pillars(candidate)
CHECK candidate.creates_reusable_parentage
CHECK candidate.can_run_locally_or_explains_why_not
CHECK candidate.uses_smallest_capable_model
CHECK candidate_preserves_human_judgment_as_evidence
CHECK candidate_strengthens_people_or_products
RETURN PILLAR_SCORECARD(candidate)
END PROCEDUREContinue with the core model-breeding loop and adaptive model ecologies.
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.
Implementation directivesModelBreeder v2.7.0 Positive Exploration DirectiveCurrent operating directive · 35.8 KB
Architecture and project resourcesModelBreeder Architecture and ProjectsSource report · 53.0 KB
Architecture and project resourcesModelBreeder Architecture and ResourcesSource report · 50.9 KB
Architecture and project resourcesModelBreeder Architecture and Resources Part 2Source report · 33.5 KB
Evolution lab and dashboardsExploring Ecology Dashboard ArchitectureSource report · 64.7 KB
Architecture and model mergingModel Breeder Architecture Deep DiveSource report · 76.7 KB
Architecture and runtime explorationModelBreeder Architecture ExplorationSource report · 48.9 KB