Code-Only-as-Policy (COAP)

• Code-Only-as-Policy (COAP) is a paradigm where executable code itself outlines and enforces policies, integrating with various systems such as decision rules, robotic manipulation, and infrastructure governance.
• COAP implementation encompasses various forms like executable rules, typed propositions, signed capabilities, and fully stateful code, each offering unique guarantees and scopes of enforcement.
• Key applications of COAP include adaptive IT governance, mission compilation, and improving evidence recovery and automated task generation in dynamic robotics.

Code-Only-as-Policy (COAP) is a policy-design paradigm in which executable code constitutes the authoritative operational representation of a policy, rather than merely storing policy text or implementing a separate policy language. In its strongest form, policy conditions are encoded as types or propositions, and execution requires typed evidence that those conditions hold (Fuchs, 2 Jun 2025). In embodied systems, COAP denotes policies whose perception, state tracking, task logic, recovery behavior, and action selection are implemented in executable programs rather than selected by a model during every control step (Hu et al., 8 Oct 2026). Across authorization, infrastructure governance, federated computing, mission compilation, robotic manipulation, and agentic tool use, COAP encompasses a spectrum ranging from executable decision rules to fully stateful code that governs runtime behavior.

1. Conceptual scope and defining distinctions

COAP is commonly distinguished from two weaker interpretations of “policy as code.” Under source-code storage, a policy happens to be stored in a source-code repository, but its enforcement semantics may remain external or undocumented. Under policy-language implementation, a policy engine or interpreter is implemented in a programming language, while the policy itself remains a separately interpreted artifact. COAP in the stronger sense makes executable code, typed interfaces, or proof-bearing artifacts part of the enforcement boundary.

The central distinction can be summarized as:

$$\text{policy condition} \rightarrow \text{executable representation} \rightarrow \text{enforced behavior}.$$

The representation may be a Rego rule, a dependent proposition, a signed capability, a compiled workflow artifact, a stateful robot program, or a guarded tool interface. These implementations differ substantially in guarantees and scope.

“Policy as Code, Policy as Type” presents the strongest static formulation. Its Policy as Type (PAT) approach identifies a policy with a type or proposition and an authorized action with a program term inhabiting that type:

$$\text{policy} \equiv \text{type or proposition}, \qquad \text{authorized action} \equiv \text{program term inhabiting that type}.$$

For a request predicate $P(r,s,o,e)$, where $r$ is the operation, $s$ the principal, $o$ the resource, and $e$ the environment, authorization is represented by a proof term:

$p : P(r,s,o,e).$

Protected code accepts only values paired with such evidence. Static violations therefore fail type checking, while dynamic inputs require decision procedures that return either proof-bearing values or failure (Fuchs, 2 Jun 2025).

Other systems use a less stringent interpretation. ARPaCCino generates Rego from natural-language requirements, validates it, evaluates infrastructure, and performs remediation. It therefore provides a code-centered operational policy model, but natural language remains the input and review layer, and semantic validation relies on an external human or domain-expert oracle (Romeo et al., 11 Jul 2025). An empirical study of open-source adoption similarly defines Policy-as-Code as executable rules evaluated by a dedicated engine, but its repository-level evidence includes policy files, configurations, examples, and artifacts whose active runtime enforcement is not always demonstrated (Foalem et al., 9 Jan 2026).

The term COAP therefore covers a continuum:

Formulation	Primary artifact	Principal guarantee
Executable rule policy	Rego, Sentinel, Cedar, YAML interpreted by an engine	Deterministic evaluation
Typed policy	Dependent proposition and proof term	Type-directed admission
Capability policy	Signed capability and proof of possession	Local cryptographic verification
Compiled policy	Accepted input transformed into typed or deployment artifacts	Gated code generation
Stateful code policy	Explicit program state and control logic	Runtime decision control
Guarded tool policy	Tool-layer validation, transformation, confirmation, or denial	Enforcement independent of prompt recall

