Runtime Consultant: Proactive Decision Support

• Runtime Consultant is a proactive, runtime-based advisory mechanism that evaluates system execution using formal value functions and dynamic models.
• It leverages prefix-based analyses to recommend actions that optimize quantitative objectives and ensure adherence to desired behaviors.
• Its implementations balance rigorous offline synthesis with lightweight online decision support, aiding operators without enforcing actions.

Searching arXiv for papers on runtime consultants and closely related runtime decision-support/runtime verification work. A runtime consultant is a runtime entity that runs in parallel to a system execution and provides inputs at every step of the run. Unlike a runtime monitor, which alerts when a violation occurs, a runtime consultant is proactive: it provides recommendations for which action to take next in order to avoid violation or obtain a maximal value for quantitative objectives (Fisman et al., 3 Aug 2025). In the most formal treatment, runtime consultants are defined with respect to value functions on infinite words and operate over finite prefixes of executions, continuously updating recommendations as the observed run evolves (Fisman et al., 3 Aug 2025). In adjacent strands of research, closely related notions appear as model-based runtime decision layers, persona-driven decision-support advocates, debugger-integrated runtime assistants, and decentralized runtime assurance mechanisms (Vogel et al., 2018, Vogel et al., 2018, Vogel et al., 2018, Hernandez et al., 7 May 2025, Ganguly et al., 2023). Taken together, these works position the runtime consultant as a general category of runtime decision-support mechanism: advisory rather than necessarily enforcing, execution-aware rather than purely static, and typically grounded in formal models, runtime models, or value-guided analyses.

1. Formal notion in runtime verification

The most explicit formalization introduces runtime consultants over infinite words $w \in \Sigma^\omega$ and value functions $\mu : \Sigma^\omega \to \mathbb{T}$, where $\mathbb{T}$ is a totally ordered set (Fisman et al., 3 Aug 2025). The value function is implemented by a quantitative automaton, or “quatomaton,”

$$\mathcal{A} = (\Sigma, Q, q_0, \delta, \kappa, \alpha),$$

with states $Q$, initial state $q_0$, transition/output functions $\delta$ and $\kappa$, and an aggregation function $\alpha$ that assigns a value to the unique run over a word (Fisman et al., 3 Aug 2025). Runtime consultation is prefix-based: only a finite prefix $u \in \Sigma^*$ is available at runtime, so the consultant reasons about best possible continuations of $\mu : \Sigma^\omega \to \mathbb{T}$0 (Fisman et al., 3 Aug 2025).

Two induced prefix values are central. The any-extension value is

$\mu : \Sigma^\omega \to \mathbb{T}$1

capturing the best achievable value among all infinite continuations of the current prefix (Fisman et al., 3 Aug 2025). The cyclic-extension value is

$\mu : \Sigma^\omega \to \mathbb{T}$2

capturing the best achievable value among continuations that eventually loop back to the current automaton state (Fisman et al., 3 Aug 2025). From these, one derives recommended next letters $\mu : \Sigma^\omega \to \mathbb{T}$3 and $\mu : \Sigma^\omega \to \mathbb{T}$4, corresponding respectively to globally best future behavior and best cyclic behavior through the current state (Fisman et al., 3 Aug 2025).

A runtime consultant for $\mu : \Sigma^\omega \to \mathbb{T}$5 is then a procedure that, given a prefix $\mu : \Sigma^\omega \to \mathbb{T}$6, returns a set of letters $\mu : \Sigma^\omega \to \mathbb{T}$7, where $\mu : \Sigma^\omega \to \mathbb{T}$8 is the set of labels on outgoing transitions from the current state (Fisman et al., 3 Aug 2025). It is strong if it returns all recommended actions, and weak if it returns only a subset of the recommended actions but never suggests a non-recommended action (Fisman et al., 3 Aug 2025). This distinction becomes important because strong consultants do not always exist for all value functions, whereas weak consultants often do (Fisman et al., 3 Aug 2025).

