Why a successful build target doesn’t prove an output exists

Compare two captures

Bazel is a build tool. Its Build Event Protocol (BEP) records what happened during a build. The adapter used here turns those records into observations for Agent Claim Check.

Both synthetic records contain a successful target and a named output. Only one contains enough evidence for the adapter's complete claim.

The truncated file is exactly the first three events of the complete file. Both record target //reports:summary, configuration cfg-k8-fastbuild, and a summary.json file of 184 bytes. The complete file adds a fourth event containing BuildFinished, exit code 0, a finish time and lastMessage: true. Those result labels answer a question about the supplied observations. A successful target record alone cannot establish that the build completed and the capture is complete.

Follow the observations

1. Select one exact claim. The request identifies an invocation, base target and configuration, default output group, and artifact path, configured digest and byte length.
2. Bind the input. The request's SHA-256 must match the complete raw event stream. This fixes which bytes are being assessed; it does not authenticate their producer.
3. Check all five observations. Invocation identity, target result, artifact record, build terminal and stream completeness each supply a necessary part of the assessment.
4. Keep absence distinct from contradiction. Missing completion evidence yields insufficient_evidence; an observed conflicting configured digest can yield contradicted. Invalid input instead produces an adapter error with no finding.

Try the public example

Use the pinned adapter guide and existing adapter in that exact repository revision. The frozen input profile is Bazel 8.7.0; the runtime requirement is Node.js >=24.19.0 <25. The fixtures are synthetic. No Bazel execution, model, cloud build or dependency installation is needed.

node tools/adapt-bazel-bep-artifact-created.mjs \
  fixtures/bazel-bep-artifact-created-v1/supported-complete/request.json \
  fixtures/bazel-bep-artifact-created-v1/supported-complete/events.bep.jsonl

For the second capture, use both files from insufficient-target-success-truncated. Do not mix a request with another stream: the source hash is part of the contract. Exit 0 means an accepted receipt, including an insufficient_evidence finding; it does not mean the claim was supported.

What this example shows

This walkthrough describes public documentation and synthetic records pinned to commit 9c0cb0760a8fb56ebbabc5840b319557de2c9f08 in Agent Claim Check. The adapter and classifier are linked, not reimplemented here.

• Contract, fixed profile and documented expected outcomes
• Complete-capture request and truncated-capture request
• Expected receipts: complete and truncated. Both retain downstream_action_authorized: false and intent_assessment: not-assessed.
• Public fixture and output-hash tests

supported means only that the supplied, hash-bound observations support the exact constructed claim. It does not establish that the artifact exists, that its producer is authentic, that the content is correct or safe, or that any downstream action is authorized. The adapter does not open the artifact or dereference its URI. The configured digest is not described as SHA-256 because the BEP file record does not name its algorithm.

Attribution: the linked documentation and independently authored synthetic content are from Agent Claim Check (CC BY 4.0); its adapter software is Apache-2.0. This explanatory comparison is adapted from the pinned guide.