Defines the concrete state, fast/slow loops, resource lanes, candidate actions, no-op semantics, traces, phase criteria, and falsification needed beyond ordinary routing.
Implementation evidence: this topic is grounded in the reviewed GGUF.MiRust.com source snapshot. It documents observed code and artifacts without claiming broad deployment, model quality, or production readiness.
State
A practical controller should separate current module structure H, trainable or adaptive parameters θ, endogenous resource state E, and trajectory τ. In an inference-first browser runtime, H can be the active module graph and θ can initially be router/adaptation parameters rather than base weights.
Fast loop
Route a request, execute bounded modules, measure result quality proxies and actual resource use, update short-lived confidence/state, and return output.
Slow loop
Periodically evaluate structural candidates: activate, deactivate, replace, reserve, merge compatible roles, split an overloaded role, retire, or no-op.
Resource lanes
- Resident memory and cache quota.
- Latency and UI responsiveness.
- Energy/thermal proxy where measurable without invasive fingerprinting.
- Uncertainty and error rate.
- Governance/review burden.
V(a) = expected task benefit
- memory cost
- latency cost
- uncertainty cost
- governance costNo-op
No-op must be an explicit candidate with a reason code. It wins when no affordable action exceeds the improvement threshold. A hard memory guard or timeout alone is not emergent halt.
Falsification
Compare against fixed routing, random activation, cost-only pruning, and externally scheduled growth. Publish phase criteria and traces that could show the claimed Teleodynamic behavior is absent.
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?