Fixed model versus evolving structure
Parameter adaptation changes values inside a fixed hypothesis class. Structural adaptation changes the class or runtime arrangement itself: routes, components, rules, tool plans, memory projections, verifiers, or topology. The latter changes what the system can do and therefore requires explicit authority, cost, rollback, and evidence. Source: Teleodynamic Learning
Conceptual state model
θ(t) — parameters or continuously adapted state
S(t) — discrete runtime or model structure
R(t) — resource or viability budget
E(t) — evidence and observed performance
P — immutable external policy boundaryThis is MiRuntime conceptual notation. It does not claim that every cited framework uses the same symbols or equations.
Two-timescale loop
Fast loop
Adapt within the current structure
Observe → update parameters or context → evaluate → continue.
Slow loop
Propose a structural change
Detect persistent deficiency → propose edit → estimate benefit and cost → validate policy → approve if required → checkpoint → apply or choose no-op → record evidence.
Structural edit operators
| Operator | Preconditions | Expected benefit | Expected cost | Authority | Recovery and evidence |
|---|---|---|---|---|---|
| Add | Persistent capability gap; bounded candidate | New strategy or verifier | Latency, maintenance, attack surface | Approval unless pre-authorized | Checkpoint, component version, evaluation result |
| Split | One branch conflates distinct cases | Better specialization | More routes and tests | Proposal-only by default | Before/after topology and ablation |
| Merge | Branches are redundant | Lower cost and complexity | Possible loss of specialization | Bounded maintenance authority | Compatibility test and rollback pointer |
| Reroute | Capability or placement mismatch | Improved fit or resilience | Provider variance and cost | Policy-approved route set | Route reason, model version, usage |
| Retire | Component is obsolete or harmful | Reduced risk and maintenance | Migration and compatibility work | Approval for shared capability | Dependents, deprecation window, restore plan |
| Rollback | Applied change failed validation | Return to known state | Lost work and compensation | Recovery coordinator | Checkpoint hashes and residual effects |
| No-op | No justified edit | Preserve stable operation | Opportunity cost | Always available | Decision reason and supporting measurements |
Why no-op matters
no-op is valid when evidence is weak, expected benefit does not exceed cost, policy blocks the change, the runtime is stable, or added complexity cannot be maintained. It is a controlled decision, not proof of wisdom, desire, or self-awareness.
Comparison
| Approach | Structure changes | Resource variable | Stopping rule | Authority boundary | Maturity | Evidence need |
|---|---|---|---|---|---|---|
| Fixed-objective optimization | No | External budget | Configured criterion | Training system | Production practice | Training and evaluation record |
| Neural architecture search | Yes, usually offline | Search budget | Search criterion | Experiment owner | Established research | Search space, trials, compute |
| Continual learning | Usually parameter or memory | Often external | Task stream | Deployment policy | Active research | Forgetting and drift tests |
| Active inference | Model-dependent | Variational objective | Belief/action convergence | Controller design | Research and niche practice | Generative model and assumptions |
| Agent reflection | Plan or prompt changes | Step/token budget | Critic or limit | Runtime policy | Emerging practice | Critic trace and outcome |
| Workflow recovery | Route/state changes | Retry/time budget | Terminal state | State machine | Production practice | Events, checkpoint, effects |
| Teleodynamic profile | Bounded proposals | Multi-dimensional viability | Cost, stability, policy, no-op | External policy and approvals | Research proposal | Full proposal-to-outcome package |
Evidence and benchmark requirements
No performance claim should appear without a verified primary source, task and dataset, baseline, hardware/software environment, repeated trials for stochastic behavior, source-review date, and limitation statement. Runtime adaptations additionally need the proposed edit, estimated cost and benefit, authority decision, checkpoint, applied diff, measured result, and rollback status.
Source record
References
Enrique ter Horst and Juan Diego Zambrano. arXiv. Published 2026-03-11; last reviewed 2026-06-24 UTC. Research preprint.
Charlie Snell, Jaehoon Lee, Kelvin Xu, and Aviral Kumar. arXiv / ICLR. Published 2024-08; last reviewed 2026-06-20 UTC. Research paper.
Shunyu Yao et al.. arXiv / NeurIPS. Published 2023-05; last reviewed 2026-06-20 UTC. Research paper.
Christopher Cruz. arXiv. Published 2025-12; last reviewed 2026-06-20 UTC. Research paper.
- The free-energy principle: a unified brain theory? Primary source
Karl Friston. Nature Reviews Neuroscience. Published 2010; last reviewed 2026-06-24 UTC. Peer-reviewed review paper.