Demand-Driven Application Management

• Demand-Driven Application Management is an adaptive strategy that adjusts resource allocation and deployment based on real-time and forecasted demand signals.
• It integrates techniques such as utilization forecasting, probabilistic provisioning, and closed-loop prediction to overcome the limitations of static configurations.
• It leverages both centralized and decentralized orchestration patterns to reconcile local demand insights with global performance objectives.

Searching arXiv for recent and relevant papers on demand-driven application/resource management across clusters, microservices, cloud-edge, and related orchestration settings. Demand-Driven Application Management denotes a class of application-management approaches in which deployment, resource allocation, reconfiguration, and related control actions are driven by observed or anticipated application demand rather than by static reservations, fixed workflows, or permanently provisioned worst-case configurations. Across compute clusters, clouds, microservice systems, fog and edge environments, and demand-side management settings, the unifying premise is that application demand is dynamic, that static allocation is therefore structurally inefficient, and that management logic should adapt online to workload, service-level objectives, queueing effects, user requests, or other demand signals. The literature spans data-driven cluster resizing (Pace et al., 2018), probabilistic cloud provisioning under rare bursts (Gonçalves et al., 2012), distributed peak-demand minimization (Notarnicola et al., 2017), QoS-aware microservice control (Zhang et al., 2021), closed-loop forecast-and-decision co-optimization (Garcia et al., 2021), continuum-wide SLO-driven deployment automation (Samani et al., 2024), malleable HPC jobs (Iserte et al., 2020), user-space page management driven by application hints (Peng et al., 2019), adaptive process/runtime interfaces for HPC DRM (Huber et al., 2024), declarative decentralized fog orchestration (Brogi et al., 17 Jan 2025), and C-ITS application orchestration through Kubernetes and ROS 2 (Zanger et al., 23 Sep 2025).

1. Conceptual scope and defining characteristics

A recurring motivation in the literature is that demand changes over time while conventional management mechanisms often do not. In compute clusters, resources are commonly reserved for peak demand although peak usage may occur only for a small portion of application lifetime, leading to under-utilization (Pace et al., 2018). In cloud systems, resource costs vary by configuration while workloads can exhibit sudden intense variations and rare extreme events such as buzz or flash crowd effects (Gonçalves et al., 2012). In HPC, jobs are usually submitted with a fixed resource allocation even though cluster demand changes over time, which harms both utilization and turnaround (Iserte et al., 2020). In microservices, dependencies between tiers create backpressure and cascading QoS violations, so local utilization signals are inadequate for end-to-end management (Zhang et al., 2021).

Within this body of work, “demand-driven” consistently implies that management decisions are tied to runtime demand signals rather than to static declarations alone. Those signals differ by domain. In clusters and clouds they include observed resource utilization, workload intensity, and queueing behavior (Pace et al., 2018). In probabilistic provisioning they include time-averaged workload levels and rare-event probabilities over multiple time scales (Gonçalves et al., 2012). In microservices they include per-tier CPU, memory, and network utilization, end-to-end latency history, and candidate next-step resource configurations (Zhang et al., 2021). In fog and Cloud-IoT systems they include local request rates, latency to clients, and resource availability, expressed as local facts for decentralized policy evaluation (Brogi et al., 17 Jan 2025). In C-ITS they include the requested configuration and the list of requesting entities, which together form the demand on a specific application part at a certain point in time (Zanger et al., 23 Sep 2025).

A second defining characteristic is that demand-driven management is broader than autoscaling in the narrow sense of adding or removing capacity. The papers include dynamic resource provisioning (Pace et al., 2018, Gonçalves et al., 2012), per-tier CPU assignment in microservices (Zhang et al., 2021), process-count changes in malleable HPC jobs (Iserte et al., 2020), process-set operations such as grow, shrink, split, union, and replace in dynamic resource management for HPC programming models (Huber et al., 2024), page-level caching and prefetching driven by application hints (Peng et al., 2019), workflow and schema evolution in description-driven BPM systems (McClatchey, 2018), and deployment, reconfiguration, update, upgrade, and scaling in C-ITS application orchestration (Zanger et al., 23 Sep 2025).

