No-op and metastability

Change is not automatically progress

Evolutionary systems generate pressure to produce descendants. Without an explicit no-op action, the controller can select the least bad candidate even when every candidate reduces system viability. No-op makes the current ecology a real competitor in every selection round.

No-op acceptance rule

best_candidate <- ARG_MAX(candidates, net_viability)

IF best_candidate.net_viability <= change_threshold
    decision <- NO_OP
ELSE IF confidence_interval_crosses_zero(best_candidate.net_viability)
    decision <- NO_OP_AND_COLLECT_MORE_EVIDENCE
ELSE
    decision <- PROPOSE_RELEASE(best_candidate)
END IF

A positive point estimate is insufficient. Require a margin large enough to cover measurement uncertainty, operational disruption, and rollback cost.

Metastability

A metastable ecology has no admissible structural change that improves viability under the current task distribution, hardware, policy, and resource budget. It is stable for now, not permanently optimal. New evidence can reopen the search.

Metastability is desirable when:

• request distributions and error rates remain within expected bounds;
• specialists have clear niches and no material redundancy;
• resource use is inside budgets with reserve capacity;
• challengers fail to produce statistically and operationally meaningful gains;
• safety and calibration remain stable under perturbation;
• the system can still adapt when a controlled trigger occurs.

Stagnation

Stagnation looks similar but results from a broken search process. Warning signs include no candidate diversity, an outdated evaluation suite, a router that starves challengers of evidence, mutation rates that are too low, or a policy budget that makes every useful experiment impossible.

Oscillation

Repeated add–remove or promote–rollback cycles indicate an unstable controller, a shifting workload, or inconsistent evaluation. Apply hysteresis: promotion and retirement thresholds should differ, and structural changes should have minimum observation windows.

IF recently_changed(capability)
    REQUIRE stronger_evidence_for_next_change
END IF

promote_when score > +PROMOTION_MARGIN
retire_when score < -RETIREMENT_MARGIN
otherwise KEEP_CURRENT_STATE

Triggering a new cycle

Resume structural search when a monitored condition changes materially: task drift, new failure clusters, hardware changes, cost shocks, revoked data, security incidents, or a new capability requirement. Record the trigger so later analysis can distinguish purposeful adaptation from continuous churn.