Open-endedness and its limits

Open-ended is not unbounded

Open-ended evolution studies sustained novelty and expanding capability rather than convergence on one fixed optimum. In operational systems, open-endedness must remain inside bounded environments, permissions, resources, and review. Removing the endpoint does not remove responsibility.

Research questions

• Can a population continue producing useful, non-redundant specialists under a fixed resource budget?
• Does diversity improve recovery after task drift?
• Can the system create new niches without overfitting arbitrary descriptors?
• How does lineage depth affect robustness and reproducibility?
• When does the evaluator become the limiting factor?
• Can novelty remain understandable and useful to human operators?

Bounded open-ended experiment

experiment_limits <- {
    isolated_environment: true,
    network_access: NONE,
    max_wall_clock_days: 7,
    max_compute_budget: FIXED,
    max_population: 500,
    max_artifact_storage: 2_TB,
    allowed_action_space: SIMULATION_ONLY,
    human_review_interval_hours: 12,
    emergency_stop: EXTERNAL_AND_TESTED
}

Novelty criteria

Measure sustained behavior-space expansion, useful niche coverage, non-repeating innovations, and human learnability. Do not reward raw complexity, file size, or unusual text. Novelty must satisfy validity and safety constraints.

Risks

Open-ended systems can exploit evaluator blind spots, accumulate opaque complexity, consume resources, or create artifacts that operators cannot interpret. Coevolution can produce arms races disconnected from the intended task. Long runs can make provenance and incident response difficult.

Containment

Use simulation, no external credentials, immutable snapshots, bounded action spaces, rate limits, periodic review, and reproducible checkpoints. The emergency stop remains outside the evolving system and is exercised before the run.

Production boundary

A production model-breeding program can be continual without being open-ended. It can repeatedly respond to explicit triggers, use allowlisted operators, and choose no-op. That approach is appropriate for most enterprise systems. Open-ended evolution belongs in a research lab until its evaluation and governance problems are better understood.