Foundations Intermediate 2 minute read Updated 2026-06-26 UTC

The teleodynamic budget

A practical way to turn viability theory into resource ledgers, thresholds, and no-op decisions.

Research statusConceptual synthesis from teleodynamic reports Publication statePublished Reviewed byMichael Kappel Source reports3

Definition

A teleodynamic budget is the controlled resource account that determines whether an adaptive structure may change. It converts the broad idea that a system should maintain itself under constraints into concrete engineering checks.

The budget is not only money. It includes memory, latency, energy, engineering attention, evaluation time, safety risk, licensing exposure, user trust, and rollback complexity. A candidate can improve accuracy and still lose if it consumes too much of these reserves.

Budget accounts

AccountMeasured asTypical limit
Memoryloaded model bytes, peak RAMdevice or container ceiling
Latencyp50, p95, p99 route timeproduct SLO
Energyjoules, GPU seconds, battery drainedge/cloud budget
Riskpolicy tier, data sensitivity, license flagsgovernance threshold
Maintenancedependencies, owners, test burdenteam capacity
Diversitynon-overlap with existing specialistsminimum useful variety
Utilitytask gain, calibration, coveragerelease threshold

No-op is active control

The budget makes no-op a positive action. The controller records that change was considered and rejected because evidence did not justify structural cost. This prevents hidden pressure to deploy every generated candidate.

pseudocode
FUNCTION teleodynamic_decision(candidate, baseline, budget, policy)
    delta <- COMPARE(candidate.scorecard, baseline.scorecard)

    benefit <- delta.utility
             + policy.robustness_weight * delta.robustness
             + policy.diversity_weight * delta.diversity
             + policy.coverage_weight * delta.coverage

    cost <- policy.memory_weight * delta.memory
          + policy.latency_weight * delta.latency
          + policy.energy_weight * delta.energy
          + policy.risk_weight * delta.risk
          + policy.maintenance_weight * delta.maintenance

    net <- benefit - cost

    IF candidate.hard_invariants_failed
        RETURN REJECT("hard invariant failure", net)
    IF budget.remaining_after(candidate) < policy.reserve_floor
        RETURN NOOP("reserve floor would be breached", net)
    IF net <= policy.viability_threshold
        RETURN NOOP("net viability below threshold", net)

    RETURN APPROVE_FOR_SHADOW(candidate, net)
END FUNCTION

Budget failure signs

A system is over-structured when route latency rises, many modules are rarely used, evaluators cannot keep pace with candidate generation, or engineers cannot explain why active models remain active. The cure is not another specialist. The cure is Flee: retirement, consolidation, quantization, or no-op.

Implementation note

Keep the first budget simple. Start with memory, latency, task score, and hard safety invariants. Add energy, maintenance, and diversity once the release process is stable.

Source reports used for this guide

These reports are preserved verbatim in the site archive. The guide above is an editorial synthesis and may narrow, qualify, or reorganize claims from the source material.