Governed mutation boundaries

The central boundary

A breeding system must distinguish the artifact being evolved from the system that judges it. The model may propose descendants, but it must not edit the evaluator, policy, holdout data, promotion threshold, or release alias.

This boundary prevents the self-referential validation loop: optimizing the test instead of the task. It is the difference between adaptive engineering and metric capture.

Permission domains

Sandbox pattern

PROCEDURE evaluate_candidate(candidate_id, suite_id)
    candidate <- REGISTRY_FETCH_IMMUTABLE(candidate_id)
    suite <- EVALUATION_REGISTRY_FETCH_IMMUTABLE(suite_id)

    sandbox <- CREATE_SANDBOX(
        network = "disabled",
        writable_paths = ["/tmp/eval-output"],
        readable_paths = [candidate.path, suite.public_inputs],
        secrets = []
    )

    result <- RUN_EVALUATION(sandbox, candidate, suite)
    signed_result <- SIGN_EVALUATOR_OUTPUT(result)
    APPEND_SCORECARD(candidate_id, suite_id, signed_result)
END PROCEDURE

Human review triggers

Require explicit owner approval when a change touches evaluator logic, security invariants, authority boundaries, data-retention policy, release automation, or any model that can affect high-risk decisions. Candidate generation can be automated; authority expansion cannot.

Red flags

• A candidate needs access to hidden labels.
• A model requests permission to change its acceptance criteria.
• A router learns only from accepted outputs and starves minority specialists.
• A release controller lacks rollback to an immutable previous version.
• Evaluation data and training data share a writable store.

Practical starting rule

Separate directories, credentials, and class responsibilities even in a single-process prototype. Physical separation can come later; logical separation should exist from the first experiment.