# Bind release acceptance to artifact identity

Illustrative planning brief; no automatic product import.

Illustrative planning case: QA tested a release candidate, but the package ready for deployment has been rebuilt from a later commit.

## Decision

Reconcile the deployed artifact with the tested identity.

## Owned work

- Capture QA candidate
  - Owner role: Release investigator
  - Acceptance evidence: Commit digest and package hash identify the tested binary.
- Compare deployment artifact
  - Owner role: Migration engineer
  - Acceptance evidence: The release package matches or lists its differences.
- Review changed package
  - Owner role: Release reviewer
  - Acceptance evidence: Any substantive difference returns to appropriate validation.

## Workflow

1. Retain the QA candidate’s commit and package digest with its validation evidence.
2. Compare the deployment package with that identity and explain any rebuild or content difference.
3. Return substantive differences to appropriate validation; proceed only with acceptance tied to the actual release artifact.

## Judgment

Do not transfer acceptance to an unexamined artifact.


## Filled illustrative release coordination record

The synthetic QA candidate is commit a12, while the deployment package is a14 and includes a dependency update. The release is held for focused validation of that difference. A matching version label is not enough because both packages say 2.8. The checklist ties acceptance evidence to immutable artifacts rather than informal names.
Decision: Reconcile the deployed artifact with the tested identity.
Review boundary: Do not transfer acceptance to an unexamined artifact.
This example uses synthetic conditions. Replace its observations with project evidence and record any changed assumptions before adopting the plan.


## Working artifact

- Identity matches / QA commit and package digest match the deployment artifact. / Proceed to the remaining release checks with matching acceptance evidence.
- Identity differs / A rebuild or later commit changes the proposed package. / Hold acceptance until the difference has appropriate validation.


## Workflow questions

### Can the same version label prove equivalence?

No. Rebuilds and later commits can share labels; retain a package digest and source identity.

### Must every rebuild repeat all tests?

Assess the actual differences and build reproducibility, then run validation appropriate to any changed behavior.

## Product connection

Use the manual work brief to discuss task ownership, review evidence and next actions in TeamBoost. Release execution remains a separate project workflow; the download performs no deployment or import.

Confirm account availability before adopting this manual outline.