A code representation does not by itself guarantee that the encoded policy matches organizational intent, that external facts are truthful, or that execution cannot bypass the code. Those properties depend on the trust boundary, runtime, attributes, compiler, tool interface, and governance process.

2. Type systems, executable rules, and proof-carrying authorization

The type-theoretic formulation of COAP uses dependent types, propositions-as-types, dependent pairs, constructive negation, and decidability. A dependent type contains a term in its definition; for example, Vec A n represents a vector of elements of type A whose length is exactly $n$. The same mechanism allows a security property to depend on the particular object being protected, so GoodProtos db and GoodProtos app are distinct propositions (Fuchs, 2 Jun 2025).

A policy proposition may be introduced by constructors that specify sufficient evidence. For example, a transport policy can be represented as:

$P(r,s,o,e)$3

with a constructor requiring proof that the protocol is HTTPS:

$P(r,s,o,e)$4

A successful proof is not merely a Boolean result. It is a value usable by subsequent code. A protected function can therefore require dependent pairs such as:

$P(r,s,o,e)$5

An arbitrary transport value cannot be passed to the operation without an accompanying proof.

The same structure expresses ABAC policies over users, objects, services, transports, payloads, and environments. In the video-service example, typed propositions encode a time-of-day constraint, age or parental authorization, HTTPS transport, approved service status, and response binding. The operation safeCall accepts only values paired with the corresponding proofs. A wrapper preCall acquires these proofs sequentially and returns nothing if a condition fails.

The approach supports both compile-time and runtime enforcement. Compile-time-known values can be normalized by the type checker, so a proof such as:

$P(r,s,o,e)$6

may compile, while an analogous proof for a server exposing telnet fails. Runtime-loaded configurations require decision procedures such as:

$P(r,s,o,e)$7

The successful branch contains a server and a proof that it satisfies the policy. The resulting architecture is hybrid:

$$\text{static proof checking} + \text{runtime evidence acquisition} + \text{typed enforcement boundary}.$$

The principal benefit is stronger coupling between decision and enforcement than an oracle model in which an application queries a policy engine, receives a Boolean, and must correctly interpret and obey it. The principal limitation is that type correctness establishes conformity to the encoded proposition, not correctness of the proposition’s business meaning. A type-correct policy may authorize too much, use an untrusted attribute, or encode an incorrect relationship.

Dependent types also support policy analysis and regression proofs. The paper proves disjointness and completeness of protocol categories, so adding a protocol without classifying it or assigning it to conflicting categories can break compilation. Such regression proofs differ from regression tests: a test checks selected executions, whereas a proof remains a term that must inhabit a formal proposition.

3. Policy engines, generation pipelines, and empirical adoption

Rego-based systems represent a more conventional executable-policy model. Rego policies evaluate structured inputs and produce outcomes such as denial messages. ARPaCCino extends this model with LLM-based synthesis, Retrieval-Augmented Generation, external rule checking, infrastructure preprocessing, deterministic evaluation, and iterative remediation (Romeo et al., 11 Jul 2025).

Its workflow is:

$$\text{policy} \equiv \text{type or proposition}, \qquad \text{authorized action} \equiv \text{program term inhabiting that type}.$$0

The system uses OPA and documentation for Terraform and the ProxMox provider. Terraform plans are converted to JSON and evaluated against generated Rego. The LLM orchestrates retrieval, policy generation, rule checking, infrastructure preprocessing, violation analysis, and correction. OPA-style evaluation remains the deterministic enforcement boundary; the LLM does not directly make the final compliance decision.

The evaluation compared LLM-only, LLM plus RAG, and full Agentic RAG configurations using Qwen3:30b, GPT-4o, and Claude Sonnet 4 across five prompts. Qwen3:30b and GPT-4o produced no syntactically correct policies in the LLM-only and RAG configurations, while the full Agentic RAG configuration achieved 4/5 for Qwen3:30b and 5/5 for GPT-4o. Claude Sonnet 4 achieved 5/5 across all three configurations. The study therefore indicates that tool-based checking and iterative correction were important for the tested models, while RAG alone did not solve policy-generation failures.