The semantics are advisory rather than enforcing. The consultant does not assume that its recommendations are always followed. Instead, it adjusts to the actions actually taken, analogous to a vehicle navigation system recalculating a route after a missed turn (Fisman et al., 3 Aug 2025). This property is not incidental but definitional: the consultant continuously recomputes recommendations from the newly observed prefix, rather than assuming compliance with an earlier plan (Fisman et al., 3 Aug 2025).

2. Relation to monitors, controllers, and runtime assurance

Runtime consultants generalize runtime monitors in a precise sense. A runtime monitor observes an execution and reports violation or satisfaction status; a runtime consultant recommends which action to take next to avoid future violation or optimize a quantitative objective (Fisman et al., 3 Aug 2025). In the Boolean case, where the value function is the indicator $\mu : \Sigma^\omega \to \mathbb{T}$9 of an $\mathbb{T}$0-regular language $\mathbb{T}$1, deviation from a $\mathbb{T}$2-recommendation can be sufficient to conclude that the property can no longer be satisfied (Fisman et al., 3 Aug 2025). This means that a violation monitor can be derived from the consultant: if the system ever takes an action outside $\mathbb{T}$3, then $\mathbb{T}$4 (Fisman et al., 3 Aug 2025). The consultant therefore strictly subsumes the monitor’s reactive role with a proactive advisory role (Fisman et al., 3 Aug 2025).

The distinction from controllers is equally important. A runtime consultant is advisory; a runtime controller is the component that may choose to follow or ignore recommendations (Fisman et al., 3 Aug 2025). This differs from enforcement mechanisms or shields, which actively restrict or modify outputs. The consultant supports decision-making but does not itself impose decisions (Fisman et al., 3 Aug 2025). In adjacent work on human-on-the-loop systems, this advisory orientation is explicit: RAVEN “does not replace the operator; instead, it surfaces evolving requirements” and provides “just-in-time” guidance while leaving the operator accountable for the ultimate decision (Hernandez et al., 7 May 2025).

In distributed runtime assurance, similar advisory functionality appears in stream-based decentralized monitoring. There, monitors compute correctness and aggregate/statistical properties over distributed traces using Lola under partial synchrony, and the framework can yield not only Boolean verdicts but also “aggregated statistics” and “profiles” to support operators (Ganguly et al., 2023). This suggests a broader notion of runtime consultant as a runtime assurance layer that not only detects violations but also exposes actionable quantitative state about the system.

Interactive Runtime Verification pushes the advisor metaphor further by combining runtime verification with debugging. There, a monitor checks behavioral properties online, and a scenario script reacts to monitor state changes by setting breakpoints, watchpoints, and checkpoints, effectively steering the debugging session toward the most informative state and time (Jakse et al., 2017). The combined monitor-plus-scenario acts as a runtime consultant for the developer: it detects suspicious behavior and immediately orchestrates the debugging environment to support diagnosis (Jakse et al., 2017).

3. Value functions, objectives, and recommendation semantics

The formal theory studies runtime consultants for common value functions used in verification, including $\mathbb{T}$5, $\mathbb{T}$6, $\mathbb{T}$7, $\mathbb{T}$8, and $\mathbb{T}$9, as well as Boolean and quantitative interpretations of $$\mathcal{A} = (\Sigma, Q, q_0, \delta, \kappa, \alpha),$$0-regular properties (Fisman et al., 3 Aug 2025). For weighted graphs, these objectives capture peak values, minimum values, long-run extrema, and long-run averages (Fisman et al., 3 Aug 2025). For $$\mathcal{A} = (\Sigma, Q, q_0, \delta, \kappa, \alpha),$$1-regular properties, the Boolean interpretation uses deterministic parity automata, while the quantitative interpretation relies on a recently proposed robustness semantics $$\mathcal{A} = (\Sigma, Q, q_0, \delta, \kappa, \alpha),$$2 (Fisman et al., 3 Aug 2025).

