Runtime-Aware Non-Ideality Adaptation

• Runtime-aware non-ideality adaptation is a class of methods that detect deviations from ideal operating conditions and adjust system configurations in real time.
• These techniques employ event-driven orchestration, model-based verification, and explicit runtime representations to manage faults and performance degradations.
• They are applied across domains such as robotics, streaming systems, LLM serving, and hardware-aware learning, enhancing both reliability and efficiency.

Runtime-aware non-ideality adaptation denotes a class of techniques that detect departures from ideal operating assumptions during execution—or, in hardware-aware learning, explicitly simulate the runtime departures expected after deployment—and adapt the active configuration, control policy, interface layer, or serving substrate accordingly. Across the cited literature, the relevant non-idealities include component failures, degradations, contingencies, workload burstiness, memory pressure, write variation, stuck-at-faults, environment-contract mismatches, trajectory degeneration, and actuator faults. The resulting adaptation mechanisms span event-driven orchestration, MAPE-K meta-control, probabilistic runtime verification, token-level precision switching, trajectory regulation, and verified runtime shielding (Bozhinoski et al., 2020, Su et al., 24 May 2025, Xu et al., 21 May 2026, Huai et al., 9 Jul 2026, Shojaei, 24 Jun 2026).

1. Conceptual scope and lineage

Early formulations treated runtime adaptation as an external control-plane concern rather than something embedded directly into application logic. In IBM System S, the orchestrator, also called ORCA, was introduced as a lightweight side-car process that lives alongside one or more streaming jobs, registers event scopes, receives event contexts, and invokes actuation APIs such as job submission, cancellation, process restart, or script execution (Jacques-Silva et al., 2012). In model-driven self-adaptive systems, adaptation logic was captured already at the requirements level through an Adaptation Goal Model, tagged sequence diagrams, and runtime verification over variable DTMC and CTMC models derived from those artifacts (Yang et al., 2017). In distributed network computing, a QoS middleware exposed an anonymous QoS API to tasks so that application-driven adaptation could react to resource variability and faults at runtime (Al-Hawari et al., 2019).

Subsequent work broadened both the domains and the meaning of “non-ideality.” In ROS-based robotics, MROS treated failures, degradations, and contingencies as ontology-level runtime entities linked to architectural variants and mission-quality concerns (Bozhinoski et al., 2020). In LLM serving, MorphServe reframed non-ideal conditions as token-granular workload burstiness and memory pressure, addressed through quantized layer swapping and pressure-aware KV-cache resizing (Su et al., 24 May 2025). In deterministic LLM agents, Life-Harness defined runtime non-idealities as mismatches at the boundary between a frozen LLM policy and a rule-governed environment, including action realization failures, environment contract mismatches, and trajectory degeneration (Xu et al., 21 May 2026). In ReRAM in-memory processing, CRIMP modeled write variation and stuck-at-faults as deployment-time device non-idealities and injected them during training so that the resulting models would be reliable at inference without extra hardware (Huai et al., 9 Jul 2026). In spacecraft autonomy, AMPLE-GNC combined a learned commander and fault-adaptive controller with a verified runtime shield and adaptation-aware engagement policy (Shojaei, 24 Jun 2026).

A concise cross-domain view is useful because the same high-level pattern recurs even when the adaptation target changes.

Setting	Non-ideality	Adaptation substrate
Stream processing	failures, built-in/custom metrics	ORCA event scopes and actuations
ROS robot control	Failure, Degradation, Contingency	DSLs, ontology, MAPE-K
LLM serving	workload burstiness, memory pressure	layer swapping, KV-cache resizing
Deterministic LLM agents	interface mismatches, trajectory degeneration	lifecycle-aware runtime harness
IMP accelerators	write variation, stuck-at-faults	non-ideality-injected training
Spacecraft GNC	actuator sign/gain faults	RMA plus runtime shield

This breadth suggests that runtime-aware non-ideality adaptation is less a single algorithm than a systems pattern: detect operational deviation, map it into a structured representation, and enact a bounded response that preserves the primary objective of the system under deployment constraints.

2. Observability and representation of non-idealities

