Executable Policy Specification Problem

• Executable Policy Specification Problem is the challenge of turning informal or underspecified human intent into machine-checkable artifacts.
• Different domains implement this problem using distinct executable artifacts, from BPMN workflows to authorization models and controller action maps.
• Robust validation, repair, and verification methods—such as simulation-based diagnostics and closed-loop feedback—ensure that semantic intent is preserved during execution.

Searching arXiv for papers relevant to executable policy specification across workflows, security policies, robotics, and formal specifications. The Executable Policy Specification Problem is the problem of turning an informal, underspecified, or context-dependent statement of intended behavior into an artifact that a machine can execute, verify, and, in many cases, audit or repair. Across the literature, this problem appears in several guises: natural-language health policies mapped to executable BPMN workflows, user-specific security preferences induced from examples, standards-based access-control policies compiled into authorization engines, goal-only instructions translated into host-side plans, robot checkpoints completed into controller-facing action laws, and software requirements rendered as executable contracts or specification functions (Matei et al., 13 Apr 2026, Nadkarni et al., 2017, Plaza-Ortiz et al., 30 May 2025, Tai, 2 Jun 2026). A common theme is that executability alone is insufficient: the specification must also preserve semantic intent, delimit admissible behavior, and remain stable under execution, regeneration, or deployment context.

1. Problem formulation and scope

In workflow digitalization, the problem is framed as whether a natural-language policy is sufficiently determinate that repeated runs of the same text-to-BPMN pipeline yield behaviorally consistent executable models, even when no gold BPMN model exists (Matei et al., 13 Apr 2026). In security policy authoring, it appears as the problem of obtaining runtime allow/deny decisions from user-labeled examples when developers cannot predefine all relevant distinctions; the executable policy is then the learned decision procedure itself rather than a handwritten rule set (Nadkarni et al., 2017). In Data Spaces, the problem is that ODRL provides a standard policy vocabulary but not an inherent execution model, so policy specifications must be compiled into an executable authorization substrate such as OpenFGA (Plaza-Ortiz et al., 30 May 2025).

The same underlying difficulty recurs in agentic and embodied systems. Host-acting agents receive benign but goal-only instructions that leave process constraints, safety boundaries, persistence, and exposure insufficiently specified; the agent must perform semantic completion before acting, and that completion may produce a security-divergent plan (Lu et al., 22 Mar 2026). Vision-language-action deployments reveal a narrower but highly concrete variant: a policy is not fully specified by checkpoint weights and prompts, because action unnormalization metadata and controller-facing conventions change the physical action law (Tai, 2 Jun 2026). Embodied jailbreak research sharpens the distinction further by showing that harmful language is not equivalent to a harmful policy, and a harmful policy is not equivalent to an executable harmful behavior (Lu et al., 2024).

This suggests a unifying interpretation: the Executable Policy Specification Problem concerns the gap between an intended norm, goal, or behavioral requirement and the full operational object that actually governs execution. That object may be a workflow, a nearest-neighbor decision rule, an authorization model plus tuples, a controller-facing action map, a pre/postcondition pair, or a formal transition system. What matters is not the surface representation alone, but whether the representation is sufficiently complete to determine admissible executions.

2. Forms of executable specification

The literature does not converge on a single executable substrate. Instead, it presents a family of specification forms whose common property is that they induce machine-checkable behavior.

Domain	Executable artifact	Illustrative papers
Process and workflow policy	BPMN XML plus simulation-derived KPI vectors	(Matei et al., 13 Apr 2026)
Example-based security policy	Target-specific labeled scenarios, tag weights, and nearest-neighbor decision rule	(Nadkarni et al., 2017)
Data Spaces authorization	ODRL/ODS compiled to OpenFGA authorization model and relationship tuples	(Plaza-Ortiz et al., 30 May 2025)
Robot deployment	$$\Pi_{\mathrm{exec}}=(f_\theta,\mathcal I,\mathcal Z,\mathcal U_k,\mathcal C)$$	(Tai, 2 Jun 2026)
Capability engineering	PredicateGraph plus CPL policies or rubric-conditioned verifiers	(Ball, 15 Dec 2025)
Behavioral software contracts	Executable Python preconditions and postconditions functions	(Chen et al., 14 Apr 2026)
Clinical protocol logic	Pure Prolog with CLP($\mathbb{Z}$) regret-constrained specification	(Norris et al., 2024)
Open normative systems	$\mathcal{C}+$ action descriptions executed by Ccalc	(Artikis, 2010)

