A governed agent action was independently recomputed outside OSuite.

Enterprise buyers are right to ask a harder question about AI governance evidence.

It is not enough for a platform to say, "trust our log." A log can be useful, but if the same system that approves the action also generates the only evidence, the proof boundary is still mostly internal. The next step is to make the decision externally challengeable without turning the external party into the decision maker.

That is the design direction behind OSuite's external verifier checkpoint path.

The idea is simple. Before a governed action is authorized, OSuite can construct a disclosure-safe checkpoint artifact from the canonical action object, policy route, risk result, action hash, and evidence hash. That artifact can be sent to an external verifier under an authenticated OSuite checkpoint account. The verifier returns a signed event and a decision reference bound to the artifact hash. OSuite verifies that event, records the reference inside the proof bundle, and keeps the final governance decision inside the customer-controlled OSuite policy path.

Update: the first reference run was independently recomputed

After the initial checkpoint integration, Baby Blue / invinoveritas independently recomputed an OSuite proof chain end to end.

The verifier did not rely on OSuite's dashboard, API response, or internal log. It recomputed the artifact hash from the bytes inside the proof bundle, recomputed the signed event identifier from public event fields, and verified the Schnorr signature against the verifier's published public key.

The chain held across the full composition:

`OSuite CAVA artifact -> external verifier review -> signed verdict -> OSuite proof bundle -> public verification view`

The verdict was `approve_with_concerns`, not a clean approval. That distinction matters. A clean approval would only show that the integration works. This run shows why the verifier layer is useful: the proof chain can remain independently checkable while the verifier still surfaces medium-severity concerns for the operator to preserve inside the governance record.

This is the operating model OSuite is building toward: not screenshots, dashboard claims, or trusted logs, but governed action evidence that can be recomputed later by someone outside the original runtime.

Reference run materials

The concrete run is intentionally public enough to be challenged:

• —OSuite public verify page
• —Reference packet JSON
• —Baby Blue verify payload JSON
• —Baby Blue `POST /verify-proof` endpoint
• —Baby Blue verifier key manifest

The packet records the action ID, the CAVA fingerprint, the action hash, the external `artifact_hash`, the Baby Blue `decision_ref`, the signed event, and local recomputation checks. The important part is not that a page says "verified." The important part is that a third party can recompute the artifact hash, recompute the event ID from the NIP-01 preimage, and verify the Schnorr signature against the published verifier key.

This is the OSuite-side account of the run. Baby Blue / invinoveritas is publishing its own account separately and linking to the same packet. That separation is part of the point: two systems should be able to describe and recompute the same run without relying on one shared narrative.

What changes next

This reference run still used a coordinated publishing step between the two teams. That was fine for the first public composition, but it should not be the long-term operating model.

Baby Blue / invinoveritas has since added a self-serve public ledger submission path through `POST /ledger/submit`. Because OSuite is already registered as an `independent_mediator` in their registry, future OSuite-side runs can publish signed verifier material directly to the public ledger path instead of waiting for a manual partner-side citation. That does not change the facts of this run. It just removes a human coordination step for the next one.

The cleaner pattern is: OSuite governs the action boundary, the verifier signs the challengeable verdict, the proof bundle preserves both, and the public ledger path makes future publication less dependent on either team being online at the same moment.

Why this matters

Most "human in the loop" systems still treat the evidence trail as a platform-owned story. A person approves something. A platform records the approval. Later, everyone hopes the record is enough.

That is weaker than it sounds.

If the question is whether a high-risk agent action was approved before execution, the proof should be tied to the action itself. It should be bound to an action hash, a policy version, a verifier event, an approval checkpoint, and a replayable proof bundle. If a third party later asks whether the evidence was produced before the action or after the fact, the system should have something better than a timestamp printed by its own database.

External challengeability gives that conversation a cleaner shape.

OSuite's role remains runtime governance: decide whether an agent action should run, wait, escalate, stop, or close with evidence. The external verifier's role is narrower: sign and validate a checkpoint artifact so the proof bundle can be checked from outside OSuite's own trust boundary.