The recommendation semantics differ between $$\mathcal{A} = (\Sigma, Q, q_0, \delta, \kappa, \alpha),$$3 and $$\mathcal{A} = (\Sigma, Q, q_0, \delta, \kappa, \alpha),$$4. The $$\mathcal{A} = (\Sigma, Q, q_0, \delta, \kappa, \alpha),$$5-consultant recommends moves that preserve access to the best achievable future value from the current prefix, while the $$\mathcal{A} = (\Sigma, Q, q_0, \delta, \kappa, \alpha),$$6-consultant recommends moves that preserve access to the best cycle through the current state (Fisman et al., 3 Aug 2025). In Boolean settings, the former corresponds to staying on a path from which acceptance is still achievable, while the latter corresponds to moving toward an accepting cycle that includes the current state (Fisman et al., 3 Aug 2025). In quantitative settings, $$\mathcal{A} = (\Sigma, Q, q_0, \delta, \kappa, \alpha),$$7 can prefer globally best future loops even if they require leaving the current strongly connected component, whereas $$\mathcal{A} = (\Sigma, Q, q_0, \delta, \kappa, \alpha),$$8 is local to cycles through the current state (Fisman et al., 3 Aug 2025).

For quantitative objectives, the theory establishes optimality guarantees. If from some point onward the system follows all $$\mathcal{A} = (\Sigma, Q, q_0, \delta, \kappa, \alpha),$$9-recommendations, and later all $Q$0-recommendations, then the resulting run has value at least as high as any other continuation from that prefix (Fisman et al., 3 Aug 2025). If from some point onward the run follows only $Q$1-recommendations, then the eventual cycle is at least as good as any other cycle through later prefixes (Fisman et al., 3 Aug 2025). These results characterize the consultant as a prefix-optimal guide under the chosen value semantics (Fisman et al., 3 Aug 2025).

The robustness semantics for $Q$2-regular languages are especially important because they strengthen the consultant concept. For Boolean $Q$3-regular properties, strong consultants need not exist in general; only weak consultants are guaranteed (Fisman et al., 3 Aug 2025). Under the quantitative robustness semantics $Q$4, however, strong $Q$5- and $Q$6-consultants exist for every $Q$7-regular language, although their construction is coNP-complete and may require exponential time (Fisman et al., 3 Aug 2025). This result suggests that quantitative semantics can be operationally superior to Boolean semantics for runtime advice, because they reduce arbitrariness in recommendations (Fisman et al., 3 Aug 2025).

A related but distinct utility-theoretic perspective arises in work on preferences over runtime distributions. There, algorithm choice is modeled in terms of utility functions over runtime and captime, rather than expected runtime alone (Graham et al., 2022). The central result is that under a set of axioms, preferences over algorithms are represented by expected utility

$Q$8

where $Q$9 is unique up to affine transformation of a fundamental preference scale $q_0$0 (Graham et al., 2022). This suggests that a runtime consultant for algorithm or parameter selection can be grounded not only in property satisfaction but also in explicit user utility over latency, deadlines, and failure (Graham et al., 2022).

4. Algorithms, complexity, and implementability

A notable result of the formal theory is that almost all common value functions admit runtime consultants that work in constant time after preprocessing (Fisman et al., 3 Aug 2025). The runtime cost is measured per step with respect to the run length: all necessary graph- or automaton-level computation is done once offline, and then the online consultant is a table lookup indexed by the current state, possibly with a small amount of auxiliary memory such as current extrema (Fisman et al., 3 Aug 2025). This is a strong implementability result: the conceptual shift from monitoring to advising does not, for most objectives, entail prohibitive online cost (Fisman et al., 3 Aug 2025).

The exact complexity depends on the value function. For $q_0$1, strong consultants may fail to exist, but weak $q_0$2- and $q_0$3-consultants always exist and can be built in polynomial time, with constant-time lookup online (Fisman et al., 3 Aug 2025). For $q_0$4, weak consultants exist but need $q_0$5 online time because the consultant must track the current maximum weight seen so far (Fisman et al., 3 Aug 2025). For $q_0$6, strong $q_0$7-consultants and weak $q_0$8-consultants exist with polynomial preprocessing and constant-time online evaluation (Fisman et al., 3 Aug 2025). For $q_0$9, strong consultants exist for both $\delta$0 and $\delta$1, but they also require $\delta$2 online time to track the current minimum (Fisman et al., 3 Aug 2025). For $\delta$3, weak $\delta$4-consultants can be built polynomially, but strong $\delta$5-consultants are coNP-complete to construct and may require exponential-time trail enumeration (Fisman et al., 3 Aug 2025).

