Explains per-action evaluation of predictive loss, structural-complexity change, and resource consumption without claiming a globally optimized or convex objective.
Research documentation: this page interprets a cited research source and defines evidence requirements. It does not claim a released Teleodynamic AI implementation.
Per-action evaluation
The source defines a local structural-action score J_a = L(s′, x, y) + λc · ΔC + λe · ΔE. It is evaluated for the current event and candidate successor state. It is not a global training objective, a proof of global optimality, or a replacement for long-horizon evaluation.
Record each term
- Predictive-loss definition, calibration, and candidate successor state.
- Complexity metric, structural delta, and compressed versus expanded complexity.
- Resource cost, feasibility constraint, and units.
- Coefficients, normalization, and tie-breaking rule.
- Complete candidate set, selected action, and selection margin.
Source-direction inconsistency
The reviewed v1 text states that structural actions minimize J, and Proposition 4.5 defines freeze when noop is no worse than every structural alternative. Definition 2.4 also says noop is selected when its score “exceeds” the alternatives. Those statements point in opposite comparator directions. MiRust treats this as a wording inconsistency that an implementation must resolve through an explicit comparator, fixtures, and trace fields rather than silently inheriting.
Interpretation
The selected action is locally rational only under the declared state, candidate generator, objective, and comparator. It need not be globally optimal, and the final structure may depend on event order and initialization.
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?