The system remains a hybrid rather than a strictly code-exclusive model. Natural language specifies intent, an expert or oracle checks semantic validity, and generated Rego depends on input schemas, preprocessing, OPA semantics, and provider documentation. A syntactically valid rule can still inspect the wrong path, omit a resource class, or express an incomplete interpretation of the requirement.

A large-scale empirical study examined Policy-as-Code adoption in 399 GitHub repositories using nine tools: OPA, HashiCorp Sentinel, Pulumi CrossGuard, Cedar, Kyverno, Cloud Custodian, AWS Config, Gatekeeper, and Kubewarden (Foalem et al., 9 Jan 2026). The initial search produced 6,010 candidate repositories, reduced to 5,942 after duplicate removal and then to 399 repositories using activity and popularity filters. The study identified 12,152 policy-related files and sampled 373 for qualitative analysis.

OPA accounted for 62% of policy-related files and appeared in 29% of repositories. Kyverno and Gatekeeper accounted for 16% and 7% of files, respectively. OPA, Kyverno, and Gatekeeper together represented 85% of policy-related files. By repository breadth, OPA, Kyverno, Pulumi, and Cloud Custodian appeared most widely.

The policy-use taxonomy contained five high-level categories: Security Governance, Compliance Governance, Cost Optimization, Workflow Automation, and Deployment Governance. Security Governance represented 65.4% of classified uses and Compliance Governance 21.3%. Their combined share was 86.7%. The taxonomy covered access control, configuration validation, secrets management, network management, resource management, vulnerability management, workload management, service compliance, standards enforcement, and deployment governance.

The study also found that 85.24% of repositories used one Policy-as-Code tool, 13.53% used two, and 1.23% used three. OPA co-occurred with Gatekeeper in 30% of repositories, with Cedar in 17%, and with Pulumi in 12%. These are repository co-occurrence figures rather than proof that tools shared policies or jointly enforced the same decisions.

The empirical results support broad adoption of executable governance artifacts, especially in security, compliance, Kubernetes, cloud infrastructure, and CI/CD. They do not establish that every identified file was authoritative, executable, connected to an enforcement point, or active in production. Documentation and toolkit repositories constituted 69% of the sample, while MLOps represented 1% and AI/Research 0.2%.

4. Compilation, sovereignty, and distributed enforcement

COAP can also compile governance conditions into portable artifacts that are verified locally rather than interpreted through an online policy service. Federated Computing as Code (FCaC) applies this model to sovereignty-critical cross-domain authorization (Fenoglio et al., 18 Mar 2026).

FCaC distinguishes constitutional governance from procedural governance. Constitutional governance specifies conditions for entering an execution domain, including issuer authority, audience, resource, action, scope, purpose, output class, validity interval, delegation limits, holder-key binding, and request freshness. Procedural governance includes stateful or contextual controls such as ABAC, quotas, workflow state, rate limits, scheduling, consent records, monitoring, incident response, and risk scoring.

Only the deterministic constitutional subset is compiled into signed capability artifacts. An Envelope Capability Token (ECT) carries issuer, subject or holder, audience, capabilities, constraints, validity period, policy metadata, holder-key confirmation, and issuer signature. The trust chain is:

$$\text{policy} \equiv \text{type or proposition}, \qquad \text{authorized action} \equiv \text{program term inhabiting that type}.$$1

KYO establishes organization-level cryptographic authority. The ECT expresses delegated capability scope. Proof of possession, implemented using DPoP, demonstrates that the requester controls the key bound to the capability for the specific request.

