Runtime Coverage is not a parser percentage.

One easy way to misunderstand CAVA is to treat it like a parser leaderboard.

How many runtime records did it parse? How many commands did it classify? What percentage of events produced a canonical action object?

Those are useful engineering questions, but they are not the whole product question. The product question is sharper: when an agent tries to act inside a real company, does the runtime produce enough structure for OSuite to decide what the action is, whether it should run, who can approve it, and whether the proof can be replayed later?

That is why we separate CAVA from Runtime Coverage.

CAVA is the action language. It defines the canonical action object, semantic fingerprint, approval binding, receipt, and verification path.

Runtime Coverage is the adapter layer around CAVA. It describes how each runtime lane maps into that language.

The three tiers

OSuite now treats Runtime Coverage as a three-tier surface.

This matters because most enterprises do not run one clean agent runtime. They have coding agents, MCP tools, browser automation, workflow engines, internal APIs, cloud automation, SaaS systems, and a few old systems nobody wants to admit still exist.

Treating all of that as one parser percentage would be dishonest. Some lanes are open and reproducible. Some are managed by OSuite. Some are private to the customer and need a reviewed mapping.

Why not put everything directly into CAVA?

Because the core action language should stay stable.

If every customer-specific ERP field, ticketing workflow, approval phrase, warehouse status, or regional data label gets baked into CAVA itself, the framework becomes brittle. It would turn from a portable action representation into a giant pile of customer-specific adapters.

The cleaner design is:

runtime event -> adapter coverage -> CAVA action object -> policy -> approval -> proof

The adapter can evolve. The canonical action object remains stable enough for policy, Decision Score, BAF leases, AREG exposure maps, external verifier references, and proof exports to depend on it.

What a customer sees

In Studio, Runtime Coverage should not look like a debug panel. A customer should be able to answer:

• —Which runtime lanes are connected?
• —Which lanes are managed by OSuite?
• —Which lanes are only reference coverage?
• —Which private systems need an enterprise custom mapping?
• —Which actions were held because evidence was incomplete?
• —Which adapters need remediation before the next rollout?

That is why Runtime Security now reports `coverage_tier`, `parser_posture`, connected lanes, evidence gaps, and exportable coverage data.

For terminal users, the same model is available through the CLI:

osuite adapters
osuite adapters coverage
osuite adapter init acme-erp
osuite adapter test .osuite/adapters/acme-erp.json

The last two commands are intentionally simple. They let a runtime owner draft a private adapter mapping in reviewable JSON before bringing it into Studio.

What this does not claim

Runtime Coverage is not a magic promise that every action in every runtime can be perfectly understood.

Sometimes the runtime does not provide enough structure. Sometimes the agent's own summary is too vague. Sometimes a customer-specific system uses fields that only the customer can interpret. In those cases, the correct behavior is not false confidence. The correct behavior is abstention, escalation, or an enterprise custom mapping.

That is the point of the layer. It lets OSuite be more honest about what it knows.

Why this is better than a log

A log can say an event happened.

Runtime Coverage says whether the event was translated into a governable action object, which tier produced that translation, what evidence was missing, and what must improve before the lane should be trusted for production decisions.

That distinction is small on a slide and large in production.

When an agent action turns into a business consequence, the company does not only need a record. It needs to know whether the record was understood.