These forms differ sharply in expressiveness and semantics. BPMN-centered work emphasizes control-flow stability under repeated generation and simulation (Matei et al., 13 Apr 2026). PyBE uses scenarios as conjunctions of tags and gives the policy operational semantics through a weighted nearest-neighbor mechanism with deterministic tie handling (Nadkarni et al., 2017). ODRL Data Spaces preserves ODRL’s declarative vocabulary but treats execution as a compilation pipeline into backend authorization models and tuples rather than as direct rule interpretation (Plaza-Ortiz et al., 30 May 2025). CAPE interposes a structured intermediate representation, PredicateGraph, so that policies can refer to claims, operations, tool calls, citations, and code blocks through a terminating, deterministic policy language (Ball, 15 Dec 2025).

Formal-methods work makes the executable substrate even more explicit. The Prolog specification of the oncology 3+3 protocol represents trial decisions as consequences of CLP($\mathbb{Z}$) regret constraints rather than imperative flowcharts (Norris et al., 2024). Dynamic protocol specification in open multi-agent systems uses $\mathcal{C}+$ causal laws to model institutional power, permission, obligation, sanctions, proposals, and run-time rule change as a transition system (Artikis, 2010). Behavioral Programming extends executable modular requirements with mustFinish labels so that liveness properties can be executed via Büchi- or MDP-based mechanisms (Yaacov et al., 2024). High-level distributed-algorithm work in DistAlgo shows that control flow and synchronization conditions can remain close to the natural protocol description while still being executable and translatable into TLA+ proofs (Liu et al., 2017).

A plausible implication is that executable policy specification is less a single formalism than a design space. The recurring architectural pattern is to introduce an intermediate artifact whose semantics are explicit enough to run, analyze, and compare, yet close enough to the source intent to remain reviewable.

3. Validation, determinacy, and verification

A central research question is how to determine whether an executable specification is adequate. The answers vary according to what kind of adequacy is sought.

In automated process modeling, adequacy is framed as behavioral determinacy under repeated machine interpretation. A policy text is treated as ambiguous when it “admits multiple logically coherent executable interpretations with different simulated behavior,” and the empirical distribution of KPI outcome vectors across regenerated BPMN models is summarized by normalized Shannon entropy as a heuristic consistency measure (Matei et al., 13 Apr 2026). Diagnosis then localizes divergence to gateway logic by comparing traces, constructing conflict sets between the last matching and first mismatching KPI-producing tasks, and computing minimal hitting-set diagnoses.

In action formalisms over core-closed knowledge bases, adequacy is expressed as structural validity and property preservation. A successor state must be core-complete and open-consistent, and static verification asks whether an action $\gamma$ preserves a Must/May query $q$ over a knowledge base for all parameter instantiations (Cauli et al., 2022). Bounded-domain plan existence then reduces to graph reachability over the generated transition system, while minimal plan synthesis is performed by a depth-first search that returns exactly the minimal plans.

In code specification generation, adequacy is split into correctness and completeness. A generated executable behavioral specification is correct if it accepts valid behaviors and complete if it rejects invalid behaviors. CodeSpecBench measures strict pass rate as the proportion of generated specifications satisfying both criteria under execution-based evaluation, and reports a sharp degradation on repository-level tasks, where the best model attains only a 20.2% pass rate (Chen et al., 14 Apr 2026). The benchmark’s most important methodological contribution is the insistence that specification quality be judged by behavior discrimination under execution, not by surface resemblance.

Program-repair work pushes the validation problem one step earlier, to inferred intent itself. Prometheus reconstructs Gherkin specifications from runtime failure reports and uses the Requirement Quality Assurance Loop—also called “Sandwich Verification”—to accept a candidate specification $S$ only if $\mathrm{Exec}(S,C_{buggy})=\mathrm{fail}$ and $\mathrm{Exec}(S,C_{fixed})=\mathrm{pass}$ (Wang et al., 19 Apr 2026). This makes requirement validity a binary executable predicate rather than an informal prompt output.