Boundary admission is performed locally. The verifier checks the issuer signature, trust anchors, audience, validity, delegation chain, capability coverage, holder-key binding, request binding, nonce, timestamp, and replay conditions. No online policy decision service is required at the receiving boundary.

FCaC therefore provides a narrow but significant COAP pattern:

$$\text{policy} \equiv \text{type or proposition}, \qquad \text{authorized action} \equiv \text{program term inhabiting that type}.$$2

It does not eliminate runtime policy. Post-admission systems may still apply ABAC, quotas, workflow controls, risk scoring, compliance checks, and monitoring. It also does not solve key compromise, rapid revocation, semantic differences between jurisdictions, stale tokens, incorrect issuers, or misuse after legitimate admission.

The satellite mission compiler provides a different compilation-oriented implementation. It processes a human-authored mission plan through four stages: Pydantic schema validation, OPA/Rego policy evaluation, generation of a typed WorkflowIntent intermediate representation, and rendering into Argo Workflow DAGs and Kueue Job manifests (Tsai et al., 16 Jul 2026).

The ten Rego deny rules cover nonempty mission identifiers, nonempty event lists, acquisition services, accelerator fallback, nonzero priority, CPU acceleration consistency, download restrictions, ground visibility, nonempty service steps, and recognized landscape types. Rule provenance distinguishes constraints directly traceable to ORCHIDE documentation from author-imposed safety rules.

No WorkflowIntent is created when schema or policy validation fails. Subsequent renderers generate execution artifacts subject to Argo lint, Kubernetes validation, Kueue admission, DRA device allocation, and runtime behavior. The layered architecture is safety-oriented defense in depth:

Layer	Primary function
Pydantic	Types, cardinality, and required fields
OPA/Rego	Cross-field semantic constraints
WorkflowIntent	Typed compiler boundary
argo lint	Argo manifest correctness
Kubernetes	Object validity and cluster constraints
Kueue	Queueing, quota, and admission
Scheduler/DRA	Device allocation and binding
Runtime	Actual execution and fallback behavior

The compiler demonstrates policy-checked code generation rather than a complete COAP guarantee. Safety-relevant behavior remains distributed across Pydantic, Rego, Python compiler logic, renderer assumptions, Kubernetes behavior, scheduler semantics, and runtime code. The paper’s DRA and Kueue experiments also show that a declared fallback policy may not have uniform operational semantics across admission and scheduling layers.

5. Embodied COAP and stateful executable control

In embodied systems, COAP is used to represent robot policies as executable programs that perceive, maintain state, select actions, verify outcomes, and recover from failures. The strongest formulation is presented by “Embodied Turing Machines: Stateful Code for Robot Recursive Self-Improvement,” which treats the robot and environment as a changing tape and code as the fixed transition rule (Hu et al., 8 Oct 2026).

The runtime transition is:

$$\text{policy} \equiv \text{type or proposition}, \qquad \text{authorized action} \equiv \text{program term inhabiting that type}.$$3

where $$\text{policy} \equiv \text{type or proposition}, \qquad \text{authorized action} \equiv \text{program term inhabiting that type}.$$4 is the observation, $$\text{policy} \equiv \text{type or proposition}, \qquad \text{authorized action} \equiv \text{program term inhabiting that type}.$$5 the explicit program state, $$\text{policy} \equiv \text{type or proposition}, \qquad \text{authorized action} \equiv \text{program term inhabiting that type}.$$6 the next action or trajectory segment, and $$\text{policy} \equiv \text{type or proposition}, \qquad \text{authorized action} \equiv \text{program term inhabiting that type}.$$7 the frozen source code. State includes environment records, robot proprioception, spatial relations, task stages, retry counters, arm assignments, and remembered facts.

The runtime program uses RGB streams, joint angles, end-effector poses, and gripper-command feedback. It does not use depth, segmentation models, VLMs, VLAs, simulator oracles, online coding agents, or model services. Perception is implemented with NumPy and OpenCV through robot masking, table-color comparison, connected-region extraction, ray-plane projection, and fitting of known object geometries.