For Boolean $\delta$6-regular properties, weak consultants can be computed in polynomial time and run in constant time, but strong consultants are not guaranteed (Fisman et al., 3 Aug 2025). For robustness semantics $\delta$7, strong consultants exist but their construction is coNP-complete and exponential in the worst case, though online execution remains constant time (Fisman et al., 3 Aug 2025). The practical implication is that the main computational burden lies in model preprocessing and synthesis; the runtime advisory mechanism itself can be lightweight (Fisman et al., 3 Aug 2025).

This split between heavy offline synthesis and lightweight online consultation resembles several systems outside the formal-runtime-consultant literature. In stream-based decentralized runtime verification, expensive SMT reasoning is used offline or in batched monitoring windows to enumerate consistent-cut sequences, while the resulting monitor updates are merged incrementally online (Ganguly et al., 2023). In RCOMPSs, a sequential-looking R program is translated at runtime into a task DAG, while the user-facing model remains a lightweight sequential API and the scheduling engine handles dependency tracking and execution (Zhang et al., 11 May 2025). Both cases reinforce the general runtime-consultant pattern of hiding substantial reasoning behind a low-latency online interface (Ganguly et al., 2023, Zhang et al., 11 May 2025).

5. Runtime consultants as architectural and model-based entities

Outside the formal verification setting, the notion of a runtime consultant appears as a model-based coordination and reasoning layer. Work on models and megamodels at runtime argues that multiple interrelated runtime models are needed to manage complex software systems and that megamodels should explicitly organize models and relations at runtime (Vogel et al., 2018). A runtime model is defined as providing “a view on a running software system that is used for monitoring, analyzing or adapting the system through a causal connection between the model and the system” (Vogel et al., 2018). A megamodel then acts as a higher-level organizing structure containing runtime models and the relations between them, supporting navigation, impact analysis, and automation (Vogel et al., 2018).

This architecture closely matches an expanded notion of runtime consultant. Rather than choosing a single next action from an automaton, the consultant here observes multiple concern-specific views—implementation, configuration and architectural models, context and resource models, variability models, and rules/strategies/constraints/goals—and uses their explicit relations to coordinate adaptation (Vogel et al., 2018). The paper explicitly frames such a megamodel as “a runtime knowledge structure and coordination mechanism,” and describes it as a layer that “knows what models exist, how they are related, and how to orchestrate operations across them” (Vogel et al., 2018). A plausible implication is that model-driven runtime consultation can subsume not only property guidance but also multi-view consistency maintenance and adaptation planning.

A related proposal on “Adaptation and Abstract Runtime Models” develops multiple architectural runtime models at different abstraction levels, automatically synchronized using model-driven engineering techniques and Triple Graph Grammars (Fredlund et al., 2018). The source model remains close to implementation and effectors, while target models abstract over specific concerns such as failures or architecture (Fredlund et al., 2018). Managers reason over these abstract models and enact changes by modifying the models or invoking factories, which are then refined and synchronized to the running system (Fredlund et al., 2018). This suggests a runtime consultant architecture in which advice is computed at a higher abstraction level than the concrete system representation, leveraging reusable target models and concern isolation (Fredlund et al., 2018).

The multi-model view also clarifies that runtime consultation need not be limited to correctness. Because different runtime models can capture performance, failures, architectural constraints, or resources, a consultant can evaluate trade-offs and recommend actions across concerns (Vogel et al., 2018, Fredlund et al., 2018). This is especially salient where different managers or concerns may conflict, as in cases where a performance manager proposes adding a component while an architecture manager enforces a limit on deployed instances (Vogel et al., 2018). In such settings, the consultant role includes arbitration or structured exposure of trade-offs rather than single-objective optimization.

6. Human-centered and persona-driven runtime consultation

