Theory Advanced 2 minute read Updated 2026-06-26 UTC

Resource closure

A practical interpretation of teleodynamic resource closure using budgets, ledgers, credits, and stop conditions.

Research statusConceptual synthesis Publication statePublished Reviewed byMichael Kappel Source reports3

Meaning of closure

In the ModelBreeder context, resource closure means the ecology must account for the resources that allow it to keep functioning. It does not mean the system is physically closed or biologically alive. It means the controller refuses structural actions that cannot be paid for by expected gains under known budgets.

The resource ledger is the practical device that makes this possible.

Ledger dimensions

Ledger accountExamplesCommon failure when ignored
Runtime memoryresident weights, adapters, caches, tokenizer stateout-of-memory failures and paging
Latencyrouting, model load, inference, judge passslow user experience and queue collapse
Compute and energyGPU time, CPU time, battery, thermal envelopeunsustainable cost or throttling
Evaluation capacitybenchmark runs, red-team effort, human reviewweak evidence and promotion errors
Operational attentionincidents, ownership, documentation, retrainingunmaintained descendants
Risk budgetpermissions, provenance, security exposureunsafe or illegal deployment

Credits are not currency

A viability credit is an accounting metaphor. It represents measured net benefit that can justify an added burden. Credits should not be transferable across unrelated safety domains. A large utility gain does not buy permission to ignore a legal or safety gate.

pseudocode
FUNCTION spend_resource_budget(action, ledger, policy)
    projected <- PROJECT_LEDGER_AFTER(action, ledger)

    FOR account IN projected.accounts
        IF account.value > policy.max_allowed[account.name]
            RETURN DENY("Budget exceeded: " + account.name)
        END IF
    END FOR

    IF action.expected_viability < policy.minimum_margin
        RETURN DENY("Action does not repay its burden")
    END IF

    RETURN APPROVE_WITH_LEDGER_RESERVATION(action)
END FUNCTION

The no-op as thermodynamic hygiene

A no-op is the default action when growth does not repay cost. It prevents the ecology from treating novelty as value. In implementation, no-op decisions should be logged with the rejected alternatives because those records teach future controllers what did not work.

Resource closure at different scales

For browser or edge systems, closure is dominated by memory, battery, bandwidth, and local privacy. For cloud systems, closure is dominated by GPU cost, queueing, security, and fleet reliability. For research labs, closure is dominated by evaluation quality and human review attention. The same theory applies, but the weights differ.

Practical ledger file

In a no-database PHP site or early lab, a ledger can be a signed append-only file. Later it can move into a database, but the semantics should stay the same.

pseudocode
RECORD LedgerEntry
    entry_id
    created_at_utc
    action_id
    candidate_digest
    memory_delta
    latency_delta
    compute_delta
    risk_delta
    evaluator_version
    decision
    approver
    signature
END RECORD

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.