Papers
Topics
Authors
Recent
Search
2000 character limit reached

Do Enterprise Systems Need Learned World Models? The Importance of Context to Infer Dynamics

Published 12 May 2026 in cs.AI, cs.CL, and cs.LG | (2605.12178v1)

Abstract: World models enable agents to anticipate the effects of their actions by internalizing environment dynamics. In enterprise systems, however, these dynamics are often defined by tenant-specific business logic that varies across deployments and evolves over time, making models trained on historical transitions brittle under deployment shift. We ask a question the world-models literature has not addressed: when the rules can be read at inference time, does an agent still need to learn them? We argue, and demonstrate empirically, that in settings where transition dynamics are configurable and readable, runtime discovery complements offline training by grounding predictions in the active system instance. We propose enterprise discovery agents, which recover relevant transition dynamics at runtime by reading the system's configuration rather than relying solely on internalized representations. We introduce CascadeBench, a reasoning-focused benchmark for enterprise cascade prediction that adopts the evaluation methodology of World of Workflows on diverse synthetic environments, and use it together with deployment-shift evaluation to show that offline-trained world models can perform well in-distribution but degrade as dynamics change, whereas discovery-based agents are more robust under shift by grounding their predictions in the current instance. Our findings suggest that, in configurable enterprise environments, agents should not rely solely on fixed internalized dynamics, but should incorporate mechanisms for discovering relevant transition logic at runtime.

Summary

  • The paper shows that static learned world models fail in dynamic enterprise environments, emphasizing the need to retrieve live configuration context for accurate state prediction.
  • It introduces CascadeBench, a benchmark that simulates cascading transitions across varied enterprise configurations with precise ground-truth datasets.
  • Empirical results reveal that discovery agents outperform fine-tuned models, particularly in high-complexity transition tiers under deployment shifts.

Contextual Dynamics in Enterprise System Modeling: An Analysis of "Do Enterprise Systems Need Learned World Models? The Importance of Context to Infer Dynamics"

Problem Motivation and Enterprise Dynamics

Enterprise systems are fundamentally shaped by tenant-specific configuration artifacts—business rules, workflows, policies—that evolve continuously and vary across deployments. These configurations introduce environment dynamics that are neither stationary nor globally consistent, contrasting sharply with traditional world model assumptions where the transition function is fixed and unknown. As delineated in the paper, this gives rise to a contextual transition model:

st+1P(st+1st,at,c)s_{t+1} \sim P(s_{t+1} \mid s_t, a_t, c)

where cc represents the instance configuration that is both explicit and readable in enterprise platforms.

Such variability induces distribution shifts not encountered in classical model-based RL or fixed-world environments. Consequently, LLM agents, which are increasingly leveraged for enterprise automation and planning, face brittle generalization if restricted to internalized, static world models. The paper thus interrogates the fundamental utility of learned world models in scenarios where system transition logic remains inspectable at inference time through configuration queries, categorizing transition complexity into three tiers:

  • Tier 1: Schema-determined transitions fully specified by data dictionary;
  • Tier 2: Rule-composable cascades requiring composition of explicit, configurable business rules;
  • Tier 3: Execution-inferred transitions contingent on platform-internal behaviors (e.g. rule execution order, race conditions).

CascadeBench: Benchmarking Under Configuration Shift

To dissect the impact of configurability and instance-specific logic, the authors introduce CascadeBench, a synthetic yet highly-structured benchmark that extends "World of Workflows" methodology to diverse, systematically generated enterprise environments. Figure 1

Figure 1: Overview of CascadeBench and conceptual comparison between learned world models—trained on historical data—and enterprise discovery agents that recover transition logic from live configurations.

CascadeBench enables fine-grained control of environment diversity (industries, organizational sizes, rule families) and precise delivery of relevant context (schemas, business rules), isolating reasoning capabilities from memorization or retrieval artifacts that confound real-world audit logs. The task—predicting the next state st+1s_{t+1} given (st,at)(s_t, a_t)—necessitates accurate modeling of cross-table cascades and multi-step rule firings. Figure 2

Figure 2: The data generation pipeline: audit logs of isolated, sandboxed action executions are subjected to normalization and filtering, resulting in a ground-truth dataset of state transitions and labeled cascade paths.

