Software Release Book: Definition and Example

A Software Release Book is a signed, portable record of what changed, which product outcomes and contexts were affected, what evidence was observed, who decided what that evidence means, whether outward content is ready, which risks remain, and what was delivered.

It is more than a release checklist. Every item points to exact identity and evidence, and human, owner, and machine views reconcile over the same signed facts.

Why checklists are insufficient

A checklist can record that “tests passed” and “docs updated” without identifying the test Run, Journey Version, contexts, evidence, reviewer, documentation version, or delivery receipt. The box remains green after source evidence changes unless somebody remembers to reopen it.

A Release Book makes those relationships explicit and verifiable.

Ten sections

Identity

Release ID, name, version, commits, pull requests, builds, environments, and release time establish what is being evaluated.

Source changes

Changed code, routes, components, targets, state, and flags retain commit, pull-request, and impact-evidence references.

Journeys and contexts

Changed Journey Versions identify executed context cells and ownership. This turns “E2E passed” into an outcome and state coverage statement.

Verification

Content-addressed Runs summarize functional, visual, and accessibility evidence while preserving failure identities and exact evidence references.

Decisions and risk

Attributable Decisions record approval, rejection, baseline acceptance, repair, or accepted risk. Exceptions preserve owner and expiry.

Support and documentation

The support/docs owner completes a readiness action against required evidence instead of inheriting engineering approval.

Publications

Documentation, support, training, demo, and other outward versions retain destination, source, stable and immutable URLs, status, and receipt.

Approved media

Launch and training media retains content hash, source Run evidence, approval Decision, and artifact reference.

Signals and cohorts

Unresolved experience Signals and affected cohorts remain visible without being promoted into verified identity.

Integrity and URLs

Canonical hashes, signature, verifier reference, and stable/version URL identities make the record portable and account-free.

Example release

Consider an invitation change. The release identity binds one commit, pull request, preview build, and environment. A changed Journey Version covers the owner desktop context. The Run contains passing functional, visual, and accessibility evidence. A visual Decision approves the current Observation. A time-bounded accessibility risk Decision remains visible with expiry.

Engineering confirms build and functional evidence. Documentation confirms the updated help path. Accessibility/design confirms the Decision and exception. Marketing confirms approved launch media. A Publication item includes the updated documentation version and delivery receipt. An unresolved support Signal records a possible role gap for an affected cohort.

The Release Book can be signed only after these relationships validate.

Fail-closed compilation

Compilation rejects:

• incomplete owner readiness;
• changed Journeys without included executed contexts;
• mismatched Run hashes;
• Decisions detached from their exact Run or evidence;
• Publications without canonical identity or receipt;
• approved media without an included Decision, exact evidence, content hash, or artifact;
• invalid or duplicate Signals;
• affected cohorts without supporting Signal policy;
• non-HTTPS, unsafe, or identical stable/version URLs.

That strictness prevents a polished release artifact from masking missing consequences.

Cryptographic integrity

Each item has a SHA-256 hash over canonical JSON. The body has a content hash. An Ed25519 signature covers a domain-separated payload containing the body hash. The offline package includes the public key.

The account-free verifier checks structure, section order, duplicate identities, item hashes, body hash, public-key fingerprint, and signature. Cryptographic success shows that bytes have not changed under the included key. Trust requires verifying that key through an independent channel.

Human and machine views

The human view groups item title, status, and evidence by canonical section. Owner views show readiness actions for engineering, support/docs, accessibility/design, and marketing. The machine export contains the complete signed object.

Reconciliation compares item identity and item hash. A separate generated summary cannot quietly replace or omit signed facts.

Risk and expiry

Accepted risk is not equivalent to pass. The item retains subject, owner, Decision, evidence, and expiry. At evaluation time an expired exception changes status and should reopen readiness work.

The Release Book should expose unresolved Signals and unsupported contexts rather than averaging them into a confidence score.

Corrections and key rotation

A signed record is immutable. Corrections create a new signed revision that points to the prior revision and the Decision and Observation supporting the correction. The stable URL can advance; the immutable version URL must not be overwritten.

If an issuer key rotates, publish the new fingerprint through an independently trusted channel and preserve the historical key needed to verify earlier versions. A compromised key requires explicit revocation and reissuance policy, not silent replacement.

Privacy boundary

The Release Book should contain only the evidence references and sanitized payloads needed for release understanding. Private Run artifacts, customer identifiers, authentication state, and internal diagnostics remain protected. A public content hash does not authorize public access to the underlying bytes.

Consumer trust model

Verification answers “are these bytes intact under this key?” Origin trust answers “is this key controlled by the expected issuer?” Evidence review answers “do these signed claims support readiness?” Keep the three questions separate in user interfaces and APIs.

Publications are release evidence

An approved documentation or media artifact is not delivered until the Channel provides a receipt and the served version is verified where possible. Stable URLs point to the current approved version. Immutable URLs preserve each historical version.

Copied PDFs, social images, offline demos, and slide decks remain distinct Publication versions.

When to issue a Release Book

Use one for a release where changed product outcomes cross engineering, QA, documentation, support, accessibility/design, marketing, or external delivery. A small internal code change with no outward or governance consequence may not need the complete structure.

The cost should be proportional to release risk, but required evidence cannot be waived by calling the release small.

Verify an example

Open the Release Book Verifier, load the signed synthetic example, and inspect each verification result. Then change an item title and verify again. The content and item hashes fail even though the JSON remains readable.

Continue with the Open Release Book Manifest, Release Readiness Beyond a Checklist, and Release Evidence for Product Journeys.