Choose the smallest architecture that solves the actual problem
A breeding system does not require every evolutionary mechanism. Most successful first implementations use one constrained pattern: a cascade, a router over independent specialists, adapters on a shared base, or an offline champion–challenger factory. This worksheet ranks those patterns from explicit constraints.
Architecture pattern shortlist
Select the closest constraint in each category. The tool ranks patterns and shows the assumptions driving the result.
Complete the worksheet and rank patterns.
Pattern families
| Pattern | Strong fit | Main scope note |
|---|---|---|
| Deterministic cascade | Most cases are easy and confidence can be calibrated | Worst-case latency and error propagation |
| Router plus specialists | Clear niches, mixed cost tiers, independent contracts | Router drift and specialist starvation |
| Parallel ensemble | High consequence, valuable diversity, manageable traffic | Linear cost and correlated error |
| Shared base plus adapters | Many related skills, compatible backbone, limited memory | Adapter interference and base lock-in |
| Offline champion–challenger | Strong governance requirement, slower adaptation acceptable | Lower adaptation frequency |
| Federated adapter network | Data cannot move and sites share a compatible contract | Non-IID data, poisoning, privacy accounting |
| Edge–cloud hybrid | Local latency/privacy with approved escalation | Transfer policy and dual-runtime complexity |
| Weight-merge laboratory | Compatible parents and a clear research objective | Parameter interference and weak portability |
Selection discipline
The top-ranked pattern is a design hypothesis. Before implementation, write down why the next two patterns were rejected. This reduces accidental lock-in and makes future migration decisions easier.
PROCEDURE select_architecture(requirements)
candidates <- LOAD_PATTERN_CATALOG()
FOR each pattern IN candidates
pattern.score <- 0
pattern.score += FIT(pattern, requirements.latency)
pattern.score += FIT(pattern, requirements.privacy)
pattern.score += FIT(pattern, requirements.adaptation_rate)
pattern.score += FIT(pattern, requirements.model_compatibility)
pattern.score += FIT(pattern, requirements.operational_maturity)
pattern.score -= VIOLATIONS(pattern, requirements.hard_constraints)
END FOR
shortlist <- TOP_NON_VIOLATING(candidates, 3)
RETURN WITH_ASSUMPTIONS_AND_VALIDATION_TESTS(shortlist)
END PROCEDURERecommended default
For an enterprise team without an existing model-evolution platform, the safest default is an offline champion–challenger factory producing immutable descendants behind a fixed capability contract. Add a router only when workload niches are measured. Add federation only when data-locality requirements justify its operational and security cost. Add online structural adaptation last, if at all.
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.