The library is layered into task programs, object-family code, manipulation, perception, and motion. Approximately 83% of the code run by a new task comes from the shared library. Task programs account for 2.5% of usage, while manipulation, perception, and motion provide reusable mechanisms.

The paper reports 70.24% overall success on RoboDojo’s 42 bimanual tasks, with the highest success in Memory, Precision, Open instruction following, Generalization, and Long-Horizon dimensions. Performance was 77.3% on standard layouts and 54.1% on randomized layouts. The same program achieved 63% with measured state and 83% with oracle state, indicating that state representation is a central performance limit.

Recursive self-improvement occurs offline. Coding agents inspect failures, generate code diffs, run tests and validation episodes, and merge only candidates that improve the relevant task without unacceptable regressions. The deployed program is frozen during runtime. This creates a clear separation between model-assisted development and model-free execution.

Other embodied COAP systems retain a LLM during execution but use executable programs as the policy substrate. MEMENTO performs memory-guided memetic evolution of code policies for long-horizon manipulation and household interaction (Sygkounas et al., 24 Jul 2026). It evolves executable controllers and rollout evaluators, then uses hill climbing, macro-mutation, and crossover. The evolved policy includes symbolic task structure, finite-state manipulation, filtered observations, verification, retry counters, and recovery behavior.

MEMENTO achieved 0.97 success on the Robosuite cube task, 0.87 on asymmetric objects, 0.63 on cylindrical objects, 1.00 on search scenes, and 0.78 on held-out scenes. In AI2-THOR it achieved 1.00 success on search scenes. An evolved Robosuite policy achieved 0.90 success over ten physical trials, with one failure attributed to perception error.

PhysCaP extends code-as-policy with active physical exploration (Lin et al., 21 Aug 2026). A Planner decides whether information is sufficient and a Prioritizer filters and ranks interactions. Training-free modules estimate mass and stiffness from proprioception through get_mass and get_stiffness. The system can lift a cup to reveal a hidden object, weigh cans, or squeeze avocados to estimate stiffness.

PhysCaP demonstrates that passive COAP can be inadequate when relevant state is latent physical information. In real-world tasks, the full PhysCaP system achieved 9/10 on hidden-cube search, 8/10 on empty-can identification, and 9/10 on ripe-avocado selection. The system uses explicit physical-property extraction, interaction planning, accumulated knowledge, and stopping decisions rather than exhaustive probing.

AquaCap applies closed-loop code-as-policy to underwater navigation and manipulation (Li et al., 19 Sep 2026). It separates a high-level Policy agent from a Coding agent, uses structured semantic and geometric perception, and stores failure-aware memory. Generated programs call perception and control APIs, while the system verifies physical outcomes and revises code or plans after disturbances.

AquaCap achieved 66.43% overall simulation success over 700 trials, including 86.88% navigation, 61.25% grasping, 62.50% transport, and 35.00% tracking. In real-world ROV experiments, it achieved 20% success for grasping and 20% for transport. The gap illustrates the importance of low-level hydrodynamics, API quality, perception, and physical execution beyond code generation.

RACaP shifts code generation and repair from deployment to offline evolution (Li et al., 24 Sep 2026). Its frozen Policy APIs implement reusable physical mechanisms, while a runtime ReAct agent selects typed calls, arguments, ordering, retries, and termination. RACaP achieved 54.4% on LIBERO-90, 45.0% on zero-shot LIBERO-PRO, and 46.0% on LIBERO-Long. Its deployment path is:

$$\text{policy} \equiv \text{type or proposition}, \qquad \text{authorized action} \equiv \text{program term inhabiting that type}.$$8

This provides a middle ground between fully generated programs and fully learned policies: code remains the reusable policy substrate, while runtime adaptation occurs through typed invocation rather than source rewriting.