Experimental Framework: Prompting, SFT, and Discovery Agents

Three principal approaches to transition modeling are compared:

  • Prompted Baseline: Zero-shot inference by general-purpose (frontier and base) LLMs on minimally contextualized prompts;
  • Learned World Models: Models fine-tuned over transition data, internalizing transition dynamics in their parameters;
  • Enterprise Discovery Agents: Agents augmented with runtime retrieval, enabling on-the-fly inspection of current configuration artifacts (business rules, schemas, records) to predict action effects.

The discovery agent follows a retrieve-then-reason paradigm, adaptively selecting relevant context c~c\tilde{c} \subseteq c at inference. By comparing zero-shot, fine-tuned, and discovery-augmented agents—across both in-distribution and deployment-shifted settings—the study exposes the inductive limitations of purely learned world models for systems with evolving logic.

Empirical Results and Analysis

In-Distribution vs. Configuration Shift

Fine-tuned world models achieve strong in-distribution performance (IoU up to 91.6 for Gemma-4-31B), demonstrating effective memorization of training-regime dynamics when business rules are static. However, this performance collapses under deployment shift in CascadeBench, reverting to around 41 IoU—a minimal advantage over base model prompting with full rule context. This delineates a sharp generalization boundary for SFT approaches: internalization of enterprise transitions is not robust across diverse or unseen configurations.

On the Limits of Prompting and SFT

When deprived of business rule context, both prompted and fine-tuned models perform near chance on CascadeBench (IoU << 13), contrasting with their moderate performance in other benchmarks and emphasizing that business rules encode the critical causal dynamics. SFT offers marginal gains when context is absent, but is ineffective in substituting for the active, ground-truth configuration necessary for cross-instance generalization.

Superiority of Runtime Discovery Methods

The discovery agent architecture consistently improves multi-step state prediction accuracy over static prompting—across all rollout horizons k=1k=1 to $5$—and substantially narrows the gap to the in-context “oracle” ceiling. Figure 3

Figure 3: The Discovery Agent maintains superior IoU over prompted baselines at all rollout horizons, mitigating error compounding when retrieving transition logic on-demand.

Notably, runtime discovery is most advantageous for transitions of higher complexity (Tiers 2 and 3), where static schema reasoning is insufficient and configuration-dependent rule composition dominates. Figure 4

Figure 4: Tier-stratified assessment on CascadeBench: Prompted models suffice for simple, schema-limited effects, but exhibit steep degradation as transition cascades become more complex. Runtime discovery recovers much of the attainable information for Tiers 1 and 2.

Crucially, discovery agents can match or exceed fine-tuned models (even with no retraining) in deployment-shifted and cross-tenant scenarios. The main residual failure modes involve deep cascade resolution and record insertions, highlighting the persistent reasoning challenges for multi-step transitions even given perfect retrieval.

Implications and Future Directions

This research presents a decisive claim: in dynamically configurable enterprise settings where the transition function is explicit and inspectable, offline-trained world models alone are insufficient for reliable cross-instance or cross-tenant transition prediction. Instead, robust agents should integrate learned priors with runtime retrieval and compositional reasoning over the instance’s active configuration.

Practically, this motivates departure from monolithic, internalized simulators for enterprise automation agents, and a shift toward architectures capable of adaptive, configuration-sensitive reasoning. Theoretically, it challenges prevailing world-model paradigms for agent planning in real-world, non-stationary environments with readable dynamics. The distinction between what should be learned vs. what should be discovered at inference is particularly salient for highly customizable multi-tenant platforms (e.g., ServiceNow, Salesforce).

Future research should examine scalable methods for learning retrieval policies (when, what, and how to retrieve context), the interplay between internalization and runtime grounding, and the generalizability of these findings to other high-variability software systems. Additionally, addressing the limitations in cross-table deep cascade prediction and learning compositional multi-hop rule application remains an open area for improvement.

Conclusion

The findings of this work rigorously demonstrate that when the governing logic of an environment is both readable and non-stationary, world model approaches anchored solely in fixed transition internalization are inadequate. Enterprise discovery agents—entities that couple off-policy learning with adaptive context retrieval—exhibit superior robustness under variation in deployment configuration. These results have immediate relevance for the design and deployment of enterprise AI systems, supporting hybrid architectures that incorporate both model-based priors and runtime discovery capabilities for accurate, context-sensitive action modeling.

