Design question: vendor-neutral checks before workflow side effects

## Context

Buzz’s model—humans and agents collaborating through signed events and
portable identities—is a strong substrate for multi-agent work.

This is a design question about a complementary exit boundary, not a
request to turn Buzz into a verifier product or adopt a specific vendor.

## Hands-on observation

We ran a small multi-agent release workflow against a real WIP tree with
code, tests, changelog, release notes, and an explicit five-gate mandate.

The room initially held because one gate—an explicit sign-off—was still
pending. We sent a bounded exit package (proposed action, mandate
reference, evidence inventory, provenance) to a separately scoped
external verification HTTP API. The full room transcript was not treated
as authoritative evidence. That incomplete package returned **BLOCK**
with structured objections.

The operator then posted “ich signiere” in the Buzz thread—a statement
intended to satisfy the workflow’s owner-sign-off gate, not a separately
verified release-bound signature. We included that statement as evidence
in the revised package. The room moved to **SHIP**. A second external
check under the same mandate returned **ALLOW**.

Observed pattern:

- Room: HOLD → sign-off statement added → SHIP
- Exit package: statement missing → BLOCK
- Revised package: thread statement attached → ALLOW

This was not “room wrong, external right.” The external check required
an explicit precondition to be present in the bounded package, then
allowed the revised package.

**Evidence-consumption limit:** in this test the external verifier
consumed the statement as supplied evidence; it did **not** independently
verify the Buzz event signature, ownership mapping, or a cryptographic
binding to the release hash. A production seam would ideally make those
checks explicit.

We are not claiming a Buzz integration exists, that Buzz systematically
fails, or that a particular verifier should be used.

## Design question

Is there an existing or preferred **vendor-neutral seam** for calling a
separately scoped check before a workflow triggers an external side
effect (merge, release, deploy, spend, submit, webhook)—and, if so, how
should its result attach to the event log?

Related: how can an external pre-exit checker verify that a sign-off
comes from an authorized Buzz key and is bound to the exact proposed
action/release hash (so the checker is not only trusting a pasted
string)?

Possible shapes might include an HTTP workflow step, `buzz-cli`,
ACP/MCP, or another hook you consider canonical. We noticed
approval-related event kinds and suspension patterns in the current tree
but may have missed the intended extension point.

Ideally the checker returns a structured outcome and optional
objections; a signed receipt could attach to the event log as an
**action-bound audit artifact**—not global room truth or reputation.

Happy to sketch a small vendor-neutral PoC against the seam you recommend.