RE-0 and RE-OPD address improvement of executable code policies through verified local teacher interventions (Zhang et al., 26 Sep 2026). RE-0 identifies the earliest executable harmful boundary, requests a bounded correction, restores the same environment snapshot, and compares teacher and student continuations under shared randomness. Only interventions with a positive lower-confidence-bound advantage are admitted. RE-OPD projects those verified interventions into a standalone student using retention and credit-weighted teacher supervision.

The framework’s central principle is:

$$\text{policy} \equiv \text{type or proposition}, \qquad \text{authorized action} \equiv \text{program term inhabiting that type}.$$9

In held-out embodied tasks, RE-OPD-cold improved Restack from 4/50 to 31/50, Spill wipe from 34/50 to 50/50, Nut assembly from 2/50 to 44/50, and Two-arm lift from 2/50 to 38/50. The system also demonstrated physical deployment on a dual-arm robot, although performance varied substantially across tasks.

6. Agentic execution, tool-layer enforcement, and benchmark evidence

COAP is also used to reduce model invocation costs and move deterministic behavior into executable tool layers. The coroutine-bridge harness for CAR-bench makes the model’s primary action an executable Python program that can suspend at tool calls, resume after evaluator results, and continue through dependent or parallel calls (Matveev, 24 Sep 2026).

The distinction is:

$P(r,s,o,e)$0

A conventional next-action agent may require a new model call after each tool result. The coroutine bridge allows one generated program to span multiple exchanges. On the public test split, the harness used a median of two model calls against seven agent turns per task. On the hidden Track 2 evaluation it achieved 60.0% Pass$P(r,s,o,e)$1, compared with 13.33% for the organizer baseline, with median task latency of 3.14 seconds.

The same architecture places deterministic rules in guarded tools. Examples include window and air-conditioning confirmation, fog-light and high-beam restrictions, route defaults, response disclosures, unknown-value handling, mutation-failure tracking, and capability checks. A guarded tool can allow, deny, transform, or require confirmation independently of whether the model explicitly remembers the rule.

The approach does not make all behavior code-determined. The model still interprets user intent, synthesizes control flow, selects tools, and handles under-specified situations. Deterministic enforcement applies after the relevant operation reaches the guarded tool or runtime.

CodeActionBench evaluates a more demanding embodied form of agentic COAP (Lyu et al., 27 Sep 2026). It provides 25 fixed manipulation tasks and requires general-purpose multimodal models to select visual evidence, infer geometry, construct targets, execute code, interpret feedback, revise policies, and judge completion. No task-specific fine-tuning, demonstrations, specialist perception modules, depth sensing, privileged scene state, or predefined task policies are provided.

The strongest configuration, GPT-6 Astra with Codex CLI, achieved 55/75 successful attempts, or 73.3%, and solved 22 of 25 fixed tasks at least once in three attempts. Across nine configurations and 675 attempts, success rates ranged from 2.7% to 73.3%. The dominant failure categories were unconfirmed arrival, object control failure, incomplete target construction, execution errors, and incorrect completion judgment.

The benchmark separates three achievements:

1. executing a commanded motion;
2. satisfying the physical task condition;
3. correctly judging whether the condition was satisfied.

This separation is significant for COAP. A program can be syntactically correct and a robot can complete a motion while the physical task still fails. Conversely, a policy can achieve the task but incorrectly claim failure. Reliable COAP therefore requires achieved-state feedback, physical verification, and explicit termination semantics.

The benchmark’s failure distribution included 280 attempts with no confirmed arrival at the relevant region, 77 with no confirmed object control, 122 that reached the operation region but failed to complete or maintain the subgoal, six that failed only the final gripper condition, and six unresolved cases. The results show that semantic recognition and executable code do not automatically provide metric alignment, object retention, or completion judgment.

7. Guarantees, limitations, and governance requirements