Paper to Video (Beta)

No one has generated a video about this paper yet.

Whiteboard

No one has generated a whiteboard explanation for this paper yet.

Explain it Like I'm 14

What is this paper about?

Imagine you’re playing a game where the rules can change from one house to another—and you’re allowed to open the rulebook before you move. This paper asks: if the rules of a computer system are written down and can be read at the moment you need them, do we really need an AI that tries to memorize the rules ahead of time?

The authors study “enterprise systems” (big software used by companies), where each customer can set up their own rules and workflows. They compare two ways an AI might predict what will happen after an action:

  • Learn the rules from past examples and try to remember them (“world models”).
  • Read the rules that are actually active right now and think through the consequences (“discovery agents”).

They also introduce a new test, called CascadeBench, to check which approach works better when rules vary across companies and change over time.

What questions did the researchers ask?

  • Can AIs that memorize how systems behave (world models) handle new companies with different, changing rules?
  • If the system’s rules are available to read, does it work better for an AI to look them up at runtime instead of relying only on memory?
  • How do different approaches compare when actions cause chain reactions (“cascades”) across the system?

How did they study it?

To make this understandable, think of a help desk ticket in a company’s system:

  • You change a ticket’s priority to High.
  • That change might trigger a rule to alert a manager, start a timer (SLA), or update other fields.
  • One small update can cause a chain reaction across the system—like knocking over one domino and watching many fall.

Here’s their approach, in simple terms:

  • They built an “Enterprise Gym” and a benchmark called CascadeBench:
    • Enterprise Gym: They set up many different fake companies with different sets of rules (like different “houses” with different rulebooks). Then they performed real actions and recorded exactly what the system changed.
    • CascadeBench: A test focused on predicting these chain reactions. It hides memorization shortcuts and focuses on reasoning: given the current state and an action, what will change next?
  • They tested three types of AI predictors: 1) Prompted baseline: A general LLM that reads some context and guesses the next changes. 2) Learned world model: A model fine-tuned (trained) on lots of past examples to “internalize” how changes usually play out. 3) Discovery agent: An AI that, at prediction time, actively looks up the current company’s rules and then reasons step-by-step about what will happen—without changing its own parameters.
  • They organized system behavior into three “tiers” of difficulty:
    • Tier 1: Simple effects you can figure out from the database design (like a default value or a required field).
    • Tier 2: Cascades driven by written rules (like “if priority increases, set escalation to true and notify manager”).
    • Tier 3: Outcomes that depend on hidden engine details (like which of several rules runs first), which are partly visible but not fully written down.

What did they find, and why does it matter?

Here are the main results, in plain language:

  • Memorizing works well only when nothing has changed:
    • Models trained on past data (world models) did great on environments similar to their training data.
    • But when they faced new companies with different rules, their accuracy dropped a lot.
  • Reading the rules at runtime makes predictions more robust:
    • Discovery agents that looked up live rules at prediction time handled new, different environments much better.
    • This advantage showed up especially when actions triggered multi-step cascades (Tier 2), because the exact rules mattered.
  • Providing the rules is a game-changer:
    • When the rules were given in the input or retrieved by the agent, all models improved, because they could anchor their reasoning in what’s actually active now.
    • Without access to rules, even strong models struggled, especially on cascades.
  • Discovery helps across multiple steps:
    • Even when predicting several steps ahead (where mistakes can snowball), discovery agents stayed more accurate than prompted models that didn’t retrieve rules, because they could keep grounding their reasoning in the live setup.

In short: in systems where rules are readable and change a lot, looking them up at runtime beats relying only on memory.

What could this change in the real world?

  • Smarter, more reliable enterprise assistants:
    • Help desk bots, IT ops assistants, and workflow planners could better predict what will happen if they change something, even as each company customizes its own rules.
  • Less retraining, more adaptability:
    • Instead of constantly retraining AI every time a company updates a rule, discovery agents can adjust on the fly by reading the current configuration.
  • A blended strategy:
    • The best future systems will probably mix both ideas: keep some learned “common sense” about typical patterns, and combine it with live rule-reading to avoid mistakes when things change.

