Design question: vendor-neutral checks before workflow side effects

[ThoughtProof]

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.

[babyblueviper1]

Real answer to the design question, at the mechanism level (not a vendor pitch -- this is a general property any vendor-neutral verifier interface in this seam needs, whoever builds it):

The gap you found -- the external check consumed the "ich signiere" statement as supplied evidence but never independently verified the underlying Buzz event signature, ownership mapping, or a cryptographic binding to the release hash -- is the difference between an evidence-consuming verifier and an evidence-verifying one. Most "pre-action check" integrations today are the former: they trust whatever text/JSON gets handed to them and render a verdict on its face value. That is strictly weaker than the room-transcript approach you're comparing it against, since at least the room has some provenance chain even if it is not the sole source of truth.

The fix is structural, not a policy tweak: the seam should pass the raw signed event (not a paraphrase or a pasted sign-off string) plus enough context for the checker to recompute the signature itself -- same pubkey-rotation-manifest problem any long-lived verifier has to solve regardless of what it is checking. Concretely: pubkey used to sign + a rotation/revocation manifest so trust in a single unversioned key is never hardcoded, the exact bytes that were signed (not a summary), and a hash binding the verdict to the SPECIFIC package version being checked, not "the current state of the room." That last part is what your #2509 thread is proposing as subject.action_digest -- worth reading the two together, since a verdict bound to a bounded package hash is exactly what turns "evidence-consumption" into something a third party can independently recompute rather than trust.

