Making governed agent actions independently challengeable.

This pilot covers a narrow but important question: can a governed AI-agent action carry a partner-verifiable proof reference before the action is authorized?

The goal is not to replace OSuite's governance engine. OSuite still owns PCAA final authority, CAVA action interpretation, policy routing, approval binding, BAF lease creation, and outcome closure. The verifier adds a separate challenge layer so a future reviewer is not forced to trust only OSuite's internal log.

The operating path

The pilot uses a simple operating path:

• —OSuite receives a planned agent action from an SDK, hook, MCP server, ChatGPT app, or runtime adapter.
• —CAVA converts the action into a canonical object with goal, target, operation, consequence, and policy route.
• —OSuite builds a disclosure-safe checkpoint artifact from the action hash, evidence hash, policy version, and governance metadata.
• —The artifact is sent to the external verifier before authorization.
• —The returned signed verifier event is verified and inserted into the OSuite proof bundle.
• —OSuite continues with its own approval, denial, or closure decision.

The key design rule is that the verifier's `source_class` should be derived from the authenticated checkpoint account. It should not be accepted as a caller-supplied field.

What the customer sees

For a customer, the pilot should not add another workflow to manage. It should appear as stronger proof quality.

On a replay page, the customer can see whether the governed action includes an external verifier reference. In Runtime Exposure, the customer can see external verifier coverage, mapping status, and whether any recent actions are still internally evidenced only.

This makes the buyer conversation more concrete. The question is not "do you have a log?" The question is whether the proof can be challenged outside the system that created the approval.

Why it matters

Agent governance needs two separate properties:

• —authority: who is allowed to decide whether the action can proceed;
• —challengeability: whether the evidence can be checked later without trusting one internal database.

Many systems collapse those properties into one platform log. OSuite keeps them separate. The customer remains the governance authority through OSuite policy and approval controls, while a verifier can strengthen the evidence boundary around the decision.

That separation is the difference between a dashboard and a control plane.