A third common theme is the separation between local demand knowledge and global control objectives. Several papers stress that local application signals alone are insufficient, while a purely system-driven approach lacks application semantics. The HPC DRM design principles explicitly decompose the problem into Dynamic Process Management and Dynamic Resource Allocation/Mapping, so that applications describe process changes while the system decides where resources are assigned (Huber et al., 2024). The DMR API for malleable MPI jobs similarly relies on collaboration between workload manager and parallel runtime (Iserte et al., 2020). Sinan’s centralized scheduler uses global application view plus per-tier metrics to choose resource-efficient actions that preserve end-to-end QoS (Zhang et al., 2021).

2. Demand signals, state representations, and control variables

The representation of demand is domain-specific, but the surveyed work reveals several recurring categories.

Observed resource demand is central in data-driven cluster management. The mechanism in "A Data-Driven Approach to Dynamically Adjust Resource Allocation for Compute Clusters" monitors resource utilization, forecasts resource demand with quantified uncertainty, and modulates resources assigned to running applications accordingly (Pace et al., 2018). MDP_DT similarly models the environment through a measurement vector over resource-side and workload-side variables, then learns which distinctions matter by adaptive partitioning of the state space (Lolos et al., 2017).

Burst and rare-event demand is central in probabilistic cloud provisioning. In "Dynamic Resource Management in Clouds: A Probabilistic Approach" the key object is the probability of observing a given time-averaged workload over aggregation window $\tau$, characterized through a large deviations spectrum $f(\alpha)$ (Gonçalves et al., 2012). This permits threshold policies and capacity margins based not only on expected demand but on the probability of sustained overload.

End-to-end QoS demand is central in interactive microservices. Sinan gathers per-tier CPU, memory, and network utilization, end-to-end latency measurements, and workload information such as requests per second every 1 second, then evaluates candidate per-tier CPU allocations with a CNN latency predictor and a Boosted Trees QoS-violation predictor (Zhang et al., 2021). The QoS targets in evaluation are 99th-percentile latency $\le 200 \text{ ms}$ for Hotel Reservation and $\le 500 \text{ ms}$ for Social Network (Zhang et al., 2021).

User- or entity-originated demand is explicit in C-ITS and fog orchestration. In "Application Management in C-ITS: Orchestrating Demand-Driven Deployments and Reconfigurations" a demand may include which application is demanded, basic application configurations, necessary communication channels, and which C-ITS entities request the application; for a specific application part, the requested configuration and the list of requesting C-ITS entities together form the demand (Zanger et al., 23 Sep 2025). In the decentralized fog framework "Declarative Application Management in the Fog. A bacteria-inspired decentralised approach", the local fact $\le 200 \text{ ms}$8 encodes request rate and latency from neighboring sources, which directly drive replicate, migrate, and undeploy decisions (Brogi et al., 17 Jan 2025).

Application-hint demand appears in memory management. UMap moves page management to user space so that applications can steer caching, prefetching, eviction, and flushing based on access patterns and storage characteristics, using configurable page size, explicit arbitrary-page prefetch, bounded buffers, and dirty-page watermarks (Peng et al., 2019). Here the “demand” is not merely a page fault; it is the application’s knowledge of which pages matter next and which transfer granularity is appropriate.

Forecast-driven demand appears in closed-loop forecast-and-decision systems. "Application-Driven Learning: A Closed-Loop Prediction and Optimization Approach Applied to Dynamic Reserves and Demand Forecasting" argues that forecasting should be optimized with respect to realized downstream application cost rather than standalone statistical loss, formalized as a bilevel problem

