Evidence Health
Public canary On-device evaluator

Release evidence / field guide

What makes release evidence trustworthy?

The short answer

Bind the exact artifact. Verify the evidence against expectations. Prove the release can be observed and recovered.

Evaluate a release

Bind every claim to the exact release.

A version label is not enough. Preserve a digest for the artifact and evidence manifest, identify the source revision and builder, and reject any verification result that belongs to different bytes.

SLSA provenance describes where, when, and how an artifact was produced. Its value comes from verification against trusted expectations—not from the presence of a file named “provenance.”

Define required evidence before the build passes.

Count what the release policy requires: tests, security verification, dependency visibility, privacy and data controls, rights, migration safety, observability, and the decision record. Missing evidence stays missing; it never becomes a zero or a passing default.

NIST SSDF provides a common secure-development vocabulary. OWASP ASVS provides testable web-application security requirements. Select the controls that match the system and record the exact scope.

Prove you can see failure and recover.

A trustworthy release has a bounded canary, live health evidence, explicit stop triggers, a reachable prior deployment, and a rollback that has been exercised or independently verified. A green deploy without a recovery path is incomplete evidence.

Field test Evaluate the evidence you have now. Evaluate your evidence

Primary references · NIST SSDF · SLSA 1.2 · OWASP ASVS 5.0