Lastly, the authors note limits: discovery only works if the agent is allowed to read the rules and knows how to use the tools to retrieve them. Some tricky effects (like exact execution order of multiple rules) may still be hard to predict. But overall, the message is clear—when the rulebook is available and changing, read it.

Knowledge Gaps

Unresolved knowledge gaps, limitations, and open questions

Below is a concise list of what remains missing, uncertain, or unexplored in the paper, framed to guide actionable future work:

  • Cross-platform generality: All quantitative evaluation is on a single platform (ServiceNow). It is unclear whether discovery-based robustness holds on other configurable enterprise systems (e.g., Salesforce, SAP, Workday) with different rule engines and configuration models.
  • Restricted-access settings: Discovery assumes readable business rules; performance and fallback strategies under realistic access controls (partial visibility, redaction, API limits) are not evaluated.
  • Retrieval policy learning: The agent’s retrieve-then-reason loop is heuristic. How to learn when/what/how much to retrieve (and in what order) to minimize errors, token budget, and latency remains open.
  • Retrieval quality measurement: The paper does not quantify retrieval recall/precision for relevant rules, schema fragments, and records, nor how retrieval errors (false positives/negatives) drive prediction errors.
  • Indexing and scaling: No study of retrieval infrastructure (index design, sharding, freshness) for large instances with thousands of rules; scalability and performance under realistic tenant sizes remain untested.
  • Cost/latency trade-offs: End-to-end latency and cost of discovery (API calls, token usage) vs. relying on internalized models is not characterized—critical for production SLAs.
  • Tier 3 coverage: Execution-order semantics, engine-internal prioritization, concurrency, and asynchronous triggers are only partially addressed. Instrumentation or static analysis needed to capture these effects is not developed.
  • Time-based and asynchronous dynamics: SLAs, scheduled jobs, timers, and event queues introduce non-instantaneous transitions not fully evaluated by the current synchronous prediction setup.
  • Mid-episode configuration drift: The system may change while the agent reasons (admins modify rules). Robustness to live updates and mechanisms for detecting and adapting to drift are not studied.
  • Noisy/obsolete/conditional rules: Real configs include disabled, conflicting, scoped, or context-gated rules. How discovery filters non-applicable or stale artifacts and handles rule-versioning remains unexplored.
  • Safe probing: While discovery “may” use probe actions, the implemented agent avoids execution. How to design safe, sandboxed probes and quantify their benefit vs. pure read-only retrieval is left open.
  • Beyond IoU metrics: Evaluation focuses on field-diff IoU. Effects on cascade-path prediction, constraint satisfaction, side-effect localization across tables, and downstream task performance (planning/execution) are not assessed.
  • Cascade path evaluation: Although cascade paths π are recorded, there is no quantitative evaluation of predicting or explaining the causal chain—important for interpretability and debugging.
  • Representativeness of synthetic schemas: CascadeBench removes memorization but may diverge from real-world inter-table dependencies and script idioms; external validation against production-like configs is limited.
  • Dataset sufficiency and diversity: With 27k transitions across 64 worlds, sample complexity for training and the breadth of covered rule patterns vs. the 1,596 pattern catalog are not analyzed.
  • Comparative baselines: Missing comparisons to symbolic/static analysis approaches (e.g., parsing business rules into executable logic), program synthesis, or rule engine emulation as alternative to LLM-based reasoning.
  • Hybrid learning + discovery: How to integrate priors with retrieval (e.g., retrieval-augmented training, policy learning for retrieval orchestration, memory of discovered rules across tasks) is proposed but not implemented.
  • Handling partial observability: Not all determinants of transitions may be exposed (plugins, external scripts, third-party integrations). Strategies for inferring hidden factors or expressing uncertainty are not provided.
  • Uncertainty and calibration: The agent does not quantify prediction confidence or detect out-of-scope dynamics; mechanisms to defer, request more context, or switch strategies under uncertainty are absent.
  • Robustness to adversarial or malformed configs: Security and safety implications of reading untrusted configuration (prompt injection via rule text, crafted rule names) are not evaluated.
  • Token/context constraints: Effects of long rule documents and large context windows on model performance, chunking/summarization strategies, and retrieval compression are not analyzed.
  • Model-size sensitivity and training regimes: Results focus on 27–31B open-weight models with LoRA; behavior with smaller/larger backbones, full fine-tuning, and instruction-tuned models is not systematically explored.
  • Formal conditions for discovery advantage: No theoretical analysis characterizes when reading cc at inference time dominates learned dynamics (e.g., bounds under configuration shift or Bayes risk comparisons).
  • Multi-agent and concurrent changes: Interaction effects when multiple agents or users act concurrently on the same instance (race conditions, interleaving cascades) are not modeled or evaluated.
  • Compliance and privacy constraints: Practical limits on exposing configuration (PII in rules, regulatory restrictions) and how to deploy discovery agents under governance requirements are not addressed.