The authenticated boundary

One design decision matters more than the rest: the verifier should not accept `source_class` from OSuite as a caller-supplied string.

Caller-supplied labels are soft evidence. They look structured, but they are still self-attestation. A better design derives `source_class` from the authenticated account that called the verifier.

In this integration model, OSuite registers a checkpoint account with the partner verifier. When OSuite calls the verifier's review endpoint under that account, the verifier maps the calling key to `source_class=independent_mediator`. That makes the class derived from the authenticated boundary, not asserted inside the artifact.

Until that partner-side mapping is active, OSuite does not pretend the assurance is complete. The proof can be valid and still marked `valid_but_unmapped`. That distinction is intentional. It lets customers see the difference between a cryptographically valid partner event and a fully mapped checkpoint identity. Once the partner derives the source class from the OSuite checkpoint key, the reference can be marked verified while preserving the returned source class, decision reference, artifact hash, and proof checks.

The resulting reference composition is concrete:

• —agent runtime proposes an action;
• —OSuite creates the CAVA action artifact and checkpoint hash;
• —OSuite calls the verifier under the OSuite checkpoint key;
• —the verifier derives `source_class=independent_mediator` from that key;
• —the verifier returns a `decision_ref` bound to the action artifact hash;
• —OSuite stores the external verifier reference in the proof bundle and exposes it through replay, export, and Runtime Exposure.

What OSuite sends

The external artifact is deliberately boring. That is a feature.

OSuite does not need to send raw customer files, message contents, proprietary prompts, or business records to make a checkpoint useful. The checkpoint can be built from operational metadata and hashes:

• —action identifier and action hash
• —evidence hash and policy version
• —runtime class and action kind
• —declared goal and target system categories
• —CAVA consequence summary
• —Decision Score and policy route
• —approval binding state
• —final authority holder

This gives the verifier enough structure to sign a pre-action checkpoint without becoming a data processor for the customer's underlying content.

What comes back

The partner returns a signed verifier event and a proof verification result. OSuite normalizes that result into an external verifier reference:

That reference is inserted into OSuite's proof bundle and included in the proof manifest. If a customer exports the proof later, the external reference travels with the OSuite evidence instead of living in a disconnected integration log.

What this does not do

The verifier does not decide whether the agent action is allowed.

That boundary is important. OSuite is not outsourcing governance authority to a blockchain service, notarization layer, or partner API. The customer policy profile, PCAA final authority model, CAVA action semantics, BAF lease, and OSuite approval path still decide whether the action can proceed.

The external verifier strengthens the evidence boundary. It does not replace the governance boundary.

This is how we avoid turning a useful verification partner into another central authority.

Where this shows up in the product

Customers should feel this as a proof-quality improvement, not another configuration chore.

In Studio, the integration appears in two places:

• —the action replay page, where the external verifier reference is shown next to the OSuite proof bundle;
• —Runtime Exposure, where external verifier coverage shows how many recent governed actions carry a partner-verifiable reference, whether the source class is mapped as an independent mediator, and whether approval/execution divergence was detected.

The useful buyer question becomes concrete: which governed actions are only internally evidenced, and which ones are independently challengeable?

Why we are doing this now

AI agent governance is moving from policy language to runtime evidence. The market is starting to understand that "approval" and "audit log" are not enough by themselves. The proof has to be tied to the action, created at the right moment, and checkable by someone who does not simply trust the approver's own database.

This is the same direction OSuite has been building toward through PCAA, CAVA, BAF, AREG, and Decision Score v2.1.

PCAA defines who has final governance authority. CAVA makes the action reviewable. BAF turns approval into a bounded lease. AREG maps the runtime relationship. External verifier checkpoints add a challengeable evidence seam.

The product claim stays disciplined: OSuite governs the action before it runs. External verification makes the evidence harder to hand-wave later.

That combination is where enterprise agent governance starts to become serious.