Identity and artifact trust

A release needs two answers: which bytes are selected, and why those bytes should be trusted. An immutable image digest answers the first. A verified signature and a constrained publishing identity contribute to the second. Neither answer establishes that the application survived a dependency failure.

Resilience Gate keeps these questions separate so a green build, a signed image, or a healthy dashboard cannot silently stand in for the complete release decision.

A name is a pointer; a digest is content identity

A registry tag such as sha-<source-sha> helps a controller discover a candidate. A tag can move: the same string can later point at different image bytes. An OCI digest such as sha256:… identifies the selected image content. Kargo carries the resolved digest into Freight, its release-candidate record, and the promotion template writes that digest into Helm values. The rendered Deployment uses a digest-qualified image reference.

This makes a later tag change irrelevant to the candidate already selected for that promotion. It does not guarantee registry retention, establish who created the image, or make rebuilding the same source equivalent to retrieving the original image. The exact runtime artifact still needs to exist.

The Warehouse accepts application discovery tags matching ^sha-[a-f0-9]{7,40}$. It excludes convenience names such as latest and buildcache. The staging promotion uses imageFrom(...).Digest, and the Deployment template constructs the runtime reference from repository and digest. Warehouse tests and staging tests check these bindings.

Publication establishes a specific trust statement

The application publication workflow first validates and builds without publishing. Its publish job runs only after that validation succeeds and only for a push or manual dispatch on refs/heads/main. GitHub OIDC exchanges the trusted execution’s short-lived identity for Google credentials; the workflow does not load a static cloud service-account key.

The build action emits the image digest. CI signs that exact digest with keyless Cosign, then verifies it against the GitHub token issuer and the expected workflow identity ending in .github/workflows/build-push.yaml@refs/heads/main. Only after verification succeeds does it upload application-artifact-identity, a JSON record connecting source revision, image reference, signature subject, workflow identity, and CI run.

That is a useful statement: the configured CI execution signed and verified these bytes. It is narrower than saying every image the cluster can deploy is trusted. The workflow pushes before signing. If signing or verification fails, the pushed image and its discovery tag may already exist even though the verified identity record is absent.

The current Warehouse does not query Cosign or require that identity artifact. The current Kubernetes deployment path has no independent signature admission policy. A digest therefore prevents content substitution after selection but does not itself enforce publisher trust at discovery or deployment. This limitation is explicitly recorded in the existing artifact contract and known limitations.

Several identities describe one release

“The commit” is ambiguous in this system. Keep the identity’s role attached to its value:

Identity	What it identifies	Why it is separate
Application source revision	Source used to build the URL-shortener image	An application build can predate chart-only changes.
Application image digest	Selected executable image content	Source identity does not uniquely establish built bytes.
Freight chart-source revision	Source tree containing Helm chart and values	Kargo renders this revision alongside the selected image.
Rendered environment revision	Commit written to env/dev, env/staging, or env/prod	It is a promotion output, not the source chart revision.
Gate-runner digest	Orchestrator, scorer, workflow, and annotation implementation	A verifier change can alter results without rebuilding the application.
Signer and load-generator digests	Other runtimes participating in the observation	They are dependencies of the experiment, not the application artifact.
Run identity	One execution and its observations	Identical release bytes can have multiple independent runs.

The gate’s scorecard field release.revision receives the source/chart commit from Freight. It is not the rendered branch commit and should not be relabeled application build source. Evidence metadata separately records the rendered revision. Scorecard tests explicitly check this source/Freight meaning.

The 3 October 2026 verification report illustrates the distinction: application release source 3b708353…, Freight chart-source 0a98c08c…, staging render 64d2dded…, and prod render 7d334d5a… describe different handoffs of the same recorded release. Shortened values here aid reading; the report retains the full identities.

Trust does not predict resilience

A correctly signed image can contain a readiness bug. A digest-pinned image can still fail when PostgreSQL disappears. The bounded staging gate evaluates observed behavior for selected dependency faults. Its scorecards need the release identity so those observations cannot be casually transferred to another candidate.

The reverse also matters. A behavioral pass does not expand the implemented supply-chain boundary. It cannot prove signature enforcement that the Warehouse and cluster do not perform. Engineering judgment joins several narrow claims instead of inflating one into a general guarantee.

Continue with controller ownership to see who transforms these identities, or follow one release to connect publication to downstream eligibility.