Practical Applications

Practical applications derived from the paper’s findings

This paper shows that in configurable enterprise environments, agents are more robust when they retrieve and reason over live configuration (business rules, workflows, SLAs) at inference time rather than relying solely on learned, fixed world models. It also introduces the Enterprise Gym/CascadeBench tooling and a three-tier taxonomy of transition complexity. Below are actionable applications grouped by deployment readiness.

Immediate Applications

  • Configuration-aware enterprise agents for safe action planning
    • Use case: Before acting (e.g., updating a ticket, changing a field), agents retrieve active business rules/SLA definitions and predict cascades to select safe, compliant actions.
    • Sectors: Software/IT (ITSM, ITOM, CRM, ERP), healthcare administration, finance operations, government services.
    • Potential tools/products/workflows: “Discovery Agent” middleware (tool-enabled LLM orchestration), rule-retriever connectors for ServiceNow/Salesforce, policy-aware action planners embedded in ticketing forms and chatbots.
    • Assumptions/dependencies: Read API access to schemas/rules/logs; reliable tool use; latency budget for retrieval; Tier 1–2 logic is machine-readable.
  • “What-if” change-impact previews (dry runs)
    • Use case: Preview the field-level state diffs and cascades an action will trigger before execution (e.g., when editing records, deploying a rule, or triggering an automation).
    • Sectors: IT operations, DevOps/CI-CD, CRM/ERP admins, MSPs.
    • Potential tools/products/workflows: Form-level “Impact Preview” widgets; CI/CD guardrails that block risky changes; PR bots that comment on predicted cascades.
    • Assumptions/dependencies: Up-to-date rule retrieval; accurate mapping from rules to field diffs; non-destructive “simulate-by-reading” mode.
  • Cross-tenant portable automations without retraining
    • Use case: Agents and automations that generalize across customers/tenants by retrieving live configuration at inference time instead of depending on a trained world model.
    • Sectors: SaaS vendors, system integrators, MSPs.
    • Potential tools/products/workflows: Multi-tenant agent SDK with configuration adapters; “bring-your-own-tenant” onboarding flows.
    • Assumptions/dependencies: Standardized configuration representations; permission boundaries respected; throttling/quotas for API calls.
  • Cascade debugging and root-cause analysis (RCA)
    • Use case: Reconstruct why a state change occurred by correlating audit logs with retrieved rule definitions and cascade paths.
    • Sectors: SRE/IT operations, regulated industries (finance, healthcare, public sector).
    • Potential tools/products/workflows: “Cascade Explorer” UI; RCA reports that trace table/field changes to specific business rules.
    • Assumptions/dependencies: High-quality audit logs; rule-to-change attribution metadata; log retention/compliance.
  • Test generation and coverage for business rules
    • Use case: Automatically generate regression tests covering rule branches and cascades; detect gaps as rules evolve.
    • Sectors: QA for enterprise applications; platform engineering.
    • Potential tools/products/workflows: Test-case generators that read rules and seed records; coverage reports for Tier 1–2 transitions; integration with existing test frameworks.
    • Assumptions/dependencies: Deterministic rule evaluation in test sandboxes; seeded initial states; mapping of conditions to test inputs.
  • Inline compliance and approval checks
    • Use case: Pre-flight compliance validation (e.g., approvals, segregation-of-duties, SLA adherence) by interpreting current approval policies and SLAs before an action is executed.
    • Sectors: Finance (SOX), healthcare (HIPAA), government (FedRAMP), large enterprises with internal governance.
    • Potential tools/products/workflows: Policy-as-code mappers from rule records; “Compliance Preview” in workflow designers; continuous controls monitoring via discovery.
    • Assumptions/dependencies: Policies encoded in rules or mappable from them; up-to-date policy catalogs; access controls allow read-only inspection.
  • Retrieval-augmented reasoning for enterprise support
    • Use case: Support assistants that fetch relevant business rules and schemas to answer “why did X happen?” or “what will Y do?” more accurately.
    • Sectors: Customer support, IT service desks, internal enablement.
    • Potential tools/products/workflows: Vector indices for rules; retrieval chains that filter to task-relevant rules c̃; response templates citing rule sources.
    • Assumptions/dependencies: Continual re-indexing as configurations change; prompt/tool reliability; PII redaction.
  • Benchmarking and academic evaluation using CascadeBench
    • Use case: Evaluate agents’ robustness to configuration/deployment shift independent of memorized schemas; compare prompting, fine-tuning, and discovery.
    • Sectors: Academia, AI research groups, enterprise AI R&D.
    • Potential tools/products/workflows: Adoption of CascadeBench and Enterprise Gym for model evaluation; tier-stratified reporting and ablations.
    • Assumptions/dependencies: Public or licensed access to the benchmark; reproducible setup; compute resources.
  • Safer personal and SMB automations (daily life)
    • Use case: In smart home platforms (e.g., Home Assistant, IFTTT) or SMB tools, preview and explain automation cascades by reading active automations.
    • Sectors: Smart homes, small businesses, facilities.
    • Potential tools/products/workflows: “Automation Impact Preview” in rule editors; conflict detectors for overlapping automations.
    • Assumptions/dependencies: Exposed, readable automations; connectors; execution-order semantics may limit Tier 3 prediction.

