A reference composition showing how an OSuite-governed action can carry an external verifier checkpoint and later be recomputed without trusting either internal log.
This reference run covers a narrow but important question: can a governed AI-agent action carry a partner-verifiable proof reference before the action is authorized, and can that proof be recomputed later without trusting OSuite's own dashboard or API response?
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.
After the checkpoint integration was wired into OSuite, an external verifier independently recomputed the proof chain from the exported evidence.
The verifier recomputed the artifact hash from the proof bundle bytes, recomputed the signed event identifier from public event fields, and verified the signature against the verifier's published public key. The composition held:
`OSuite CAVA artifact -> external verifier review -> signed verdict -> OSuite proof bundle -> public verification view`
The result was not a rubber-stamp approval. The verifier returned `approve_with_concerns`, including medium-severity concerns around possible raw-secret exposure in the action summary and whether the hash-binding process was explicit enough in the artifact. That is useful. Real enterprise governance is rarely just approve or deny. A reference composition should preserve concerns in the proof record rather than hiding them behind a green check.
The reference run uses a simple operating path:
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.
In the current reference composition, the verifier maps the OSuite checkpoint key to `source_class=independent_mediator`. OSuite then stores the returned `decision_ref`, artifact hash, source class, verdict, concern signal, and verification result in the action proof bundle. During outcome closure, OSuite also records whether the final runtime action still matches the CAVA-approved fingerprint or whether approval/execution divergence was detected.
For a customer, the reference composition 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, which source class was returned, which decision reference was bound to the artifact hash, and whether execution stayed aligned with the approved CAVA fingerprint. In Runtime Exposure, the customer can see external verifier coverage, mapping status, independent-mediator references, 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.
Agent governance needs two separate properties:
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.
“The proof chain held across the OSuite CAVA artifact, external review, signed verdict, proof bundle, and public verification view.”
Request enterprise access and send your first governed decision today.
