Begin with the active deployment.
A merged PR identifies an engineering change. To assess a deployed result, read the active deployment for the intended environment and record its immutable commit, image digest or artifact ID, together with the observation time.
Read the serving record rather than selecting the most recent build. A newer build can exist while an older revision still receives traffic. If the platform shows only a mutable image tag, keep the artifact identity unresolved until a digest or equivalent immutable identifier is available.
The checklist keeps the merged change, CI checks, serving identity and health response in separate rows. This makes a later reader’s question answerable: which source established each part?
Use ancestry when the history supports it.
When both the reviewed change and serving artifact map to commits in the same repository, Git can test whether the former is an ancestor of the latter. Replace both placeholders with the exact commit IDs from those source records.
git merge-base --is-ancestor FIX_COMMIT SERVING_COMMIT| Status | Meaning |
|---|---|
| 0 | The first commit is an ancestor of the second. |
| 1 | That ancestry relationship does not hold. |
| Another nonzero status | The check failed; inspect the error before drawing a conclusion. |
A squash, cherry-pick or rebuild can carry equivalent changes under another identity. An ancestry result of 1 therefore needs investigation of the resulting diff or artifact; it does not alone establish that the fix is absent. A positive ancestry result also leaves room for later reverts or changes. Inspect the relevant code in the serving revision when the exact content matters.
If the required commits are unavailable locally, record the gap. Do not substitute the branch tip for the serving revision.
Give the runtime check its own window.
A healthy endpoint establishes the health response you observed. For a sensitive-logging fix, the remaining question is what happened on the relevant route after the deployment.
Choose a bounded post-deployment interval and retain the same environment, route and source scope for both observations: positive activity on that route and the presence or absence of the sensitive-message pattern. Record aggregate results where they answer the question; retain source access errors as errors.
Zero sensitive-message matches with no relevant activity leaves the condition unresolved. A permission failure leaves the counts unknown. Keep the observation window and the specific missing read attached to the work so the next person can continue without repeating the code change.
Write the conclusion the sources support.
The historical logging note reached a precise result: the serving revision contained the engineering fix, and health returned HTTP 200. A later Grafana metadata request returned 401, so runtime counts remained unknown.
A useful handoff names the confirmed serving artifact, the observed runtime result or exact gap, and the person responsible for the next read. The worksheet has a place for each source identity, observation time and next owner.