A distinguishing feature of the literature is the use of explicit runtime representations rather than ad hoc exception handling. MROS defines an OWL-style ontology whose core classes include Component, Connector, Resource, Variant, Context, NonIdeality, QualityMetric, and AdaptationAction, with relations such as impacts(NonIdeality,QualityMetric) and resolves(AdaptationAction,NonIdeality) (Bozhinoski et al., 2020). Runtime observations arrive through distributed ROS-style monitors. Each component has a paired monitor node publishing on /health/<component>, and monitors emit a HealthEvent with fields {component_id, timestamp, status ∈ {OK,Degraded,Failed}. These events are lifted into ontology instances by a mapper, allowing reasoning layers to treat faults as semantic objects rather than raw telemetry. MROS also gives an explicit logical declaration of a soft fault over a window $\Delta t$:

$$\mathrm{SoftFault}(c)\;\equiv\;\sum_{i=1}^{n}\mathbf{1}_{\{\mathrm{health}_i=\mathrm{Degraded}\}}>k .$$

ORCA uses a different representational strategy. Instead of an ontology, it provides event scopes and event contexts. A subscope may specify, for example, operator-metric events for queueSize on operator types Split or Merge inside a given composite, or PE-failure events for a named application. Each delivered event is annotated with context such as PE-ID, operator instance, composite nesting, metric epoch, timestamp, or crash reason. The key abstraction is not semantic reasoning but precise event filtering plus enough logical and physical metadata to map the event back into the application structure (Jacques-Silva et al., 2012).

The QoS service for network computing similarly exposes runtime state through structured views. The application is modeled as an Application Task Graph $G=(T,M,L)$, while machine and task states are maintained through MachView, TaskView, PortView, LocalQoSData, and GlobalQoSData. Dynamic attributes include Workload, EffectiveSpeed, FreeRAM, FreeSwap, link throughput, and latency. The measured machine speed is explicitly defined as

$\mathit{EffectiveSpeed}_m= \begin{cases} 1\times \min_{\ell\in\text{CPUs}}(\mathit{CPUSpeed}_\ell), & \text{if }1+\mathit{Workload}_m\le \mathit{NumOfCPUs}_m,\[6pt] \dfrac{\mathit{NumOfCPUs}_m}{1+\mathit{Workload}_m}\times \min_{\ell}(\mathit{CPUSpeed}_\ell), & \text{o.w.} \end{cases}$

and machine failure is detected if two consecutive Unix ping calls fail (Al-Hawari et al., 2019).

Later systems pushed observability to finer granularity. MorphServe recomputes smoothed arrival and token rates at each generated token,

$$\mu_k=(1-\alpha)\mu_{k-1}+\alpha\lambda(t_k),\qquad \nu_k=(1-\alpha)\nu_{k-1}+\alpha\tau(t_k),$$

and detects a pressure event when either $U_{\mathrm{mem}}(k)>T_{\mathrm{mem}}$ or $\mathrm{queue\_delay}(k)>T_q$ (Su et al., 24 May 2025). Life-Harness observes not physical degradation but interface-level failure modes: action realization failures, environment contract mismatches, trajectory degeneration, and residual reasoning failures (Xu et al., 21 May 2026). CRIMP goes further by modeling the deployed hardware itself. Its write-variation model assumes target resistance $r_{ij}$ becomes

$$r'_{ij}=e^{\theta_{ij}}r_{ij},\qquad \theta_{ij}\sim N(0,\epsilon^2),$$

or, in conductance form, $c'_{ij}=e^{-\theta_{ij}}c_{ij}$, while stuck-at-faults are represented by random masks over a small fraction of cells (Huai et al., 9 Jul 2026).

The commonality across these representations is explicitness. Non-ideal conditions are elevated to first-class runtime objects, typed events, measurable resource views, or stochastic device models, which makes them amenable to adaptation logic rather than mere post hoc diagnosis.

3. Adaptation substrates and decision logic

Once non-idealities are represented explicitly, the adaptation problem becomes one of selection under constraints. MROS implements a MAPE-K loop extended with a meta-control planner. Candidate architectural variants are generated from ArchDSL, mission preferences are supplied by QLDSL, and each candidate variant $$\mathrm{SoftFault}(c)\;\equiv\;\sum_{i=1}^{n}\mathbf{1}_{\{\mathrm{health}_i=\mathrm{Degraded}\}}>k .$$0 in context $$\mathrm{SoftFault}(c)\;\equiv\;\sum_{i=1}^{n}\mathbf{1}_{\{\mathrm{health}_i=\mathrm{Degraded}\}}>k .$$1 is scored by

$$\mathrm{SoftFault}(c)\;\equiv\;\sum_{i=1}^{n}\mathbf{1}_{\{\mathrm{health}_i=\mathrm{Degraded}\}}>k .$$2

If a detected non-ideality impacts a soft or hard constraint, the planner enumerates candidate variants, computes $$\mathrm{SoftFault}(c)\;\equiv\;\sum_{i=1}^{n}\mathbf{1}_{\{\mathrm{health}_i=\mathrm{Degraded}\}}>k .$$3, and executes a swap when the best candidate exceeds the current score by a threshold, which is explicitly used to prevent thrashing (Bozhinoski et al., 2020).

ORCA embodies a more direct event-to-actuation style. Its logic module declares scopes at startup and then handles callbacks such as handleOperatorMetricEvent or handlePEFailureEvent. Adaptation actions include _orca->submitJob(appConfig), _orca->cancelJob(jobName), _orca->restartPE(peId), _orca->updateHostPool(jobName, exclusivePool=true), and _orca->invokeScript(...). The adaptation logic can therefore encode threshold-triggered recomputation, replica fail-over, or on-demand application composition without modifying the streaming dataflow graph itself (Jacques-Silva et al., 2012).

The QoS service adopts an application-driven formulation. Tasks query a local QoSService façade and implement their own policies. For fault tolerance, a manager checks peer task state before communicating and skips dead workers. For performance adaptation, the scheduler solves a load-balancing system using the measured workloads:

$$\mathrm{SoftFault}(c)\;\equiv\;\sum_{i=1}^{n}\mathbf{1}_{\{\mathrm{health}_i=\mathrm{Degraded}\}}>k .$$4

The paper specifies LU decomposition in $$\mathrm{SoftFault}(c)\;\equiv\;\sum_{i=1}^{n}\mathbf{1}_{\{\mathrm{health}_i=\mathrm{Degraded}\}}>k .$$5 for solving the resulting linear system (Al-Hawari et al., 2019).

A separate line of work formalizes adaptation as runtime verification over probabilistic models. The model-driven approach of Yang et al. transforms a tagged requirements model into an LTS, then into a variable DTMC for reliability and a rewarded variable CTMC for performance, and prunes the decision space by verifying PCTL and CSL properties such as $$\mathrm{SoftFault}(c)\;\equiv\;\sum_{i=1}^{n}\mathbf{1}_{\{\mathrm{health}_i=\mathrm{Degraded}\}}>k .$$6 or $$\mathrm{SoftFault}(c)\;\equiv\;\sum_{i=1}^{n}\mathbf{1}_{\{\mathrm{health}_i=\mathrm{Degraded}\}}>k .$$7 (Yang et al., 2017). Here adaptation candidates are literally the variable states of the stochastic models.

Life-Harness shifts the control locus from the model to the runtime mediator. The harness $$\mathrm{SoftFault}(c)\;\equiv\;\sum_{i=1}^{n}\mathbf{1}_{\{\mathrm{health}_i=\mathrm{Degraded}\}}>k .$$8 wraps a frozen agent $$\mathrm{SoftFault}(c)\;\equiv\;\sum_{i=1}^{n}\mathbf{1}_{\{\mathrm{health}_i=\mathrm{Degraded}\}}>k .$$9, evolves from training trajectories, and remains fixed during held-out evaluation. Its four layers are applied sequentially: environment contract enrichment, procedural skill retrieval, action realization, and trajectory regulation. Immediately before execution, the harness computes

$G=(T,M,L)$0

thus turning interface validation itself into an adaptation surface (Xu et al., 21 May 2026).

AMPLE-GNC combines learned and verified substrates. A learned commander maps natural language to PDDL+, a constraint-screening verifier checks feasibility, and a fault-adaptive controller uses online latent fault estimates $G=(T,M,L)$1 in

$G=(T,M,L)$2

Around these components sits a runtime shield with nine LTL invariants and a split-conformal recovery-deadline certificate, allowing adaptation-aware engagement rather than unconditional latching to safe-hold (Shojaei, 24 Jun 2026).

Taken together, these systems show that runtime-aware non-ideality adaptation is not committed to a single decision paradigm. It may be utility maximization, thresholded orchestration, view-based application logic, formal model checking, harness interposition, or verified shielding, provided that the adaptation target and admissible actions are defined precisely.

4. Granularity of adaptation across domains

The most informative distinction across the literature is the granularity at which adaptation occurs. Architectural adaptation is prominent in robotics. MROS models entire ROS control pipelines as variants, with inheritance, connectors, resources, and optional parameters, and switches among those variants in response to runtime failures or environmental contingencies (Bozhinoski et al., 2020). Stream-processing adaptation in ORCA is job- and operator-centric: applications are not recompiled, but runtime routines can redeploy subgraphs, restart failed processing elements, or dynamically compose jobs (Jacques-Silva et al., 2012).

Serving systems operate at much finer temporal granularity. MorphServe’s two mechanisms are explicitly asynchronous and token-level. Quantized layer swapping selectively replaces less impactful transformer layers with quantized replicas during high-load periods, while pressure-aware KV-cache resizing attaches or frees blocks asynchronously via cudaMallocAsync and cudaFreeAsync. Adaptation is initiated for token $G=(T,M,L)$3 onward if pressure is detected at token $G=(T,M,L)$4 (Su et al., 24 May 2025). The adaptation unit is therefore neither a whole service nor a whole model, but a layer-level precision choice synchronized to token boundaries.

Hardware-aware learning introduces a different kind of granularity. CRIMP does not insert a runtime controller into the deployed accelerator. Instead, each forward pass during training replaces the ideal crossbar MAC with a simulator that perturbs outputs according to sampled write variation, computes

$G=(T,M,L)$5

and trains on the perturbed output $G=(T,M,L)$6. The adaptation is “runtime-aware” because it is calibrated to actual deployed non-idealities, but it is absorbed into the learned parameters before deployment (Huai et al., 9 Jul 2026).

In deterministic LLM agents, the adaptation granularity is interactional rather than architectural. Life-Harness modifies the environment contract, prompt-time skill context, just-before-execution action realization, and just-after-execution trajectory regulation, but it does not change model weights or evaluation environments (Xu et al., 21 May 2026). This makes the runtime harness itself the primary adaptive object.

In spacecraft autonomy, AMPLE-GNC combines multiple granularities simultaneously: symbolic action generation, linearized resource screening, continuous control adaptation, and horizon-bounded runtime shielding. The shield’s invariants cover pointing angle, body rate, power, wheel momentum, thermal limits, propellant reserve, link budget, sunlit constraints, and an attitude-rate violation bound, with predictor soundness checked in Kind 2 (Shojaei, 24 Jun 2026).

This variation in granularity has a practical implication. A plausible implication is that the “right” adaptation locus depends less on the application domain than on where non-idealities first become observable and where corrective action can still be taken without unacceptable switching cost or verification burden.

5. Empirical effects and trade-offs

The reported results show that adaptation is typically evaluated against both effectiveness and overhead. In MROS, two ROS-based demonstrators—a TurtleBot-based indoor delivery system and a UR5 pick-and-place station—ran 100 missions under injected non-idealities including random sensor dropout, dynamically blocked corridors, and soft-fault oscillations in the planner. Reported successRate improved from 65% to 92%, recoveryTime from 18 s for static fallback to 4.3 s for MROS auto-reconfiguration, extensibility from 2 custom variants to 7 variants, and code reuse across two use cases from 1.2% to 48% (Bozhinoski et al., 2020).

For streaming and networked systems, the gains are similarly operational. ORCA’s financial trend calculator case study reports fast failover of at most one ORCA roundtrip plus the C++ handler, contrasted with 10 min to rebuild sliding windows if state were lost (Jacques-Silva et al., 2012). In the network QoS middleware, adaptive scheduling under heterogeneous load patterns produced speedups of approximately 25–47%, while the monitoring overhead was below 4% at monitoring periods of 30 s or 60 s and peaked at approximately 7–12% at a 5 s period (Al-Hawari et al., 2019).

MorphServe’s serving results are expressed in SLO and latency terms. Relative to full-precision serving, average SLO violations are reduced by 92.45%, P95 TTFT is improved by a factor of 2.2×–3.9×, and the saturation point shifts to approximately $G=(T,M,L)$7–$G=(T,M,L)$8. Static INT4 is reported to yield relative quality $G=(T,M,L)$9–$\mathit{EffectiveSpeed}_m= \begin{cases} 1\times \min_{\ell\in\text{CPUs}}(\mathit{CPUSpeed}_\ell), & \text{if }1+\mathit{Workload}_m\le \mathit{NumOfCPUs}_m,\[6pt] \dfrac{\mathit{NumOfCPUs}_m}{1+\mathit{Workload}_m}\times \min_{\ell}(\mathit{CPUSpeed}_\ell), & \text{o.w.} \end{cases}$0, but MorphServe confines this loss to a small fraction of tokens, producing end-to-end quality degradation of at most 3.8% and often below 1%; tail TPOT is reduced by up to 1.23× in performance mode (Su et al., 24 May 2025).

Life-Harness reports broad cross-model improvements on seven deterministic benchmarks from $\mathit{EffectiveSpeed}_m= \begin{cases} 1\times \min_{\ell\in\text{CPUs}}(\mathit{CPUSpeed}_\ell), & \text{if }1+\mathit{Workload}_m\le \mathit{NumOfCPUs}_m,\[6pt] \dfrac{\mathit{NumOfCPUs}_m}{1+\mathit{Workload}_m}\times \min_{\ell}(\mathit{CPUSpeed}_\ell), & \text{o.w.} \end{cases}$1-bench, $\mathit{EffectiveSpeed}_m= \begin{cases} 1\times \min_{\ell\in\text{CPUs}}(\mathit{CPUSpeed}_\ell), & \text{if }1+\mathit{Workload}_m\le \mathit{NumOfCPUs}_m,\[6pt] \dfrac{\mathit{NumOfCPUs}_m}{1+\mathit{Workload}_m}\times \min_{\ell}(\mathit{CPUSpeed}_\ell), & \text{o.w.} \end{cases}$2-bench, and AgentBench. The headline results are an average relative improvement of 88.5% and gains in 116 out of 126 model-environment settings across 18 model backbones. Averaged over 18 models, pass@1 gains are reported as +84% on ALFWorld, +40% on WebShop, +19% on OS, +34% on DBBench, +26% on Airline, +10% on Retail, and +25% on Telecom. Ablation results are also large: removing the Action Realization layer loses up to 62% on Airline, while removing Trajectory Regulation loses 86% on ALFWorld (Xu et al., 21 May 2026).

CRIMP quantifies both robustness and cost. On LeNet-5 for MNIST with baseline 99.21%, no adaptation at $\mathit{EffectiveSpeed}_m= \begin{cases} 1\times \min_{\ell\in\text{CPUs}}(\mathit{CPUSpeed}_\ell), & \text{if }1+\mathit{Workload}_m\le \mathit{NumOfCPUs}_m,\[6pt] \dfrac{\mathit{NumOfCPUs}_m}{1+\mathit{Workload}_m}\times \min_{\ell}(\mathit{CPUSpeed}_\ell), & \text{o.w.} \end{cases}$3 yields 97.43%, while runtime-aware adaptation yields 99.13%; with pruning at 94.9% sparsity the result is 98.90%. On VGG-16 for CIFAR-10 with baseline 93.28%, no adaptation at $\mathit{EffectiveSpeed}_m= \begin{cases} 1\times \min_{\ell\in\text{CPUs}}(\mathit{CPUSpeed}_\ell), & \text{if }1+\mathit{Workload}_m\le \mathit{NumOfCPUs}_m,\[6pt] \dfrac{\mathit{NumOfCPUs}_m}{1+\mathit{Workload}_m}\times \min_{\ell}(\mathit{CPUSpeed}_\ell), & \text{o.w.} \end{cases}$4 yields 91.06%, while adaptation yields 93.20%; with pruning at 88.3% the result is 90.31%. On ResNet-56 for CIFAR-10 with baseline 93.34%, no adaptation at $\mathit{EffectiveSpeed}_m= \begin{cases} 1\times \min_{\ell\in\text{CPUs}}(\mathit{CPUSpeed}_\ell), & \text{if }1+\mathit{Workload}_m\le \mathit{NumOfCPUs}_m,\[6pt] \dfrac{\mathit{NumOfCPUs}_m}{1+\mathit{Workload}_m}\times \min_{\ell}(\mathit{CPUSpeed}_\ell), & \text{o.w.} \end{cases}$5 yields 91.88%, while adaptation yields 93.18%; with pruning at 51.4% the result is 91.88%. The reported training overhead is approximately 10–20% extra time, whereas inference latency and hardware overhead are zero because no additional compute units, extra cycles, multiplier, or mask logic are needed at runtime (Huai et al., 9 Jul 2026).

AMPLE-GNC reports separated metrics for command generation, control adaptation, and shielding. The commander achieves 100% grammar validity and 84% planner-executable actions. On held-out faults, Rapid Motor Adaptation recovers 97.8% of actuator-sign faults and 94.4% of continuous-gain faults, compared with 0% for fault-unaware PD and end-to-end GRU+RL, 100%/55.2% for the classical sign-adaptive baseline, and 45.2%/3.2% for the Nussbaum-gain baseline. With adaptation-aware engagement at $\mathit{EffectiveSpeed}_m= \begin{cases} 1\times \min_{\ell\in\text{CPUs}}(\mathit{CPUSpeed}_\ell), & \text{if }1+\mathit{Workload}_m\le \mathit{NumOfCPUs}_m,\[6pt] \dfrac{\mathit{NumOfCPUs}_m}{1+\mathit{Workload}_m}\times \min_{\ell}(\mathit{CPUSpeed}_\ell), & \text{o.w.} \end{cases}$6, the controller remains autonomous 94.5% of the time while still catching non-recovery, and the shield overhead is 0.02% per 10 Hz step, approximately 18 $\mathit{EffectiveSpeed}_m= \begin{cases} 1\times \min_{\ell\in\text{CPUs}}(\mathit{CPUSpeed}_\ell), & \text{if }1+\mathit{Workload}_m\le \mathit{NumOfCPUs}_m,\[6pt] \dfrac{\mathit{NumOfCPUs}_m}{1+\mathit{Workload}_m}\times \min_{\ell}(\mathit{CPUSpeed}_\ell), & \text{o.w.} \end{cases}$7s (Shojaei, 24 Jun 2026).

These results make two recurring trade-offs explicit. First, better robustness usually depends on richer runtime information or richer training-time simulation. Second, adaptation is only practical when its own overhead is minor, overlapped, or moved offline.

6. Misconceptions, limitations, and recurring tensions

A common misconception is that adaptation necessarily means changing model parameters. Life-Harness is defined precisely by the opposite choice: $\mathit{EffectiveSpeed}_m= \begin{cases} 1\times \min_{\ell\in\text{CPUs}}(\mathit{CPUSpeed}_\ell), & \text{if }1+\mathit{Workload}_m\le \mathit{NumOfCPUs}_m,\[6pt] \dfrac{\mathit{NumOfCPUs}_m}{1+\mathit{Workload}_m}\times \min_{\ell}(\mathit{CPUSpeed}_\ell), & \text{o.w.} \end{cases}$8 is fixed, the runtime harness evolves from trajectories, and the final harness is frozen for held-out evaluation (Xu et al., 21 May 2026). A related misconception is that runtime adaptation always requires redesigning the primary control architecture. MROS was motivated by the observation that many self-adaptive robotics proposals require a major redesign and rely on complex tools unfamiliar to the robotics community; its stated objective is reuse and extensibility across ROS applications instead (Bozhinoski et al., 2020).

Another recurring misconception is that better adaptation simply follows from adding more training data. AMPLE-GNC reports that beyond the training randomization envelope, a split-conformant retrain scores 57–67%, while retraining with 4× more in-regime data worsens performance, supporting the paper’s claim that randomization breadth, not data volume, drives generalization (Shojaei, 24 Jun 2026). CRIMP similarly indicates that robustness to device non-idealities can be induced by exposing the network to sampled write variation during training rather than by adding runtime compensators, with the resulting inference path incurring zero overhead (Huai et al., 9 Jul 2026).

The literature also documents a structural tension between capability and protection. AMPLE-GNC states explicitly that a latching safe-hold shield can suppress even a capable controller, and addresses this through a split-conformal recovery-deadline certificate and adaptation-aware engagement (Shojaei, 24 Jun 2026). MorphServe addresses a different version of the same tension: lowering precision and resizing KV cache relieves pressure and reduces SLO violations, but threshold choices determine the operating point on an efficiency–accuracy frontier (Su et al., 24 May 2025). Yang et al. formalize this tension as decision-space reduction under reliability, utility, timing, and energy constraints, verified through PCTL and CSL rather than heuristic tuning (Yang et al., 2017).

Finally, the surveyed systems clarify that “runtime-aware” does not always mean “test-time learning.” In some cases adaptation is online and explicit, as in ORCA, MROS, MorphServe, and AMPLE-GNC. In others, such as CRIMP, runtime awareness is incorporated during training so that the deployed system remains static but robust (Jacques-Silva et al., 2012, Al-Hawari et al., 2019, Huai et al., 9 Jul 2026). This suggests that the field is better understood as a spectrum of mechanisms for reconciling real operating conditions with idealized design assumptions, rather than as a single family of runtime controllers.