Reference architecture

Direct answer

A practical ModelBreeder system has two separated paths: a request path that routes work to safe model specialists, and an evolution path that creates, evaluates, and releases descendants. The request path must not be able to rewrite the evaluator, registry policy, or release gates.

System overview

The reference architecture supports two distinct paths: the request path, which answers user or system tasks, and the evolution path, which changes the model population. They share telemetry and registry data but have different permissions and latency expectations.

Request path

1. A gateway validates the request contract, identity, jurisdiction, and risk tier.
2. The router filters models by capability, compatibility, permissions, and current resource budget.
3. One specialist, a cascade, or a small coalition runs in isolated execution contexts.
4. A judge or deterministic validator checks candidate outputs when the task requires it.
5. The response includes a trace identifier, selected lineage, confidence, and policy decision.
6. Telemetry is appended to the evidence stream after sensitive fields are minimized.

Evolution path

1. Evidence curation identifies failure clusters, cost pressure, drift, or new capability demand.
2. The candidate factory executes an allowlisted mutation operator against signed parents.
3. Candidates are packaged immutably and registered as candidate artifacts.
4. Independent evaluation runs task, robustness, safety, and resource suites.
5. The viability controller compares candidates with the current ecology and no-op.
6. Approved candidates enter shadow, canary, progressive, and champion stages.
7. Lineage, approvals, deployment evidence, and rollback targets are appended throughout.

Core components

Data boundaries

Separate content data, training data, evaluation data, operational telemetry, and governance data. A model that can see hidden holdout labels can optimize them. A model that can write governance data can alter its own constraints. Use distinct credentials, storage locations, encryption keys, and audit streams.

Failure containment

Every runtime invocation has a deadline, memory ceiling, network policy, tool allowlist, and output-size limit. Coalition fan-out is capped. When the judge is unavailable, the system either uses a pre-approved direct path or fails closed according to task risk; it does not silently bypass evaluation.

Reference request algorithm

FUNCTION handle_request(request)
    context <- GATEWAY_VALIDATE_AND_CLASSIFY(request)
    eligible <- REGISTRY_QUERY(
        capability = context.capability,
        contract = context.contract_version,
        jurisdiction = context.jurisdiction,
        risk_tier = context.risk_tier
    )

    route <- ROUTER_PLAN(eligible, context, RESOURCE_LEDGER.current())
    outputs <- EXECUTE_PLAN_IN_ISOLATION(route, context)
    verdict <- APPLY_REQUIRED_GATES(outputs, context)

    IF verdict.accepted
        result <- ASSEMBLE_RESPONSE(verdict.selected_output)
    ELSE
        result <- EXECUTE_APPROVED_FALLBACK(context, verdict)
    END IF

    APPEND_TRACE(context, route, outputs, verdict, result)
    RETURN result
END FUNCTION

Start smaller than the diagram

A first implementation can collapse several components into one process while preserving logical boundaries. Use separate classes, credentials, directories, and immutable records even if they run on one host. Physical distribution can follow when scale or trust requires it.