A human-centered variant appears in “Runtime Advocates: A Persona-Driven Framework for Requirements@Runtime Decision Support,” which turns traditional personas into runtime advocate personas for human operators supervising small uncrewed aerial systems (Hernandez et al., 7 May 2025). RAVEN defines three baseline personas—Safety Controller, Ethical Governor, and Regulatory Auditor—and updates or activates them at runtime in response to events such as adverse weather, low battery, or proximity to restricted areas (Hernandez et al., 7 May 2025). Each persona is grounded in specific standards and produces contextualized runtime requirements, concrete guidance, constraints, and cautions for the operator (Hernandez et al., 7 May 2025).

This is runtime consultation in a directly operational sense. The system continuously monitors a structured world state, detects significant changes, selects which advocates are relevant, and uses a LLM grounded in standards and current state to generate contextualized runtime requirements (Hernandez et al., 7 May 2025). Guidance is “just-in-time,” tailored to the current mission context, and explicitly multi-perspective: safety, ethics, and regulation may be aligned or may intentionally conflict, exposing trade-offs rather than hiding them (Hernandez et al., 7 May 2025). The operator remains human-on-the-loop and accountable, but the advisor surfaces mission-critical constraints that might otherwise remain latent (Hernandez et al., 7 May 2025).

The architecture is event-driven. A world-state monitor aggregates sensor, mission, and regulatory data; an event detector watches for threshold crossings or significant state changes; a persona selection module decides which advocate personas are relevant; each active persona then produces domain-specific guidance; and a summarizer renders concise operator-facing advice (Hernandez et al., 7 May 2025). This suggests a generalized runtime consultant pattern for socio-technical systems: event-driven activation, role-separated advisory modules, standards-grounded reasoning, and explicit treatment of cross-domain trade-offs (Hernandez et al., 7 May 2025).

A plausible implication is that the formal runtime consultant and the persona-driven runtime advocate are instances of the same broader design space. The former defines next-action recommendations with respect to a value function over traces; the latter defines next-action guidance with respect to safety, ethical, and regulatory requirements induced by changing world state. In both cases, the consultant is advisory, reactive to actual execution, and recomputes recommendations as state evolves (Fisman et al., 3 Aug 2025, Hernandez et al., 7 May 2025).

7. Interactive, diagnostic, and performance-oriented consultants

Runtime consultation can also be diagnostic rather than purely prescriptive. Interactive Runtime Verification combines a classical debugger, a runtime monitor over formal behavioral properties, and an optional scenario script that reacts to property evolution (Jakse et al., 2017). The monitor checks events such as function calls and variable accesses against a property automaton; the scenario translates state changes into debugger actions like stopping execution, setting breakpoints, creating checkpoints, or restoring previous states (Jakse et al., 2017). This produces a “runtime consultant” for debugging: rather than merely announcing a property violation, the tool positions the debugging infrastructure at the exact state and time most useful for understanding the bug (Jakse et al., 2017).

The monitor formalism there uses extended finite-state machines with guards, updates, and trace slicing, allowing object-specific properties to be tracked across execution (Jakse et al., 2017). Dynamic instrumentation is guided by the monitor state so that only currently relevant events are monitored, improving efficiency (Jakse et al., 2017). Scenarios can create checkpoints when a property is in a good state and restore them when a violation occurs, effectively enabling runtime advice about where to inspect or replay (Jakse et al., 2017). This is an instance of consultation aimed at human developers rather than system controllers.

A performance-oriented variant appears in JXPerf, a Java performance analysis tool that pinpoints “wasteful memory operations” such as dead stores, silent stores, and silent loads (Su et al., 2019). JXPerf uses PMU sampling and hardware debug registers to observe memory accesses at machine-code level and attribute inefficiencies back to Java source and full calling contexts (Su et al., 2019). The paper explicitly casts the tool as a runtime consultant for Java performance: it identifies runtime patterns symptomatic of bad algorithms, poor data structures, missed compiler optimizations, or developer inattention, then reports them with enough context to guide remediation (Su et al., 2019). Unlike a hot-spot profiler, which says where time is spent, JXPerf says where memory work is being wasted and in which calling-context pairs, which is a stronger basis for performance advice (Su et al., 2019).