Long-Term Applications

  • Hybrid agents that learn “when/what/how” to retrieve
    • Use case: Combine learned priors with runtime discovery so agents adaptively decide if retrieval is needed, which artifacts to fetch, and how to compose them.
    • Sectors: Enterprise AI platforms; autonomous operations.
    • Potential tools/products/workflows: Retrieval-aware planners; RL/meta-learned retrieval policies; cost/latency–accuracy trade-off optimizers.
    • Assumptions/dependencies: Training datasets with retrieval supervision; telemetry to learn retrieval policies; sustained tool reliability.
  • Platform standards and policy for rule observability
    • Use case: Industry standards mandating read-only, auditable APIs for business rules/workflows to enable safe AI agents and compliance.
    • Sectors: Policy/regulation, SaaS vendors, standards bodies.
    • Potential tools/products/workflows: “RuleBOM”/“ConfigBOM” artifacts analogous to SBOMs; auditability schemas; certification programs.
    • Assumptions/dependencies: Vendor buy-in; security reviews; alignment with privacy requirements.
  • Tier 3 (execution semantics) inference and verification
    • Use case: Resolve execution-order and engine-internal behaviors via formal methods and non-destructive probe experiments to close the gap where static artifacts are insufficient.
    • Sectors: Safety-critical IT, healthcare, fintech, government.
    • Potential tools/products/workflows: Probe schedulers; partial-order/temporal logic verification for workflow engines; causal inference over logs.
    • Assumptions/dependencies: Safe sandboxing; engine instrumentation; agreement on probe safety/risk scoring.
  • Autonomous, policy-governed operations (“autopilot” agents)
    • Use case: Agents that continuously retrieve rules, plan actions, verify compliance, execute safely, and adapt to configuration changes without retraining.
    • Sectors: Cloud/IT operations, fintech operations, hospital administration.
    • Potential tools/products/workflows: Closed-loop controllers with discovery hooks; explainability dashboards tying actions to rules/policies.
    • Assumptions/dependencies: High availability of APIs; robust fallback/kill-switches; strong audit trails and human-in-the-loop oversight.
  • Cross-platform discovery SDKs (beyond one vendor)
    • Use case: Generalize discovery agents to CRM (Salesforce), ERP (SAP), EHR (Epic/Cerner), building management systems, and industrial control platforms.
    • Sectors: Software, healthcare, manufacturing, energy/buildings.
    • Potential tools/products/workflows: Connector libraries for rule/schema retrieval; unified configuration ontology; adapter patterns.
    • Assumptions/dependencies: Vendor APIs and licensing; variability in configuration models; careful PII/PHI handling.
  • Migration/upgrade “change twin” simulators
    • Use case: Predict behavior after rule changes or platform upgrades by comparing cascades across versions/branches and suggesting remediations.
    • Sectors: Large enterprises, MSPs, platform vendors.
    • Potential tools/products/workflows: Differential cascade visualizers; automated rule refactoring suggestions; upgrade risk scoring.
    • Assumptions/dependencies: Versioned rule stores; high-fidelity sandboxes; mapping between legacy and new execution semantics.
  • Retrieval economics and scheduling optimization
    • Use case: Optimize retrieval frequency, breadth, and depth to balance latency, cost, and accuracy for production agents.
    • Sectors: AI platform engineering, FinOps.
    • Potential tools/products/workflows: Telemetry-driven retrieval schedulers; caching layers; budget-aware planning.
    • Assumptions/dependencies: Rich runtime metrics; cost-accounting hooks; service-level objectives.
  • Workforce education and curriculum on cascade reasoning
    • Use case: Training programs that use Enterprise Gym/CascadeBench to teach rule composition, cascade prediction, and safe automation design.
    • Sectors: Academia, corporate training, professional certifications.
    • Potential tools/products/workflows: Courseware, labs, certification exams based on tiered transition complexity.
    • Assumptions/dependencies: Stable benchmark access; instructor resources.
  • Continuous security posture and misconfiguration detection
    • Use case: Discover misconfigured or conflicting rules that create security or privilege-escalation pathways; prioritize fixes based on cascade risk.
    • Sectors: Enterprise security, GRC.
    • Potential tools/products/workflows: Rule linters, conflict detectors, risk dashboards tied to discovery outputs.
    • Assumptions/dependencies: Comprehensive rule visibility; defined risk models; SOC integration.
  • Energy/building automation and digital twin alignment
    • Use case: In building/facility management systems, retrieve automation graphs to predict cascades from setpoint changes and align with digital twins.
    • Sectors: Energy, smart buildings, industrial IoT.
    • Potential tools/products/workflows: “Setpoint impact” previews; BAS rule introspection adapters; twin consistency checks.
    • Assumptions/dependencies: Standardized BAS models (e.g., Project Haystack/Brick); vendor APIs; safe test environments.

