For teams

Reviewing a release

The tests pass. For which version?

You are reviewing a change to a customer portal’s sign-in flow. The checks are green—but the code has changed since they ran. Does the evidence still support the version you are being asked to approve?

Illustrative user story. Not a client case study or a measured result.

Conceptual illustration of separate documents and an open code project.
Conceptual illustration. No customer data.

Reviewing a release

Review the assumption, not just the implementation.

As technical lead, you need to see the earlier decision, the source it relied on and the reasoning for changing it now. A summary without that basis leaves you reconstructing the discussion before you can make a judgement.

A useful review separates what is documented, what has been checked and what still needs an answer. It does not need to pretend that every dependency is already known.

Reviewing a release

Keep evidence and approval separate.

AKDB’s acceptance checks require judgments to refer to their exact assessed inputs, with delivery sources and supporting verification bound to the relevant revisions. Stale or unrelated evidence cannot simply be treated as a current acceptance. In an evaluation, your team would investigate a selected delivery against those checks.

An operation receipt can show what a tool did. It cannot establish that the design is correct or that a release is safe. Approval, postponement or rejection remains with the authorised person; production changes are outside this evaluation.

Understand the inspection capability and its limits

The goal is a decision you can explain, including what remains unresolved.

Which question is holding up your review?

Bring one change and the evidence you need to assess it. We can define a suitable investigation and compare its review effort with your existing process.

Discuss a release review