$\theta_T \in \argmin \limits_{\theta \in \Theta, \hat{y}_t,z_t^{*} \quad \frac{1}{T} \sum_{t \in \mathbb{T}} G_a(z_t^{*}, {y}_t)$

subject to

$$\hat{y}_t = \Psi (\theta, x_t), \qquad z_t^{*} \in \argmin_{z \in Z } G_p(z, \hat{y}_t)$$

(Garcia et al., 2021). This recasts demand management as a closed loop in which prediction and action are co-optimized.

3. Architectural patterns and implementation models

Despite wide variation in domain, the papers converge on a small number of architectural patterns.

One pattern is the monitor–predict–act loop. The cluster mechanism of (Pace et al., 2018) monitors utilization, forecasts demand and confidence, and adjusts allocations. Sinan collects metrics every second, predicts near-term latency and later QoS violation probability, and chooses the least-resource safe action (Zhang et al., 2021). The continuum resource manager in (Samani et al., 2024) continuously monitors SLOs, validates deployments with the Monitoring and Alerting Verticles, and reacts to violations within an evaluation interval of 5 s.

A second pattern is declarative desired-state reconciliation. In C-ITS, the application manager translates deployment requests into Kubernetes custom resources, and custom operators reconcile changing and new demands using bookkeeping to derive a new desired application state (Zanger et al., 23 Sep 2025). This explicitly extends Kubernetes’ reconciliation loop from infrastructure resources to the application level. The fog framework in (Brogi et al., 17 Jan 2025) is also declarative, but with Prolog rules at each decentralized agent instead of a centralized Kubernetes control plane.

A third pattern is cooperation between application/runtime and system scheduler. The DMR API for malleable MPI jobs exposes reconfiguration points through dmr_check_status or dmr_icheck_status, while Slurm returns expand, shrink, or none depending on spare resources and queued jobs (Iserte et al., 2020). The HPC DRM design-principles paper generalizes this into process-centric interfaces with Process Sets (PSets), PSet operations, and a Cooperative Optimization Language associated with those operations (Huber et al., 2024).

A fourth pattern is surrogate or latent-model control. Sinan’s CNN produces latent representation $L_f$, which is then used both for latency prediction and by the Boosted Trees QoS-violation classifier (Zhang et al., 2021). The Stackelberg DSM paper estimates a projected-affine user-response model

$x^*(y)=\mathrm{proj}_C(\Theta_Ay-\Theta_b)$

from observed user actions and then solves a learned surrogate bilevel problem to accelerate tariff search (Cianchi et al., 1 May 2026). MDP_DT uses a decision-tree abstraction over measured telemetry to create an adaptive state representation for a full-model MDP (Lolos et al., 2017).

4. Core methodological families

Demand-driven application management in the surveyed literature can be organized into several methodological families.

4.1 Data-driven demand forecasting with uncertainty

The compute-cluster mechanism of (Pace et al., 2018) represents a forecasting-based family. It employs a data-driven approach to resource-demand forecasting, with quantification of uncertainty, and uses predicted demand and confidence to modulate cluster resources while preventing failures due to finite-resource contention such as RAM (Pace et al., 2018). The abstract reports more than one order of magnitude reduction in turnaround time while keeping application failures under control (Pace et al., 2018).

A related but more formal probabilistic approach appears in (Gonçalves et al., 2012). For a finite irreducible continuous-time Markov process and observable $\Phi$, the paper studies

$\frac{1}{\tau}\cdot\int_{0}^{\tau} \Phi(X_s) d s$

and derives a large-deviation principle

$f(\alpha)$0

For the VoD use case, $f(\alpha)$1, so $f(\alpha)$2 is the time-averaged number of active viewers (Gonçalves et al., 2012). This supports reconfiguration timescale selection and capacity-margin sizing through quantities such as

$f(\alpha)$3

4.2 Distributed optimization for peak-demand management

The smart-grid DSM paper (Notarnicola et al., 2017) studies distributed minimization of

$f(\alpha)$4

with double coupling across devices and across time. Through a sequence of primal/dual reformulations, it derives local convex problems

$f(\alpha)$5

and dual updates

$f(\alpha)$6

This family is not forecasting-based but optimization-based: demand enters as coupled convex costs to be coordinated across agents.

4.3 QoS-aware prediction-driven microservice management

Sinan is a representative microservice family. It uses a CNN for next-interval tail-latency prediction and Boosted Trees for later QoS-violation prediction, operating every second (Zhang et al., 2021). It evaluates a restricted candidate action space such as scale down one tier, hold current allocation, scale up one tier, scale up all tiers, or scale up recent victim tiers, with CPU change steps of 0.2 up to 1.0 CPU or 10%/30% service CPU changes (Zhang et al., 2021). Candidate actions are filtered by predicted latency exceeding $f(\alpha)$7 and then by violation probability thresholds $f(\alpha)$8, after which the least-resource acceptable action is chosen (Zhang et al., 2021).

The CNN is trained with squared loss

$f(\alpha)$9

and, in the more detailed version of the work, achieves validation RMSE of 14.7 ms for Hotel Reservation and 26.4 ms for Social Network (Zhang et al., 2021). The paper reports that Sinan always meets QoS on the evaluated applications while using less CPU than other QoS-meeting methods; for example, on Hotel Reservation it uses 25.9% less CPU on average and up to 46.0% less, and on Social Network it reduces CPU usage by 59.0% on average and up to 68.1% (Zhang et al., 2021).

4.4 Closed-loop prediction-and-decision co-optimization

The application-driven learning framework (Garcia et al., 2021) belongs to a distinct family in which forecasts are learned against downstream decision cost. It proves that

$\le 200 \text{ ms}$0

with probability 1 under the paper’s assumptions, where

$\le 200 \text{ ms}$1

Empirically, on PG-LIB-OPF systems the Opt-Opt configuration improves out-of-sample cost over LS-Ex by between $\le 200 \text{ ms}$2 and $\le 200 \text{ ms}$3, with average gain $\le 200 \text{ ms}$4 (Garcia et al., 2021). This family suggests that demand-driven management may require changing the learning objective itself, not just the runtime controller.

4.5 Runtime malleability and process-centric DRM

The HPC strand includes DMR API (Iserte et al., 2020) and the DRM design-principles paper (Huber et al., 2024). DMR API exposes application-level malleability at safe points and lets the scheduler decide whether to expand, shrink, or keep current size. On a 400-job workload, synchronous malleable execution achieved average resource utilization 93.909% versus 83.607% for fixed execution, average waiting-time gain 27.980%, and average completion-time gain 12.786% despite a negative execution-time gain of $\le 200 \text{ ms}$5 due to shrinking jobs from performance-optimal size (Iserte et al., 2020). Across workloads of 50, 100, 200, and 400 jobs, flexible workloads reduced waiting and completion times substantially even though execution times increased (Iserte et al., 2020).

The design-principles paper abstracts this into Process Sets and PSet operations such as ADD, SUB, SPLIT, UNION, DIFFERENCE, INTERSECTION, GROW, SHRINK, and REPLACE, plus a Cooperative Optimization Language attached to those operations (Huber et al., 2024). This generalizes demand-driven management beyond ad hoc grow/shrink APIs.

4.6 User-space, application-driven data/memory management

UMap (Peng et al., 2019) shows that demand-driven management can target page placement and movement rather than coarse resources. Using userfaultfd, manager threads, filler threads, evictor threads, and a store-object abstraction, it lets applications control page size, prefetch, eviction, and flushing per region. The paper reports performance improvements of 1.25× to 2.5× over the system service, with 2.5× speedup for out-of-core sort at 8 MiB page size and 1.8× for BFS at 512 KiB (Peng et al., 2019).

4.7 Declarative and decentralized policy-based orchestration

The fog paper (Brogi et al., 17 Jan 2025) represents a decentralized family. Policies are Prolog rules of the form $\le 200 \text{ ms}$9 and use facts such as service, node, serviceInstance, requests, and inhibited (Brogi et al., 17 Jan 2025). Local agents can replicate, migrate, or undeploy, and global behavior emerges from accepted local actions. In simulation over Rome taxi traces with 81 AP handovers, the system reacts within 1–2 management cycles on average, and correlations between user handovers and management operations include $\le 200 \text{ ms}$6 for workload-sensitive apps under Policy 1 and $\le 200 \text{ ms}$7 for latency-sensitive apps under Policy 2 (Brogi et al., 17 Jan 2025).

4.8 Kubernetes-based demand reconciliation at the application level

The C-ITS framework (Zanger et al., 23 Sep 2025) uses a ROS 2 action interface for deployment requests, an application manager to translate those requests into Kubernetes custom resources, and custom operators with bookkeeping to reconcile overlapping, time-shifted demands. In the collective perception use case, object detection and object fusion services are deployed on demand when vehicles approach an intersection; existing services are reused rather than redeployed when later requesters arrive; and shared services are only shut down when no requesters remain (Zanger et al., 23 Sep 2025).

5. Representative systems and empirical evidence

The following table organizes representative systems by domain and demand signal.

System	Domain	Demand signal and action
Compute-cluster forecasting (Pace et al., 2018)	Compute clusters	Utilization forecasting with uncertainty; modulate assigned resources
Probabilistic VoD provisioning (Gonçalves et al., 2012)	Cloud networking / VoD	Large-deviation workload analysis; choose reconfiguration timescale and capacity margin
Sinan (Zhang et al., 2021)	Interactive microservices	Per-tier telemetry, latency history, candidate CPU allocations; choose least-resource safe action
DMR API (Iserte et al., 2020)	HPC	Queue pressure and spare resources; expand, shrink, or keep current process count
UMap (Peng et al., 2019)	Data-intensive HPC / storage	Application access hints, page faults, backend characteristics; prefetch, evict, flush, resize regions
Continuum resource manager (Samani et al., 2024)	Edge–cloud continuum	SLO monitoring and threshold validation; alert and support corrective orchestration
Declarative fog management (Brogi et al., 17 Jan 2025)	Fog / Cloud-IoT	Local requests, latency, available hardware; replicate, migrate, undeploy
C-ITS application manager (Zanger et al., 23 Sep 2025)	C-ITS	Requested configuration plus requester set; deploy, reconfigure, update, scale, shut down

Several quantitative findings recur across these systems. Compute-cluster forecasting reports turnaround-time reduction by more than one order of magnitude (Pace et al., 2018). Sinan reports always meeting QoS in evaluation while maintaining high utilization and reducing CPU usage relative to alternative QoS-meeting methods (Zhang et al., 2021). UMap reports 1.25× to 2.5× performance improvement over mmap with adapted configurations (Peng et al., 2019). The continuum resource manager detects SLO violations in 0–5 s because the evaluation interval is 5 s (Samani et al., 2024). Malleable HPC execution improves average waiting and completion times at workload scale (Iserte et al., 2020). The closed-loop forecasting paper reports large-system out-of-sample cost improvements averaging 8.42% (Garcia et al., 2021).

6. Common design principles

A set of cross-cutting design principles emerges from the literature.

Demand should be represented at the right abstraction level. In some systems the relevant state is instantaneous resource usage; in others it is a time-averaged workload over a horizon (Gonçalves et al., 2012), a requester set and configuration (Zanger et al., 23 Sep 2025), or an application-specific access pattern (Peng et al., 2019). This suggests that demand-driven management is less about one universal signal than about exposing the control-relevant demand variable for a given domain.

Static thresholds are usually insufficient. This is explicit in elasticity papers such as MDP_DT, which motivates adaptive state-space partitioning by the difficulty of identifying correct metrics and thresholds in advance (Lolos et al., 2017), and in microservices, where utilization thresholds are shown to be unreliable proxies for end-to-end latency (Zhang et al., 2021).

Application semantics matter. The DMR API requires applications to expose safe reconfiguration points and redistribution logic (Iserte et al., 2020). UMap relies on application hints (Peng et al., 2019). The BPM paper relies on runtime-interpreted, versioned descriptions of workflows and schemas (McClatchey, 2018). The fog paper relies on application-specific declarative policies (Brogi et al., 17 Jan 2025). This suggests that purely infrastructure-driven orchestration is often too weak.

Global objectives still require system-level control. Cooperative interfaces in HPC (Huber et al., 2024), centralized cluster scheduling in Sinan (Zhang et al., 2021), and the application manager in C-ITS (Zanger et al., 23 Sep 2025) all preserve a system-level role in reconciling multiple demands and resources.

Prediction without downstream coupling can be misaligned. This is the explicit thesis of application-driven learning (Garcia et al., 2021), but it also underlies Sinan’s use of future QoS-violation prediction rather than myopic latency-only prediction (Zhang et al., 2021).

Runtime bookkeeping is indispensable when demands overlap in time. The C-ITS framework’s custom operators store which entities request which application part and its dynamic configurations (Zanger et al., 23 Sep 2025). The fog paper stores inhibited operations to avoid retrying impossible actions (Brogi et al., 17 Jan 2025). DMR maintains queue-aware decisions across running and pending jobs (Iserte et al., 2020).

7. Misconceptions and points of contention

One common misconception is that demand-driven management is equivalent to threshold autoscaling. The surveyed work suggests otherwise. Threshold triggers are only one possible policy mechanism, and several papers argue they are difficult to configure or structurally inadequate (Lolos et al., 2017, Zhang et al., 2021). Demand-driven systems may instead use forecasts (Pace et al., 2018), probabilistic large-deviation analysis (Gonçalves et al., 2012), distributed optimization (Notarnicola et al., 2017), learned surrogate models (Cianchi et al., 1 May 2026), or declarative logical policies (Brogi et al., 17 Jan 2025).

A second misconception is that demand-driven management necessarily requires centralized optimization. The fog paper explicitly proposes a fully decentralized approach (Brogi et al., 17 Jan 2025), while HPC DRM proposes cooperative interfaces rather than centralized direct control of all process semantics (Huber et al., 2024). At the same time, some domains do benefit from central control, as in Sinan and Kubernetes-based C-ITS management (Zhang et al., 2021, Zanger et al., 23 Sep 2025). This suggests that centralization is an architectural choice, not a defining property.

A third misconception is that better predictive accuracy always yields better management. The freezer DSM paper shows the opposite in a controlled setting: the nonlinear Model E has the best predictive accuracy, but the third-order linear Model C is better for MPC because it yields a convex optimization problem and better control performance (Sossan et al., 2015). This suggests a broader principle: model tractability and control alignment may matter as much as raw forecast fidelity.

A fourth misconception is that demand-driven management is only about resource quantity. Several papers manage topology, communication channels, workflow definitions, or page movement rather than just CPU count (Peng et al., 2019, McClatchey, 2018, Zanger et al., 23 Sep 2025).

8. Limitations and open directions

The literature also reveals recurring limitations.

Many systems rely on offline training or profiling. Sinan requires deliberate offline data collection, taking 8.7 hours for Hotel Reservation and 16 hours for Social Network (Zhang et al., 2021). Application-driven learning can overfit with small samples in more flexible model classes (Garcia et al., 2021). MDP_DT needs stored experience and careful split-threshold calibration (Lolos et al., 2017).

Several systems are resource-specific. Sinan mainly controls CPU, while memory is provisioned at maximum profiled usage (Zhang et al., 2021). The continuum resource manager provides strong SLO monitoring and deployment automation, but its autonomous reallocation policy is under-specified (Samani et al., 2024). The C-ITS paper focuses on a collective perception use case and does not provide quantitative contention-resolution or priority schemes (Zanger et al., 23 Sep 2025).

Some frameworks provide substrates rather than full policy solutions. The HPC DRM design-principles paper defines interfaces and abstractions but does not report quantitative performance metrics (Huber et al., 2024). The BPM paper provides a strong metadata and provenance architecture for runtime evolution, but says little about resource elasticity or SLOs (McClatchey, 2018).

Decentralized systems may sacrifice global optimality. The fog framework reacts locally and scales by decentralization, but it does not optimize a global objective or provide strong global convergence guarantees (Brogi et al., 17 Jan 2025). This suggests a design trade-off between scalability and global coordination.

A plausible implication is that future work will increasingly combine the strengths of these families: declarative application semantics, probabilistic or learned demand models, control-theoretic or optimization back ends, and runtime reconciliation infrastructure. The most explicit examples already point in that direction: closed-loop forecast learning (Garcia et al., 2021), learning-assisted Stackelberg incentive design (Cianchi et al., 1 May 2026), and QoS-aware microservice control (Zhang et al., 2021).

9. Synthesis

Demand-Driven Application Management is best understood not as a single algorithmic technique but as an organizing principle for managing applications under dynamic demand. The principle is that management decisions should be induced by the current or anticipated demand state that actually matters for the application and the system’s objectives. In the surveyed work, this leads to several concrete forms: utilization forecasting with uncertainty in compute clusters (Pace et al., 2018), large-deviation provisioning over time scales (Gonçalves et al., 2012), distributed peak-demand optimization (Notarnicola et al., 2017), end-to-end QoS-aware per-tier control in microservices (Zhang et al., 2021), bilevel co-optimization of forecasts and operational plans (Garcia et al., 2021), SLO-aware deployment automation across the continuum (Samani et al., 2024), runtime malleability and process-set control in HPC (Iserte et al., 2020, Huber et al., 2024), application-driven page management (Peng et al., 2019), decentralized rule-based fog orchestration (Brogi et al., 17 Jan 2025), and Kubernetes-based reconciliation of overlapping application demands in C-ITS (Zanger et al., 23 Sep 2025).

Taken together, these works suggest that demand-driven application management is fundamentally about closing the loop between application demand, system observation, and adaptive control, while preserving enough application semantics to make those controls meaningful. Whether realized through MDPs, bilevel optimization, machine learning, declarative policies, or runtime interfaces, the field is defined by that closed-loop relationship between evolving demand and evolving application state.