Debugging executable specifications is itself treated as a verification problem in VDM-SL. Specification slicing defines a static backward slice for criterion $\mathbb{Z}$0 as the subset of AST nodes that may influence the value of expression $\mathbb{Z}$1 in operation $\mathbb{Z}$2, and computes it by reverse traversal, read/write tracking, and control-dependency propagation through branches and loops (Oda et al., 2024). This suggests that verification of executable policies often benefits from source-level explanation mechanisms, not only model-level checking.

4. Runtime context, embodiment, and executable semantics

Several papers argue that the executable policy is only fully specified once runtime context is fixed. In host-acting agents, the central issue is semantic under-specification: the user specifies an outcome, but the system must invent missing execution semantics concerning privilege ceilings, persistence, exposure, resource scope, and acceptable repair cost (Lu et al., 22 Mar 2026). The threat is endogenous rather than adversarial: a plan may be on-task yet out-of-policy because boundary conditions were never made explicit.

In robot deployment, the same point is sharpened into a formal identity claim. A vision-language-action deployment is specified by $\mathbb{Z}$3, and executable equivalence requires equality of the controller-facing action law under every history, not merely equality of weights or normalized outputs (Tai, 2 Jun 2026). For quantile-style unnormalization, the paper derives a closed-form metadata displacement transform and defines static ExecSpec certificates,

$\mathbb{Z}$4

and

$\mathbb{Z}$5

to quantify action-space semantic drift without rollout.

Embodied policy execution can also be mediated through language. In VirtualHome, a Scene Understanding Module converts visual observations into textual summaries, and an Action Prediction Module generates executable textual action programs of the form [[action_i] <object_i> (id_i), ...]; a program is deemed executable if the simulator can understand and perform it (Qiu et al., 2023). This is an explicitly language-mediated path from perception to executable policy.

Security work on embodied jailbreaks adds another runtime layer. POEX distinguishes harmful language, harmful policy, and executable harmful policy, and operationalizes executability through API-format compatibility and a policy evaluator that scores generated policies from 0 to 4, with scores 3 or 4 treated as executable (Lu et al., 2024). Its combined loss couples jailbreak success with policy executability, showing that embodied policy attack and defense must reason over the chain from instruction to policy to physical execution.

Supply-chain security generalizes the same execution-bound principle beyond robotics. In execution-bound advisory automation, exploitability is computed from presence, activation, and feasibility, where feasibility depends on enforced execution policies such as network egress restrictions, RBAC, and isolation settings (Radanliev et al., 16 Jun 2026). This suggests that, in many domains, executable policy semantics are incomplete unless they include both the artifact being executed and the environment that constrains how execution can occur.

5. Repair, refinement, and learning loops

A distinctive feature of recent work is the shift from one-shot specification authoring to closed-loop diagnosis-and-repair.

The BPMN ambiguity framework is explicitly diagnosis-driven. It detects behavioral inconsistency from KPI dispersion, localizes divergence to gateways, maps those gateways back to verbatim narrative segments, and then performs constrained text repair through four steps: ambiguity localization and mapping, evidence-based interpretation selection, minimal disambiguation synthesis, and narrative reconstruction (Matei et al., 13 Apr 2026). In the reported diabetic nephropathy studies, regeneration from the repaired City 1 text caused more than 90% of the 100 generated models to produce the same KPI outcome, while the repaired City 2 text produced 70% concentration on a single KPI outcome class.

PyBE treats policy specification as a repairable example set. It defines two nearest-neighbor graph invariants—majority-label existence among a node’s neighbors and agreement between a node’s label and that majority—and greedily recommends relabelings that maximally reduce invariant violations (Nadkarni et al., 2017). In the feasibility study, 96 labeling errors were identified among 1,230 examples, and the PyBE-assisted review found 80 of them, about 83%.