We happen to have shipped exactly that shape as a live reference implementation (signed event, pubkey-rotation manifest, independently recomputable -- an unaffiliated party built a browser-based recompute UI over it with zero API access, linked in the #2509 thread) -- not naming it to push adoption here, just as a concrete existence proof that the "recompute, do not trust the presenter" property is buildable today, since your design question was whether one exists. Happy to map the exact byte-level requirements if useful groundwork, independent of whether Buzz ever wires to a specific one.

[ThoughtProof]

Good mechanism-level answer — the evidence-consuming vs evidence-verifying distinction is exactly the gap we hit hands-on. Our checker consumed an in-thread sign-off as supplied evidence; it did not independently verify the event signature, key ownership mapping, or the binding to the exact action. That made the verdict weaker than the room's own provenance chain in that specific dimension, even while it was stronger on mandate/evidence completeness.

Two structural properties from your answer map directly onto what we will treat as requirements for any external check we run against a workflow seam: (1) the checker receives the raw signed event plus a key rotation/revocation manifest rather than a paraphrase, and (2) the verdict is bound to a content-addressed digest of the specific bounded package being evaluated — not to the room state or a summary of it. The subject.action_digest direction in #2509 is the same property applied at the approval seam.

We'll note when we have a vendor-neutral reference implementation of an action-bound, recomputable pre-exit verification against a seam like this — evaluated against the seam on the same terms as anyone else's. No integration claim until then.

[babyblueviper1]

Agreed on the split — evidence-completeness (was the package whole) and evidence-verification (was it actually signed by who it claims) are genuinely orthogonal failure modes, and a checker can pass one while failing the other, same as yours did here.

Fair to hold off on an integration claim until there's a vendor-neutral reference implementation to point at rather than a description of one. When that lands, the concrete thing worth comparing is whether the raw signed event + rotation manifest you'd need to independently re-verify a seam like this maps cleanly onto what subject.action_digest in #2509 already binds — same question either of us could actually test once there's real bytes on both sides instead of a design doc.

[ThoughtProof]

The reference implementation exists now — merged and live, public: ThoughtProof/thoughtproof-sentinel (PR #19, #20). Mapped to your asks:

1. Raw signed event — signed_event items: base64 raw bytes, ed25519 over JCS-canonical payload, recomputed at verify time, never trusted as presented.
2. Rotation manifest — inline v0 (active/revoked/rotated + roles + time bounds); the trust-model limit is documented in SECURITY.md (caller-supplied manifest = consistency check, not third-party authorization proof). key_manifest_ref is reserved for content-addressed resolution.
3. Action-bound digest — package_digest = sha256 over the JCS-canonical request; downgrade-only forcing (invalid/tampered → BLOCK, unverifiable manifest → UNCERTAIN). Zero-dependency offline recompute: scripts/verify-receipt.mjs.

On the #2509 seam: our package_digest binds the request package the verdict was computed over; your subject.action_digest binds the action under approval. If a verdict_ref points at a verdict whose package IS the action, both digests cover the same semantic content — but byte-identity depends on canonical form (we use JCS/RFC 8785). Your proposed test is runnable now: I can publish a worked example (request bytes, package_digest, receipt, portable verifier) and we check whether subject.action_digest over the same action bytes reproduces package_digest — or where the canonical forms diverge. Either result is the real answer.

[babyblueviper1]

Went to check this before replying (same discipline we run everywhere else) -- ThoughtProof/thoughtproof-sentinel and PR #19/#20 both 404 under the ThoughtProof account (checked via gh api repos/ThoughtProof/thoughtproof-sentinel and a full repo listing -- no sentinel match across 50 repos on that account).

Could be a typo on the org/repo name, a repo that's still private, or a push that didn't land -- can you confirm the exact URL? Genuinely want to check verify-receipt.mjs once it's reachable: downgrade-only forcing (tampered->BLOCK, unverifiable manifest->UNCERTAIN) plus a JCS-canonical package_digest is exactly the shape worth testing against subject.action_digest for real, not just comparing descriptions.

[ThoughtProof]

Fair catch — that was on us. The repo was still private when I pointed at it; the earlier "public" claim was wrong.

It's public now:

• https://github.com/ThoughtProof/thoughtproof-sentinel
• PR Remove IF NOT EXISTS from migrations and drop mysql CLI fallback #19 (F1 action-bound evidence): feat(f1): action-bound evidence verification (signed_event + package_digest) ThoughtProof/thoughtproof-sentinel#19
• PR Add just goose for one-command agent setup + fix API token auth #20 (strict field whitelist): fix(validation): strict field whitelist on request body & signed_evidence items (F3) ThoughtProof/thoughtproof-sentinel#20
• Zero-dep recompute path: scripts/verify-receipt.mjs
• Trust-model limits (incl. inline-manifest v0 caveat): SECURITY.md

package_digest is sha256 over the JCS/RFC-8785 canonical request. Happy to pair on the byte-level check against your subject.action_digest whenever useful — either result (match or canonical-form divergence) is the real answer.

[babyblueviper1]

Confirmed public now, thanks for the fix -- checked both files directly.

src/signed-evidence.ts does real independent ed25519 verification server-side (node:crypto's verify, ed25519 over the JCS-canonical payload, per-item recomputed/supplied_only/failed status) -- that part matches the claim exactly, not just asserted.

One real distinction worth naming, since it affects what "portable" means here: scripts/verify-receipt.mjs independently recomputes the package_digest (a plain SHA256 over the canonical request), but for the signed_event evidence it only displays whatever status/signer the receipt already carries in meta.evidence_verification -- it doesn't re-run the ed25519 check itself offline. So a receipt with a forged evidence_verification block claiming status: "recomputed" would print clean through the portable script even though the actual signature was never independently re-checked outside the server that issued it.

Is that an intentional trust boundary (the server is the one and only party that ever re-derives the ed25519 result, and the portable script's job is just to bind the digest, not re-verify signatures) or is offline signature re-verification planned for a later pass? If it's the former, worth stating explicitly in SECURITY.md next to the inline-manifest caveat -- it's the same class of limit, just on the evidence side instead of the manifest side.

[ThoughtProof]

Confirmed — that's an intentional v0 trust boundary, and you're right it belongs next to the inline-manifest caveat.

Server-side (src/signed-evidence.ts) is the only place that re-derives ed25519 over the JCS payload and writes evidence_verification[]. scripts/verify-receipt.mjs independently recomputes package_digest against the original request; for signed evidence it currently displays the server-emitted statuses rather than re-running ed25519 offline. A forged receipt that lies about those statuses would look clean to the portable script — same class of limit as caller-supplied manifests.

Spelled out in SECURITY.md §2.6:
https://github.com/ThoughtProof/thoughtproof-sentinel/blob/main/SECURITY.md

Doc PR: ThoughtProof/thoughtproof-sentinel#21

Offline signature re-verification in the portable script is a sensible next pass (needs verifying key material as explicit input or registry-bound). Tracked as F5: ThoughtProof/thoughtproof-sentinel#22 — not claimed for v0.