Another performance-related line is r-Complexity, which treats algorithm cost models as architecture-dependent and fits constants for functions like $\delta$8 from empirical measurements (Folea et al., 1 Nov 2025). Although it is not a runtime monitor, the paper repeatedly frames the model as a “runtime consultant” for deciding between implementations by comparing empirically grounded cost functions over realistic input distributions (Folea et al., 1 Nov 2025). This suggests a broader usage of the term for systems or methodologies that advise on execution decisions using architecture-aware performance models (Folea et al., 1 Nov 2025).

8. Distributed, concurrent, and systems-oriented settings

Distributed systems pose special challenges for runtime consultation because observations are partial and clocks are only partially synchronized. “Stream-based Decentralized Runtime Verification” addresses this by extending the Lola stream language to partially synchronous distributed systems with bounded clock skew $\delta$9 and by providing a decentralized SMT-powered monitoring architecture (Ganguly et al., 2023). Monitors observe partial distributed streams, exchange symbolic equations, and merge them so that every monitor eventually reconstructs the same set of evaluations as a centralized partially synchronous monitor (Ganguly et al., 2023). The framework supports not only correctness properties but also aggregated/statistical properties such as averages, counts, and distances (Ganguly et al., 2023).

The paper explicitly remarks that this yields a runtime consultant in the sense of flagging violations, computing continuous statistics, and exposing counters and averages to operators (Ganguly et al., 2023). Under this view, a consultant in distributed runtime verification is not only a next-letter recommender but also a decentralized aggregator of semantically meaningful state, capable of advising operators about long-term behavior, trends, or anomalies (Ganguly et al., 2023). In Industrial Control Systems and aircraft monitoring, such advisory capability is intertwined with formal guarantees: the algorithm is sound and complete under the partial synchrony semantics and has message complexity $\kappa$0 in the worst case, with a lower bound $\kappa$1 (Ganguly et al., 2023).

Concurrent programming in Erlang motivates yet another consultant form: contract-based runtime verification via EDBC [(Fredlund et al., 2018)? No, correct ID (Fredlund et al., 2018) is abstract runtime models; Erlang contracts is (Fredlund et al., 2018)? Wait user provided (Fredlund et al., 2018) for runtime models and (Fredlund et al., 2018)? Actually Erlang paper is (Fredlund et al., 2018)? No it is (Fredlund et al., 2018)? The data says (Fredlund et al., 2018) title Adaptation..., and (Fredlund et al., 2018) not Erlang. Erlang is (Fredlund et al., 2018)? user gave arXiv id (Fredlund et al., 2018)? Let's check; but must only cite correct ID from provided. For Erlang contracts it is (Fredlund et al., 2018)? No provided id: (Fredlund et al., 2018) Title Adaptation and Abstract Runtime Models; Erlang by using contracts is (Fredlund et al., 2018)? Wait at bottom says arXiv id: (Fredlund et al., 2018) Title Runtime verification in Erlang by using contracts? Actually user data says "arXiv id: (Fredlund et al., 2018) Title: Runtime verification in Erlang by using contracts Published: 2018-08-23". Let's re-read. There are two 2018 papers: (Vogel et al., 2018) and (Fredlund et al., 2018) likely Erlang. Yes okay cite (Fredlund et al., 2018).] EDBC instruments Erlang code to check contracts such as preconditions, postconditions, decreasing arguments, execution-time constraints, purity, type conformance, state invariants, and the concurrent cpre/3 condition for gen_server-style servers (Fredlund et al., 2018). Here the runtime consultant is the instrumented program itself: it checks explicit programmer knowledge at runtime and reports contract violations with detailed call and state information (Fredlund et al., 2018). The concurrent cpre/3 callback is particularly close to runtime advice, since it determines whether a request should be served now or postponed based on the current state (Fredlund et al., 2018).

At the systems-configuration level, the study of PCV interactions shows that “valid” runtime configurations can become effectively invalid or risky because parameter values interact with constants and runtime variables during propagation and use (Luo et al., 31 Mar 2025). The paper finds that only 33.6% of studied parameters propagate faithfully without interaction, while 66.4% interact with constants or variables, and 56.5% of interaction sites can lead to runtime errors, performance degradation, or unexpected behavior (Luo et al., 31 Mar 2025). This motivates a configuration-oriented runtime consultant that models not just parameter ranges but how configuration values are transformed by program logic and workload, potentially validating, explaining, or dynamically adjusting parameters based on observed PCV interaction patterns (Luo et al., 31 Mar 2025).