Notes on feasibility across all applications:

  • The approach presumes read access to live configuration; without it, discovery degenerates to the prompted baseline.
  • Reliability hinges on tool-use competence of the underlying LLM and the freshness/quality of retrieved artifacts and logs.
  • Execution-order and engine-internal behaviors (Tier 3) may remain only partially observable; safe probe mechanisms and/or vendor support are often required.
  • Privacy and access control constraints (e.g., PII/PHI) must be respected via redaction, scoping, and least-privilege access.

Glossary

  • Access control lists: Permission lists that define which users or roles can access specific resources or operations in an enterprise system. "access control lists deployed on a particular customer's instance"
  • Audit logs: System-generated records that chronologically capture actions and resulting changes, used here to trace cascades and ground truth transitions. "recording the resulting cascades through platform audit logs."
  • Business rules: Declarative, configurable logic that governs automated actions and cascades in enterprise workflows. "real business rules execute"
  • Cascade path: The ordered trace of tables and rules traversed by a triggered cascade resulting from an action. "the cascade path: the ordered sequence of tables touched and business rules attributed to each transition."
  • CascadeBench: A benchmark designed to evaluate robustness and reasoning for enterprise cascade prediction under configuration and deployment shift. "We introduce CascadeBench, a reasoning-focused benchmark for enterprise cascade prediction"
  • Configuration artifacts: Deployable, tenant-specific objects (e.g., rules, workflows) that determine system behavior. "tenant-specific configuration artifacts, such as business rules and workflows"
  • Configuration shift: Changes in the deployed configuration (rules, workflows, policies) that alter transition dynamics and stress model robustness. "robustness under configuration and deployment shift"
  • Contextual transition model: A dynamics formulation where next-state transitions depend on state, action, and the active instance configuration. "We formalize this as a contextual transition model."
  • Deployment shift: Variation across different deployed instances (tenants) that causes learned models to degrade when moved across environments. "brittle under deployment shift."
  • Distribution shift: Mismatch between the training distribution and test/deployment conditions that harms model performance. "reduce robustness under distribution shift."
  • Enterprise discovery agents: Agents that recover transition logic at inference time by reading live configuration instead of relying solely on learned dynamics. "We propose enterprise discovery agents"
  • Enterprise Gym: A live, non-simulated environment suite where worlds are deployed to collect ground-truth transitions via the real platform engine. "collected from Enterprise Gym"
  • Execution-order resolution: Engine-specific semantics that determine the order and outcome when multiple rules interact, affecting observed transitions. "execution-order resolution and other engine-internal behaviors"
  • Grounding (predictions): Anchoring predictions to the active system instance by using live configuration and state instead of only internalized knowledge. "by grounding predictions in the active system instance."
  • In-distribution: Evaluation regime where test data matches the training configuration, often yielding higher performance than under shift. "perform well in-distribution but degrade as dynamics change"
  • Instance configuration: The deployed set of rules, workflows, policies, SLAs, and ACLs that define a tenant’s runtime behavior. "the instance configuration (the collection of all business rules"
  • IoU (Intersection over Union): A set-overlap metric used to compare predicted field-level diffs against ground truth; strict IoU requires exact value matches. "Strict IoU additionally requires the predicted value to match"
  • IoU(T+F): A table-and-field-level IoU variant that credits correct identification of which table/field pairs change, regardless of exact values. "IoU(T+F) credits a prediction when it correctly identifies the affected (table, field) pair"
  • Latent dynamics: Learned internal representations of environment evolution that support planning without predicting raw observations directly. "which learn latent dynamics to support planning and policy optimization."
  • LoRA: A parameter-efficient fine-tuning method that adapts large models via low-rank updates. "with LoRA"
  • Model-based reinforcement learning: A paradigm that separates a learned dynamics model from control/planning to improve sample efficiency and foresight. "forming the foundation of model-based reinforcement learning."
  • Multi-tenant: A platform architecture where multiple customers (tenants) share infrastructure but differ in configuration, inducing cross-tenant variability. "multi-tenant enterprise environments"
  • Oracle (for retrieval): An evaluation setting where the relevant rules are provided directly in the prompt, serving as an upper bound for discovery. "w/ BR supplies the relevant business rules in the prompt (an oracle for retrieval)"
  • Retrieve-then-reason: An inference strategy where the agent first fetches relevant configuration/context and then reasons to predict outcomes. "the discovery agent follows a retrieve-then-reason strategy."
  • Rollout horizon: The number of future steps over which predictions are sequenced, with accuracy typically degrading as depth increases. "as the rollout horizon increases"
  • Sandboxes: Isolated execution environments used to safely run candidate actions and collect clean traces. "executed in isolated sandboxes"
  • Service Level Agreements (SLAs): Formalized service performance contracts whose timers and states can be triggered and tracked during cascades. "Service Level Agreements (SLAs)"
  • State delta: The subset of state that changes between consecutive steps, modeled as the difference from pre- to post-action state. "we effectively model a state delta, Δ s_t, roughly corresponding to s_{t+1} − s_t"
  • State diff: The structured representation of field-level changes predicted or observed after an action. "a state diff over a database with thousands of fields"
  • sys_audit: A platform audit table used to recover causal state changes resulting from executed actions. "recovered from sys_audit"
  • Synthetic schemas: Artificially constructed table structures used to prevent memorization and focus evaluation on reasoning. "built on synthetic schemas that do not appear in real platform deployments"
  • Tenant-specific: Pertaining to configuration or logic customized per customer instance, leading to differing dynamics across deployments. "tenant-specific business logic"
  • Transition complexity: A tiered taxonomy of difficulty for predicting effects, from schema-determined to rule-composed and execution-dependent. "three levels of transition complexity"
  • World models: Predictive models that internalize environment dynamics to anticipate the effects of actions for planning and reasoning. "World models enable agents to anticipate the effects of their actions"
  • World of Workflows (WoW): A benchmark that evaluates agents’ ability to predict state transitions and constraints in enterprise workflows. "World of Workflows (WoW)"

Open Problems

We haven't generated a list of open problems mentioned in this paper yet.

Collections

Sign up for free to add this paper to one or more collections.

Tweets

Sign up for free to view the 9 tweets with 77 likes about this paper.