COAP guarantees are determined by the relationship between the code artifact and the enforcement environment. The strongest static guarantees arise when protected operations require proof-bearing values, as in PAT. Cryptographic guarantees arise when signed capabilities and proof of possession are verified locally, as in FCaC. Deterministic operational guarantees arise when policy rules are executed by guarded tools, policy engines, admission controllers, or compilers. Embodied guarantees arise when executable programs maintain explicit state, verify physical effects, and restrict recovery behavior.

These guarantees remain conditional on trusted components. The relevant trusted base may include:

• the Agda or Lean kernel;
• code generation and runtime systems;
• foreign functions;
• policy engines;
• compilers and renderers;
• cryptographic libraries;
• claim issuers and attribute stores;
• robot APIs and motion controllers;
• Kubernetes, schedulers, and admission systems;
• perception and calibration procedures;
• the environment and database state;
• the sandbox or enforcement boundary.

External attributes are a central limitation. A proof that an age, location, approval, or transaction condition holds is only as reliable as the source and freshness of the attribute. Signed claims establish provenance and integrity but do not establish semantic or legal correctness. Stale attributes and time-of-check/time-of-use races remain possible.

Policy correctness also has two dimensions. Syntactic and operational correctness concerns whether the code compiles, executes, and enforces its stated conditions. Semantic correctness concerns whether those conditions express the intended business, safety, legal, or organizational policy. COAP strongly addresses the first dimension and does not automatically solve the second.

Dynamic policy updates create additional problems. Compiled proof terms, capabilities, workflow artifacts, and generated code may become incompatible with new policy versions. Revocation, rollback, contract migration, artifact versioning, and trust-anchor changes must be treated as policy lifecycle operations.

The code-only representation can also be too narrow. Rationale, authority, exception justification, risk acceptance, legal interpretation, human approval, and organizational accountability may remain external to the executable policy. The empirical adoption study found that documentation and toolkit repositories were widespread, while enforcement attachment was not consistently demonstrated (Foalem et al., 9 Jan 2026). ARPaCCino similarly retained natural language and expert review because executable Rego alone was insufficient to establish organizational intent (Romeo et al., 11 Jul 2025).

Embodied COAP introduces further limitations. Explicit state can be inaccurate, incomplete, stale, or difficult to estimate from RGB observations and proprioception. Physical contact, deformable objects, hydrodynamic disturbances, sensor uncertainty, and API limitations can defeat otherwise coherent code. MEMENTO, PhysCaP, AquaCap, RACaP, RE-0, and CodeActionBench all show that execution feedback, verification, recovery, and state representation are essential to reliable behavior (Sygkounas et al., 24 Jul 2026, Lin et al., 21 Aug 2026, Li et al., 19 Sep 2026, Li et al., 24 Sep 2026, Zhang et al., 26 Sep 2026, Lyu et al., 27 Sep 2026).

A mature COAP system therefore requires more than executable source code. It requires:

• explicit policy authority and versioning;
• typed or schema-validated interfaces;
• proof-bearing or capability-bearing enforcement boundaries where appropriate;
• provenance and trust requirements for external facts;
• policy consistency and completeness checks;
• deterministic runtime guards;
• compiler and renderer validation;
• sandboxing and capability restrictions;
• achieved-state and outcome verification;
• regression tests and, where possible, formal proofs;
• exception, revocation, rollback, and update semantics;
• audit logs and structured explanations;
• protection against bypass channels;
• evaluation of semantic correctness, not only execution success.

The general COAP principle can therefore be expressed as:

$P(r,s,o,e)$2

COAP is not a single language, engine, or algorithm. It is a design paradigm whose strongest instances make policy part of the type, capability, compiled artifact, guarded interface, or stateful executable program that governs action. Its central contribution is to reduce the gap between policy specification and enforcement. Its central unresolved problem is ensuring that the executable artifact faithfully captures the intended policy while remaining correct under changing attributes, environments, runtimes, and organizational requirements.