TeamStation AI / Research / CTO Research / Bind the Reviewed Artifact to the Release
Bind review, build, deployment, and live checks to one artifact identity so leaders can prove the approved release is the artifact being served.
A practical release control for proving that the artifact approved during review is the same artifact deployed and served after release.
A review approves a specific artifact, not the idea of a release.
Release evidence gets messy when that distinction disappears. If the build changes after approval, or the deployment serves different bytes, the review no longer proves what went live. The release may still work, but the evidence chain is broken.
The control is simple: give the reviewed artifact one identity, carry that identity through deployment, then verify it again from the live system. If the identity changes, stop and review the new artifact.
This article proposes a practical operating method. It does not claim that a hash prevents every release failure, that one tool proves the whole system, or that TeamStation has measured a universal improvement from this method.
What does it mean to bind review to release?
Binding review to release means connecting four decisions to the same artifact identity:
1. Review: the team approves a known source revision and built artifact. 2. Promotion: the release process selects that exact artifact, without rebuilding it. 3. Deployment: the platform records which artifact it accepted. 4. Live verification: the running system exposes enough evidence to confirm what it serves.
The identity is usually a cryptographic digest, paired with the source commit, build run, builder, and release record. The digest answers one narrow question: are these bytes the same?
SLSA's artifact verification guidance tells verifiers to confirm that the provenance subject matches the digest of the artifact being checked. SLSA provenance describes verifiable information about where, when, and how an artifact was produced.
That is the foundation. The review record and the release record must point to the same subject.
The minimum identity chain
A useful release packet needs six fields:
- Source revision: the exact commit or source snapshot.
- Build identity: the workflow and run that produced the artifact.
- Artifact digest: the content identity of the deployable output.
- Review decision: who approved that digest, when, and for what scope.
- Deployment receipt: the environment, time, and digest accepted by the platform.
- Live evidence: a health response, manifest, image digest, or bounded readback tied to the deployed artifact.
Do not replace missing fields with "latest," a branch name, a mutable tag, or a screenshot. Those can help a person find the release, but they do not prove artifact equality.
GitHub's artifact attestation documentation explains how attestations establish where and how build artifacts were produced, and how the resulting attestation can be verified. NIST's Secure Software Development Framework includes collecting and sharing provenance data for software release components.
The tools differ, but the operating question stays the same: can the team trace the live artifact back to the reviewed artifact without guessing?
A concrete example, clearly hypothetical
Consider a hypothetical checkout service. This is an illustration, not a TeamStation client result or a measured case.
The team reviews source commit A. The governed build produces artifact digest R1. Tests, security checks, and the release owner all approve R1.
Before deployment, somebody changes an environment-dependent file and runs the build again. The new output is R2. The change may be small. The build may still be green. But the approval belongs to R1, not R2.
A weak process deploys R2 because it came from the same branch.
A governed process stops because the artifact identity changed. The team either promotes R1, or reviews R2 with fresh evidence.
After deployment, the platform receipt and live release marker both report R1. Now the decision chain closes:
reviewed artifact R1 = deployed artifact R1 = live artifact R1
If the live record reports anything else, the release is not proven. The right response is investigation, not a rewritten receipt.
Why a green build is not enough
A green build proves that a defined set of checks passed for one build execution. It does not automatically prove:
- that the reviewed output was the artifact deployed;
- that a later build produced identical bytes;
- that the platform accepted the intended upload;
- that routing sends users to that deployment;
- that runtime configuration matches the approved boundary;
- that the live service still reports the expected identity.
This is why our related research separates release readiness evidence from build status. A green build can still sit beside a red release decision when identity, ownership, rollback, or live proof is missing.
The same rule applies to AI-assisted engineering. Faster code generation and faster review do not remove the release boundary. They increase the amount of work that can change before that boundary, which makes identity control more important.
A digest is necessary, not sufficient
A matching digest is strong evidence about artifact bytes. It does not prove every part of production behavior.
Runtime configuration values, feature flags, database state, edge rules, traffic routing, and injected platform code can change what users experience without changing the application bundle. Keep those controls separate and visible.
Use the artifact digest to prove artifact equality. Use configuration identity to prove the approved runtime boundary. Use live route checks to prove that traffic reaches the intended release. Use monitoring and rollback evidence to manage what happens after launch.
Don't squeeze all of that into one magic number.
Put the control at each decision boundary
The identity check belongs where a decision can change:
At review
Record the source revision, build run, artifact digest, test evidence, unresolved risks, and approval scope. The approver should see which artifact the evidence covers.
At promotion
Promote the reviewed artifact from storage. Do not rebuild from the same source and assume the result is equal. If rebuilding is unavoidable, compare the new digest and reopen review when it changes.
At deployment
Capture the platform's native receipt. Bind the environment and deployment identifier to the artifact digest. A CLI success message is useful, but it is not the whole release proof.
After deployment
Read the custom domain, health marker, or platform manifest. Confirm the release identity and inspect the buyer-facing route that changed. Verify the actual social image, Markdown representation, schema, headers, or other surfaces included in the release.
TeamStation's CTO Proof System uses the same operating principle: the decision needs evidence tied to the exact thing being accepted. The Distributed Engineering OS keeps that evidence connected to ownership, workflow, and release control.
Who owns the chain?
Ownership should be explicit:
- the builder owns accurate artifact and provenance output;
- the reviewer owns the approval scope;
- the release owner owns artifact selection and deployment receipt;
- the service owner owns live verification and rollback readiness;
- the engineering leader owns the rule that identity drift stops the release.
One person can hold more than one role. The roles still need separate evidence.
This is not paperwork for its own sake. It prevents a common failure where every step looks successful, but nobody can prove that all steps refer to the same artifact.
The decision rule
Use one firm rule:
If the artifact identity approved at review does not match the artifact identity selected, deployed, and observed live, the release is not ready.
Then preserve the mismatch. Do not delete the failed receipt or relabel the later artifact as previously approved. The mismatch is useful operating evidence.
The goal is not a perfect chain diagram. The goal is a release decision that another person can inspect and reproduce without relying on memory.
What should a release owner record?
Record the source revision, builder and build run, artifact digest, review approval, deployment receipt, live identity, environment, and unresolved risk.
Should a team rebuild an approved artifact before deployment?
Prefer promoting the approved artifact. If the team rebuilds it, compare the resulting digest and treat a changed digest as a new review candidate.
Does a matching hash prove the release is safe?
No. It proves artifact equality within the chosen digest boundary. Security, configuration, routing, data, runtime behavior, and rollback readiness still need their own checks.
