Ask which artifact earned the green check

A release dashboard shows a green build, a green smoke test, and an approval. The room reads the row from left to right and sees a release that is ready to move.

Then somebody notices that the smoke test ran before the binary was rebuilt. The approval belongs to the earlier digest. The current artifact has the same version label, but it is not the file that earned the green checks.

At that point the checks are still true facts. They are simply facts about the wrong artifact. We think every release decision should begin with one plain question: which exact artifact earned this proof?

Version names are too broad for proof

Human-friendly versions matter. Teams need to talk about release 4.8.1 without reading a digest aloud. But a version can be rebuilt, re-signed, repackaged, or produced by a different toolchain while keeping the same label.

A check attached only to the version therefore proves less than it appears to prove. The record needs an immutable artifact identity, such as a cryptographic digest or a provider-issued package identifier, alongside the version and platform.

The identity should be captured where the artifact is created, then carried into signing, testing, approval, submission, and promotion. If a later step receives a different digest, the workflow should make the mismatch visible before anyone can reuse the earlier green state.

Bind each claim to what it actually exercised

Not every check touches the final binary. Source lint may belong to a commit. Dependency review may belong to a lockfile. A device smoke belongs to the installed package on a particular device and environment. Store validation belongs to the uploaded package the store inspected.

We want the release record to preserve those scopes instead of flattening them into one checklist. A source check can remain valid across a re-signing step if source and dependencies did not change. A binary smoke cannot silently transfer to a newly signed or rebuilt package just because the version string stayed put.

A compact record can make the boundary obvious: source commit, unsigned build digest, signed artifact digest, check name, environment, result, and time. Operators should not need raw logs to discover that the approval and the upload refer to different files.

Rebuilds should invalidate narrowly and visibly

When artifact identity changes, the product should reopen the checks that depended on that artifact. It should not necessarily erase every result in the release. Broad invalidation wastes useful proof and encourages teams to treat reruns as ceremony.

Suppose a packaging correction changes the final mobile binary without changing application source. The source typecheck may remain current. Package inspection, signing verification, device smoke, and store submission evidence need to follow the new digest. The interface should show which proof was inherited and why, then separate it from what must be earned again.

This is also where same-version rebuilds deserve special visibility. They are sometimes necessary, but they create exactly the conditions in which names stop protecting the room. A release view can label the earlier and later artifacts as distinct attempts even when product version and build number are unchanged.

Promotion should verify identity again

The last handoff is often where identity gets assumed. A tested artifact sits in one location, while a deploy script, store command, or operator selects what looks like the matching file elsewhere. If the promotion step does not verify the digest, the release can switch artifacts after every important check has passed.

We prefer promotion to state the expected digest and refuse a mismatch. The failure should be ordinary and legible: expected the approved artifact, received another one. That is not an infrastructure mystery. It is the release system protecting the boundary the team already agreed to trust.

Rollback needs the same discipline. Last known good is useful only if it points to a retrievable artifact with a proved identity. A tag or filename that can resolve to different contents is a memory aid, not a rollback guarantee.

Make artifact lineage readable by people

Digests are precise but difficult to scan. The product can present short prefixes, build labels, and a simple lineage while retaining the full value for verification. Built from this commit. Signed into this artifact. Tested on this environment. Uploaded under this provider reference.

That chain gives engineering, release managers, and support the same answer without forcing them into the same level of detail. They can see whether the current production artifact is the one that passed, and they can open the deeper evidence when the answer is uncertain.

Ubriot is built to keep mobile release work accountable across long handoffs. A green check without artifact identity is easy to admire and hard to defend. Bind proof to the exact binary, verify the identity again at promotion, and make every rebuild earn only the checks it actually changed.