launchdev / release notebook

Digital project releases / A practical editorial guide

Release the change.
Keep the evidence.

A technical notebook for defining a release, collecting the checks that support it and keeping the decision understandable after the launch window has passed.

Use the release preparation guide →
A conceptual release record with checkpoints and evidence A vertical blue axis connects scope, checks, decision and review. Paper notes sit beside the axis. This is an editorial illustration, not a live release dashboard. 01 02 03 04 SCOPE / what changes CHECKS / what supports it DECISION / ready or open REVIEW / what follows RELEASE RECORD / ILLUSTRATIVE
A conceptual release record. The diagram shows a planning relationship, not the status of a real project.
  1. 01

    Define the change

    Write what will change, where it appears and why it is being released. Keep the boundary small enough that a reader can tell which behaviour belongs to this release.

    Evidence to collect
    A clear change description and the relevant source of the request.
    Question to keep open
    What lies outside the scope, and which assumptions still need confirmation?
  2. 02

    Check the intended behaviour

    Choose checks that address the actual change and the surrounding behaviour it may affect. Record the result and the conditions under which you observed it.

    • Confirm the intended outcome rather than only the presence of a new file or a completed task.
    • Include relevant alternative paths, empty states or access conditions for the change.
    • Keep an unexpected result visible instead of treating a planned check as a successful result.

    A check record should make it possible to understand what was examined without implying that every possible condition has been tested.

  3. 03

    Prepare the release record

    Connect the change description, observed checks and open questions in one place. Name the person handling the release decision and the person following the outcome. 

    Change: what is included
Evidence: what was checked and observed
Open points: what remains unresolved
Decision: who decided, with what conditions
Follow-through: who reviews the result

    Use the format your project already needs. The headings are prompts for a clear record, not a required tool, file type or deployment command.

  4. 04

    Make the decision explicit

    Review the available evidence against the defined scope. A decision can be to proceed, hold or narrow the change; the record should make the reason understandable.

    If a material question remains open

    State the gap, its effect on the decision and what would resolve it. Do not hide the question in a general label such as “checked” or “ready”.

    If the plan changes

    Update the scope and the relevant checks. A smaller or different release needs a record that describes the new decision rather than the abandoned plan.

  5. 05

    Observe and close the loop

    After the release, use the project’s actual observation arrangements to review the intended outcome. Keep unexpected findings connected to the change and assign the relevant follow-up.

    A useful closing note
    What was observed, what remains open and where any further work is recorded.
    A useful handover
    Who is responsible for the next review and which source explains the decision already made.

    Closing the record does not mean declaring that no problem can exist. It means leaving an understandable account of the result and the remaining responsibilities.

02 / A worked example

A small link change.
A complete reasoning trail.

This is a constructed example of release preparation, not a report from a real product. It shows how a modest change can still have a clear scope, check and decision.

THE PROPOSED CHANGE

Replace an outdated help destination

A project’s settings page includes a help link. The proposed change points that link to the team’s approved replacement page while keeping the visible label unchanged.

Keep the boundary explicit

The example concerns one link and the places where the same destination is deliberately reused. It does not include rewriting the help content or changing account permissions.

Ask before calling it done

Which destination has been approved, which views include the link and what should the user encounter after following it? Those questions shape the checks.

THE EVIDENCE TO COLLECT

Check the journey, not only the text

Verify that the intended view presents the expected label and that following the link reaches the approved destination. Record the relevant view and conditions used in the check.

Look at deliberate reuse

Identify where the old destination is expected to appear or disappear. Check those locations against the agreed scope instead of assuming that every matching string belongs to the change.

Write the decision from the results

If the observed behaviour matches the agreed scope and no material question remains open, the responsible person can record the project’s release decision. If a check exposes another outdated destination, record that finding and decide whether the scope must change.

What if another old link remains?

The presence of another link is not automatically proof that the original change failed or that the new link is enough. First establish whether the second location belongs to the agreed scope and whether its destination is intended to remain.

Then update the record. The outcome may be a revised change, a separate follow-up or a decision to hold. The useful part is the explicit connection between the finding and the decision.

This is why a release notebook preserves the question as well as the result. It lets another reader see what “complete” meant in the actual discussion.

Use a concise preparation record for your own change: scope, evidence, open points, decision and follow-through.

Open the release preparation guide →