The first OSuite + Baby Blue reference run proved a useful pattern: a CAVA action artifact could be reviewed by an external verifier, signed, exported, and recomputed later without trusting either team's internal dashboard.
That was already better than a normal audit log. But it was still a first run. The action itself was not very interesting, and the ledger publication involved coordination between both teams.
This second run raises the bar in two ways.
First, the Baby Blue / invinoveritas verdict used their v11 review policy. For `source_class=independent_mediator`, v11 binds `verified_at`, `registry_as_of`, and `registry_snapshot_sha256` into the signed decision reference. That closes a real timing gap. A mediator registry claim is not just "valid"; it is valid as of a specific registry snapshot.
Second, OSuite did not ask Baby Blue to publish the result manually. OSuite took the signed verifier event returned by `/review` and submitted it directly through Baby Blue's self-serve `POST /ledger/submit` endpoint. The resulting public ledger entry is labeled `self_submitted_verdict`, which is exactly the right label. Baby Blue did not curate it by hand; their system accepted it after verifying the signed proof.
Then OSuite executed a real third-party SaaS side effect: it created a public GitHub issue in the Agent Action Boundary Benchmark repository.
The point was not to create a dramatic action. The point was to make the chain concrete enough that someone outside both companies can ask a plain question:
Did the action that executed match the action that was approved?
What actually ran
OSuite constructed a CAVA action artifact for a bounded GitHub issue creation:
- —target repository: `OndCo/Agent-Action-Boundary-Benchmark`
- —side effect: create exactly one public GitHub issue
- —expected body hash: `sha256:878d7d4463883595484563c316c0321c2de3c63e6464e42c5aa2b90661076978`
- —expected verifier policy: `invinoveritas.review.v11` or later
- —expected source class: `independent_mediator`
Baby Blue returned `approve_with_concerns` with confidence `0.90`. OSuite preserved that verdict as issued.
After the signed verdict was returned, OSuite submitted the signed event to Baby Blue's public ledger. The ledger entry is public:
Baby Blue ledger entry 246
After that, OSuite created the GitHub issue:
GitHub issue #2
The final GitHub issue body was fetched back from GitHub and hashed again. The executed body hash matched the approved body hash.
That is the small but important difference between an audit trail and an action-bound proof. A normal log can say an issue was created. This packet can show what was approved, what was independently signed, what was submitted to the public ledger, and what actually landed in GitHub.
What can be checked
The public material is available here:
The key values in this run are:
| Field | Value |
|---|
| `policy_version` | `invinoveritas.review.v11` |
| `source_class` | `independent_mediator` |
| `decision_ref` | `sha256:a90a6f398e94129344549d36bd93cbefabd97f0f18a2fb7ca548ada24a089aaa` |
| `artifact_hash` | `d7f8744cfdbc955abc59a5f587028598cbe4e53613bfd9b3c0c186ad95ee5065` |
| `signed_event_id` | `ba6aef4ff80ab4c33b6e2d0e09a5d8af2e80284daa72ed96b71b46f165231c25` |
| `registry_snapshot_sha256` | `ca7912e150d4e03f4c762f4d4b2a4718c1e56043c45756f6031578f84fcddbb5` |
| `ledger_entry` | `246` |
| `GitHub issue` | `OndCo/Agent-Action-Boundary-Benchmark#2` |
Baby Blue's `/verify-proof` check returned `valid=true`; its sub-checks passed for event id integrity, signature validity, issuer key, proof-event shape, decision reference recomputation, and artifact hash match.
On the OSuite side, the local packet verifier recomputed the CAVA action fingerprint, the artifact hash, the expected GitHub body hash, and the final GitHub outcome binding. The packet is valid, and the final GitHub issue body hash matches the pre-approved body hash.
Why v11 matters
The subtle part of this run is not the GitHub issue. It is the registry timing.
If a verifier says a caller is an independent mediator, the next question should be: according to which registry state, checked when?
Without that, a proof can accidentally rely on a current registry fact that was not necessarily true when the verdict was issued. Baby Blue's v11 policy adds the missing time boundary by binding `verified_at`, `registry_as_of`, and `registry_snapshot_sha256` into the signed decision reference.
OSuite stores those fields in the external verifier reference and exposes them through the proof material. That lets the verifier claim become a replayable claim, not a floating label.
This is also why OSuite does not accept caller-supplied `source_class` as truth. A source class should be derived from authenticated infrastructure, not copied from a JSON field that the agent or caller can invent.
What this still does not prove
The verdict was `approve_with_concerns`, not `approve`.
That is not a bug in the demo. It is the point of the demo.
Baby Blue flagged real concerns. The verifier noted that the artifact expected v11 registry fields but did not itself carry pre-existing independent mediator evidence before the review. It also flagged that a body hash alone is weaker than having the full proposed body preimage in the reviewed artifact, and that GitHub identity/scope should be independently checked for a stronger production claim.
We agree with that framing.
This run proves the verdict-to-ledger-to-execution chain held for a controlled public SaaS action. It does not prove that every upstream identity, token scope, or source attestation problem is fully solved.
That distinction is important. A serious governance system should preserve concerns instead of polishing them away. Buyers do not need more demos where everything is green because the scenario was chosen to make the system look clean. They need proof chains that can carry uncomfortable facts without breaking.
Why this matters for enterprise agent governance
Most agent governance discussions still get stuck at one of two levels.
One level is execution infrastructure: can the agent call the tool, authenticate to the service, and complete the workflow?
The other is governance evidence: what exact action was approved, under which policy, by which authority, with what verifier reference, and did execution stay inside that boundary?
This run sits in the second layer.
It does not claim GitHub issue creation is hard. It claims that even a simple SaaS side effect should be representable as a governed action object whose approval, external review, ledger publication, and final outcome can be recomputed later.
That is the direction OSuite is building toward:
- —CAVA makes the action itself stable enough to review.
- —PCAA keeps final authority inside the governance model.
- —BAF binds approval to a bounded action lease.
- —AREG gives the runtime relationship a graph.
- —External verifier checkpoints make selected proof seams independently challengeable.
The practical buyer question becomes easier to ask:
If this agent changes a customer record, opens a ticket, posts a message, updates a repo, calls a payment API, or touches a production system, can the company later prove what was approved and what actually happened?
For this reference run, the answer is yes, for a deliberately scoped public GitHub side effect.
Now the next step is to keep raising the difficulty of the action while keeping the proof chain checkable.