9. Conceptual synthesis and research directions

Across these lines of work, several recurrent features define the runtime consultant concept. First, consultation is execution-coupled: the consultant runs in parallel with the system and updates recommendations or explanations from the current prefix, state, or world model (Fisman et al., 3 Aug 2025, Hernandez et al., 7 May 2025, Jakse et al., 2017). Second, consultation is advisory rather than necessarily enforcing: whether in formal runtime verification, human-on-the-loop mission support, debugger steering, or configuration reasoning, the consultant supplies information or recommendations without necessarily taking final control (Fisman et al., 3 Aug 2025, Hernandez et al., 7 May 2025, Jakse et al., 2017, Luo et al., 31 Mar 2025). Third, consultation is model- or semantics-grounded: recommendations are justified by value functions, automata, runtime models, explicit contracts, or formally identified interaction patterns rather than purely heuristic alerts (Fisman et al., 3 Aug 2025, Vogel et al., 2018, Fredlund et al., 2018, Ganguly et al., 2023, Luo et al., 31 Mar 2025).

Several tensions also recur. One is the trade-off between expressive recommendation semantics and computational tractability. Strong consultants exist for many but not all objectives; when they do exist, synthesis may become coNP-complete or exponential, especially for long-run average and robustness settings (Fisman et al., 3 Aug 2025). Another is the trade-off between observability and overhead. Full-path attestation or full-state differencing can be highly informative but costly in runtime, memory, or network bandwidth (Ammar et al., 2024, Etemadi et al., 2022). A third is the tension between local and remote or centralized and decentralized consultation: some systems assume a local monitor/controller loop, while others distribute monitors, models, or advocates across components or human stakeholders (Ganguly et al., 2023, Vogel et al., 2018, Hernandez et al., 7 May 2025).

The runtime integrity literature introduces a complementary perspective: Control-Flow Integrity provides local policy enforcement against control-flow hijacking, while Control-Flow Attestation provides remote cryptographic evidence of the executed path (Ammar et al., 2024). From a runtime-consultant standpoint, CFA is especially relevant because it turns execution into authenticated evidence consumable by a remote verifier, effectively enabling remote consultation or auditing about runtime behavior (Ammar et al., 2024). A plausible implication is that future runtime consultants for safety- or security-critical systems may combine local enforcement, remote attestation, and value-guided recommendation within a single architecture (Ammar et al., 2024).

Open problems are correspondingly broad. The formal runtime consultant framework currently assumes finite-state deterministic models, full observability, and no probabilistic or partial-information dynamics (Fisman et al., 3 Aug 2025). Model-based consultants face coordination issues among multiple concern-specific managers and the complexity of maintaining runtime model consistency (Vogel et al., 2018, Fredlund et al., 2018). Persona-driven consultants need broader empirical validation, mitigation of LLM bias, and better management of operator cognitive load (Hernandez et al., 7 May 2025). Diagnostic and diff-augmentation consultants need better summarization, handling of sequencing effects, and stronger integration with CI and test generation (Jakse et al., 2017, Etemadi et al., 2022). Distributed consultants must continue to balance semantic rigor with scalability under partial synchrony and limited observability (Ganguly et al., 2023).

In its most general sense, the runtime consultant has emerged as a unifying idea for proactive runtime decision support. It can be a synthesized adviser over $\kappa$2-automata, a megamodel-driven coordination layer, a persona-based operational counselor, a debugger-integrated assistant, a distributed runtime assurance engine, a configuration reasoning aid, or a performance inefficiency guide (Fisman et al., 3 Aug 2025, Vogel et al., 2018, Hernandez et al., 7 May 2025, Jakse et al., 2017, Ganguly et al., 2023, Luo et al., 31 Mar 2025, Su et al., 2019). What unifies these forms is not a single implementation technique but a shared role: using runtime information and an explicit semantic model to recommend, explain, or constrain future action under evolving execution conditions.