Audits reward, decay, structural cost, initial energy, clipping, saturation, system-death behavior, and the conditions under which the source model can accumulate unbounded energy.
Research documentation: this page interprets a cited research source and defines evidence requirements. It does not claim a released Teleodynamic AI implementation.
Source equation and reported DE11 configuration
The reviewed preprint defines the resource transition as E(t+1) = γE · E(t) + δE(t) − c_a(t). Its reported DE11 default uses no decay (γE = 1), reward +10 for a correct prediction, penalty −10 for an incorrect prediction, and structural costs of 5 for genesis and 8 for wedge; parameter updates are reported as free. These are author-reported configuration values, not MiRust recommendations.
Write the implementation contract explicitly
For every event, retain resource before the action, reward or replenishment, decay, penalties, structural and parametric costs, clipping, saturation, numerical precision, update ordering, and resource after the action. A generic template such as E′ = clip(ρE + r − c, E_min, E_max) is only an engineering example; the implementation must publish its actual rule and units.
Boundedness is a property to prove or test
The source states that when decay is one and expected net reward is positive, energy is unbounded above. A browser controller therefore needs a declared finite-horizon interpretation, normalization, saturation, spillover, or decay policy before “resource-bounded” is used as a factual description.
Death, dormancy, and restart
The paper describes E ≤ 0 as “system death,” clearing hypotheses and restarting from void. An engineering implementation should replace metaphor with explicit lifecycle semantics: reject structural actions, enter recoverable dormancy, restore a checkpoint, start a successor run, or terminate. Process crashes and host-enforced shutdowns remain separate events.
Stress tests
- Long runs with sustained correct predictions.
- Long runs with adversarial, delayed, or noisy feedback.
- Reward-scale, action-cost, and decay sweeps.
- Initial-resource sensitivity and class imbalance.
- Clipping, overflow, underflow, and threshold-oscillation tests.
Scope
This starter page defines the questions, boundaries, evidence, and failure modes that should be recorded before a capability is presented as supported.
Engineering considerations
- Identify the source, version, target environment, and owner.
- Separate observed values from estimates and externally reported values.
- Record trade-offs, unsupported cases, and fallback behavior.
- Link performance statements to a compatible benchmark methodology.
Verification questions
- What exact artifact, revision, backend, and environment were reviewed?
- Which assumptions could change the result?
- Which data should be retained so another engineer can reproduce the conclusion?