Answer first
The first ModelBreeder workbench should run in the browser, use local files, and teach the full breeding cycle without requiring a cloud service. The site can start with deterministic simulations and later attach real .slm packages, adapter deltas, and WASM runtime diagnostics.
Components
| Component | Role |
|---|---|
| File-backed registry | Stores model cards, Genome records, FitnessVector records, and release packets. |
| Browser dashboard | Shows population state, fitness trends, novelty, lineage, and next actions. |
| WASM runtime bridge | Loads tiny model packages and adapter deltas when the lab graduates from simulation. |
| Manifest verifier | Confirms artifact digests, tokenizer identity, tensor layout, and adapter compatibility. |
| Release packet builder | Converts evidence into a copyable promotion record. |
Why browser-local matters
The source reports emphasize edge compute, privacy, low latency, and local sovereignty. A browser-local workbench teaches those principles by design: no database, no cloud requirement, and no third-party scripts. The user can inspect the artifacts directly and understand how a population changes over time.
PROCEDURE open_workbench(local_folder)
registry <- LOAD_MANIFESTS(local_folder)
dashboard <- RENDER_POPULATION(registry.population)
IF wasm_runtime_available THEN
runtime <- LOAD_RUNTIME()
VERIFY_MODEL_PACKAGES(registry.models)
END IF
ENABLE_LOCAL_EXPERIMENTS(dashboard, registry)
END PROCEDURESource 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.