CAPE generalizes this repair loop into a post-training protocol. Its Specify $\mathbb{Z}$6 Verify $\mathbb{Z}$7 Correct $\mathbb{Z}$8 Train cycle converts requirement $\mathbb{Z}$9 into an executable policy $\mathcal{C}+$0 or rubric, verifies outputs against $\mathcal{C}+$1, corrects violating outputs, re-verifies the corrections, and fine-tunes on verified-correct examples (Ball, 15 Dec 2025). The paper reports that across 109,500 examples in six domains, CAPE reduces violation rates by 81 percent relative to DPO, with CAPE (frontier) at 2.5% versus DPO at 13.1%, and argues that reusable specifications change the scaling behavior of post-training because verification accuracy improves with model scale rather than saturating at preference disagreement.

Prometheus applies the same philosophy to automated program repair. Instead of generating a patch directly from a failure report, it first reverse-engineers an executable Gherkin contract, validates that contract in the RQA loop, and only then performs “Enlightened Repair” under the accepted specification (Wang et al., 19 Apr 2026). On 680 Defects4J defects, the framework reports a total correct patch rate of 93.97% (639/680) and a Rescue Rate of 74.4% on bugs that the blind baseline failed to repair.

These systems differ in domain and substrate, but they share a structural claim: executable policy quality improves when the system validates the specification artifact itself, not only the downstream behavior it induces.

6. Limits, misconceptions, and open questions

A persistent misconception is that executability implies correctness. The process-modeling literature states this explicitly: repeated generations may converge on one wrong interpretation, yielding high consistency despite semantic error (Matei et al., 13 Apr 2026). Robot-deployment work makes the same point from the opposite direction: identical weights and normalized outputs do not imply the same executable policy once metadata-selected unnormalizers and controller conventions are considered (Tai, 2 Jun 2026). CodeSpecBench reinforces the distinction by showing that specification generation is substantially more difficult than code generation, so strong coding performance does not necessarily reflect deep understanding of intended program semantics (Chen et al., 14 Apr 2026).

A second misconception is that policy meaning resides entirely in the policy syntax. Data Spaces work shows that ODRL-based authorization needs a compilation target and runtime relationship graph to become enforceable, while several normative constructs—duties, retention semantics, prohibition conflicts, and lifecycle controls—remain only partially specified in the current executable path (Plaza-Ortiz et al., 30 May 2025). Execution-bound advisory automation similarly argues that exploitability cannot be inferred from SBOM or AIBOM presence alone, because activation conditions and policy-constrained feasibility determine whether a vulnerability is actually actionable (Radanliev et al., 16 Jun 2026).

A third misconception is that underspecification is merely a linguistic defect. Host-agent research reframes the problem as missing execution semantics rather than wording ambiguity alone: convenience-oriented goal statements silently delegate boundary choices about privilege, persistence, and exposure to the planner (Lu et al., 22 Mar 2026). This suggests that future policy languages for agents may need first-class constructs for boundary profiles rather than relying on unstructured prompts.

Several open problems recur across the literature. Rich formal semantics are often incomplete: ODRL Data Spaces does not provide a full execution account for duties or conflict handling (Plaza-Ortiz et al., 30 May 2025); CAPE’s strongest results hold on requirements that can be made contextually objective and policy-addressable (Ball, 15 Dec 2025); Prometheus notes that BDD captures explicit behavioral intent more readily than hidden protocol or serialization semantics (Wang et al., 19 Apr 2026). Scalability remains delicate: bounded-domain action planning is decidable but unbounded plan existence is undecidable in the core-closed knowledge-base setting (Cauli et al., 2022), and exact symbolic execution of liveness in Behavioral Programming motivates an MDP and DRL route for larger systems (Yaacov et al., 2024). Tooling for explanation is also unfinished: VDM-SL slicing is practical and integrated into ViennaTalk, but the paper does not establish a full formal minimality or semantic-preservation theorem for the extracted slice (Oda et al., 2024).

Taken together, these results suggest that the Executable Policy Specification Problem is not a single defect in policy authoring but a family of alignment problems between human intent and machine-interpretable operational artifacts. The literature converges on a stable core thesis: executable policies must be explicit enough to run, structured enough to verify, contextual enough to preserve meaning, and auditable enough to diagnose and repair when execution reveals that the original specification was incomplete.