How to read evidence

The release question is about one candidate under one set of conditions. Evidence earns its value by joining an immutable identity, a bounded scenario, a measurement window, a result, and cleanup. A screenshot can explain that join, but a green panel alone cannot establish it.

Start by asking what kind of statement is being made. “The scorer rejects a stale sample” is a source/test contract. “A Kargo-managed staging run passed three experiments” is a recorded execution. “The app looks healthy now” is a point-in-time resource observation. These statements support different decisions and should remain distinguishable.

Enlarge diagram: Provenance connects candidate identity, a bounded execution, measured verdict, and reviewed public artifacts. · Version-controlled diagram source

Establish identity and time

A release contains several identities. Application source identifies the code build. Chart source identifies configuration selected by Kargo. The rendered revision identifies its environment output. The OCI digest identifies image content. Signer, gate-runner, and loadgen digests identify the supporting runtimes. A Workflow name or run ID identifies the execution. Do not collapse these into a single commit.

In particular, repository_revision in retained run metadata is the source/Freight revision supplied to the gate, while chart_revision records the observed rendered branch. The format reference preserves that historical field meaning. An application tag can point at a different source than the platform snapshot or chart source.

Time is equally specific. A scorecard names its injected-fault window and generation time. A screenshot names capture time and the observed dashboard or execution window. The October 2 dashboard campaigns remain October 2 observations even if a screenshot was captured later or this documentation was built in October. Compare the recorded October 3 release and historical cases instead of blending them.

Read the strength of the artifact

Artifact	Useful support	Insufficient on its own
Deterministic test	Implemented behavior for supplied fixtures and contract boundaries	A live payment, applied fault, or release approval
Rendered manifest	Intended resources and selected configuration	Reconciliation or runtime health
Accepted Kargo request	The controller accepted an action	Successful verification
Completed AnalysisRun	The controller’s recorded verification outcome	Full interpretation without identity, scorecards, and cleanup
Scorecard	Exact expressions, thresholds, sample/error context, immutable release/run identity	Successful enclosing Job when orchestration or cleanup failed
Gate log and cleanup readback	Runtime lifecycle and absence of exact temporary objects	General resilience outside that run
Reviewed screenshot	Visual context attached to the manifest’s identity/window	Replacement for machine-readable verdicts
Private-bundle summary	A public account of privately reviewed observations	Public independent inspection of unavailable raw records

The evidence repository publishes selected earlier sanitized bundles and a reviewed final summary. The fresh October 3 scorecards and full raw collection are privately retained. Public readers can assess the summary’s identities and screenshots, and inspect older public examples of the format, but cannot independently recompute the fresh verdict from unpublished files.

A pass is a conjunction

For staging, read useful paid traffic before chaos, actual applied timestamps, observed dependency unavailability, bounded recovery, every scorecard, cleanup, the gate Job, and the AnalysisRun together. The target preflight prevents a fault against nothing. Traffic preflight prevents a quiet service from earning a pass for doing no useful work. Timestamp and telemetry checks prevent a scheduled experiment or missing measurement from being mistaken for demonstrated behavior.

No-data behavior is expression-specific. Some error queries use or vector(0) intentionally. A zero error result can be appropriate while traffic, target, and recovery remain separately required. “All missing telemetry always fails” is too broad, and “no errors proves resilience” is too weak. The measurement explanation and metrics reference show the implemented distinction.

The metadata status is supplied by the operator. Schema validity ensures structure and routing; it does not certify the claim. fail, blocked, and unavailable mean the associated release claim was not proven. A deliberate negative test with status fail can establish correct fail-closed behavior without becoming a passing release.

Decide what follows

Successful staging verification grants normal downstream eligibility for its Freight. Prod-like promotion remains an explicit operator action, followed by its own readiness/liveness smoke. It does not repeat staging paid load or chaos. A manual Freight approval is a separate override; it is not evidence that upstream verification passed.

The strongest conclusion is therefore bounded: this candidate satisfied these checks in this lab during this window, and temporary resources were cleaned. Broader claims need broader evidence. Read limitations before extrapolating availability, payment safety, supply-chain enforcement, or production readiness.

Public provenance begins with the verification report, evidence index, screenshot manifest, and reviewed gallery. Publication rules are in collect and review evidence.