Viability controller

The controller decides structure, not truth

The viability controller consumes evidence cards and resource state, then proposes actions such as promote, keep, merge, compress, quarantine, retire, or no-op. It does not generate benchmark labels, alter hard policy, or execute arbitrary code.

Decision inputs

• candidate versus champion performance deltas;
• confidence intervals and slice results;
• contribution to behavioral diversity and task coverage;
• memory, latency, energy, bandwidth, and storage deltas;
• security, privacy, license, and data-lineage risk;
• operational complexity, dependencies, and on-call burden;
• current resource reserve and upcoming commitments;
• stability history and recent structural changes.

Hard policy first

FUNCTION decide(evidence, ledger, policy)
    IF NOT evidence.hard_invariants_pass
        RETURN QUARANTINE(evidence.candidate_id)
    END IF

    IF evidence.requires_permission_expansion
        RETURN REQUIRE_SEPARATE_GOVERNANCE_REVIEW
    END IF

    score <- WEIGHTED_VIABILITY(evidence, policy.weights)
    reserve_after <- PROJECT_RESERVE(ledger, evidence.lifecycle_cost)

    IF reserve_after < policy.minimum_reserve
        RETURN NO_OP("insufficient reserve")
    END IF

    IF score <= policy.change_threshold
        RETURN NO_OP("no material net gain")
    END IF

    RETURN PROPOSE_SHADOW_RELEASE(evidence.candidate_id)
END FUNCTION

Actions beyond promotion

A useful controller can choose to keep a candidate in the archive because it expands diversity but is not currently economical. It can merge two redundant specialists through a new experiment, lower traffic to an unstable model, or retire a component whose niche disappeared.

Hysteresis and cooldowns

Prevent oscillation by using different thresholds for adding and removing capacity, minimum observation windows, and cooldown periods after structural change. Escalate repeated reversals to human review.

Explainable decisions

Each decision record should state:

• eligible actions considered;
• hard constraints applied;
• score components and weights;
• uncertainty and missing evidence;
• resource projection before and after;
• chosen action and rejected alternatives;
• required approvals and rollback target.

Controller failure modes

A controller can overvalue easy-to-measure metrics, concentrate resources on incumbents, ignore long-term diversity, or create complexity through many small “wins.” Audit cumulative effects, not only per-action scores. Set population, dependency, and maintenance ceilings independent of candidate quality.