CAVA: Canonical Action Verification and Attestation

The CAVA paper is now available on arXiv as CAVA: Canonical Action Verification and Attestation for Runtime Governance of Agentic AI Systems.

We built CAVA after seeing the same failure pattern across agent deployments: raw action text is too weak a substrate for governance. A command string can look dangerous while being harmless. A neat SDK call can hide a privileged write. A workflow step can be low risk in staging and unacceptable in production.

CAVA, short for Canonical Action Verification and Attestation, is OSuite's runtime semantics layer. In product language, we often describe it as the action analysis layer because that is what customers feel: it turns agent activity into a structured action object that can be scored, routed, approved, rejected, expired, attested, and replayed.

Why string matching is not enough

The first generation of agent controls often started with allowlists, blocklists, and command pattern checks. Those are useful as tripwires, but they do not understand action consequence.

Consider two actions:

CAVA evaluates the action context, not just the string.

The CAVA decomposition

CAVA decomposes every intercepted action across several dimensions. Each dimension is intentionally simple enough for a buyer to understand, but structured enough for policy and proof.

The result is a canonical action object that feeds PCAA approval binding and Decision Score v2.1.

Runtime Coverage tiers

CAVA is the canonical action language. Runtime Coverage is the adapter posture around it: how much of a customer's real runtime surface is being translated into that language before policy evaluates the action.

This distinction matters. A public reference parser-pack percentage is not the ceiling of CAVA's architecture. It is the reproducible baseline. Product coverage comes from managed adapters and enterprise custom mappings that preserve the same canonical action object while fitting the customer's actual runtime.

DeepSeek Harness is now listed as a target runtime lane rather than a ready managed adapter. The reason is technical, not cosmetic: its plugin-first tool pipeline exposes pre-execution and post-execution points that line up with OSuite review, outcome recording, and CAVA proof export. Until a production adapter is shipped and tested, it remains a roadmap lane.

Interoperability is an input, not authority

Recent protocol-governance work on MCP, A2A, ACP, ANP, and trust registries makes the same boundary visible from the interoperability side: agent protocols can support discovery, tool access, delegation, and message exchange, but they do not automatically encode governance primitives such as deliberation, dissent preservation, human escalation, voting, or replayable audit.

CAVA treats those protocols as runtime lanes. An MCP tool call, A2A handoff, browser action, workflow step, or shell command can all become evidence, but none of them becomes final authority by being well-formed. The job of CAVA is to project the event into a canonical action object that PCAA, policy profile, Decision Score, BAF, and AREG can govern.

From analysis to decision

CAVA does not replace policy. It makes policy executable.

• —Policy profile says which boundaries matter to the customer.
• —CAVA explains what the action is and what it touches.
• —Decision Score v2.1 calculates why the action is low, medium, high, or blocked.
• —PCAA binds approval to the canonical action fingerprint.
• —BAF converts approval into a bounded action lease.
• —AREG maps the governed action into runtime exposure and blast radius.
• —OSuite records closure and produces proof.

This separation matters because customers should not be forced to trust a black box. A security leader should be able to ask, "Why was this action held?" and see the answer in product language.

Example CAVA output

{
  "runtime_lane": "codex-hook",
  "raw_action": "git push origin main",
  "intent": "publish-code",
  "target": "repository:payment-api/main",
  "boundary": ["production-release-path"],
  "privilege": "write",
  "reversibility": "partial",
  "data_movement": "none",
  "evidence_quality": "replay-ready",
  "score_inputs": {
    "target_sensitivity": 0.72,
    "privilege_weight": 0.68,
    "reversibility_penalty": 0.44,
    "policy_pattern_match": "release-boundary"
  }
}

The score is not "bash equals 25." It is a composed judgment over consequence, authority, boundary, reversibility, and evidence.

What deployers see

The product expression of CAVA should feel legible, not academic. In OSuite, a customer sees a decision explanation such as:

• —This action touches a release boundary.
• —It requires write authority.
• —The change is only partially reversible.
• —The repository is classified as production-adjacent.
• —Human approval is required before execution.

That is the difference between a control plane and a log viewer. CAVA gives the system something real to govern.

Research direction

CAVA is designed to remain portable. The open-source skeleton can help developers normalize actions in their own environments. The OSuite implementation adds managed policies, scoring calibration, proof closure, tenant-specific patterns, and deployment-grade evidence handling.

The open implementation is available at OndCo/CAVA, with an npm package published as `osuite-cava-core`.

Public reproducibility artifact

After publication, an independent replication survey initially marked the CAVA benchmark claim as not released because the paper referenced internal benchmark paths. We treated that as a fair reachability criticism and published a public artifact for the arXiv benchmark claim.

The reproducibility mirror is available at OndCo/CAVA reproducibility/cava-2607.13716. It includes the benchmark harness, expected snapshots, manifest, and verifier for the 96-seed, 384-variant benchmark profile. The public correction trail is available in the replication survey reply record.

This does not make the entire OSuite product public or certified. It means the specific CAVA paper benchmark claim is now publicly reachable and independently recomputable.

@misc{wang2026cava,
  title={CAVA: Canonical Action Verification and Attestation for Runtime Governance of Agentic AI Systems},
  author={Wang, Zexun},
  year={2026},
  eprint={2607.13716},
  archivePrefix={arXiv},
  primaryClass={cs.AI},
  url={https://arxiv.org/abs/2607.13716}
}