Release Evidence for Product Journeys

Release Evidence for Product Journeys connects a software release to observable product outcomes rather than relying on test counts, ticket status, or a checklist alone. The evidence identifies which Journey Version ran, which context cells were executed, what was observed, who decided what it means, which outward outputs are current, and which risks remain.

Establish release identity

Bind release ID and version to commits, pull requests, builds, environments, and time. Every referenced build must belong to a declared commit and environment. Avoid a release document that combines evidence from unrelated deployments.

Resolve source change into Journey impact

Map changed code, routes, components, targets, state, and feature flags to affected Journeys and context cells. Direct code relationships are stronger evidence than keyword or embedding similarity. Candidate impact can trigger Review but cannot become a verified claim without confirmation.

Record unchanged critical Journeys when release policy requires them, but do not imply complete coverage from an unrelated smoke test.

Execute declared contexts

For each changed Journey Version, identify the representative roles, plans, data, flags, locales, themes, viewports, clocks, dependencies, and side-effect policies. Preserve selected, skipped, and unsupported context cells with reasons.

Coverage should distinguish outcome evidence, context execution, current Decisions, and downstream lineage. Do not average the axes into one score.

Retain peer evidence

Functional, visual, automated/manual accessibility, state, target, console, network, privacy, policy, and performance-adjacent evidence belong on exact step/Observation timelines. A visual pass cannot hide a functional failure. A functional pass cannot resolve an accessibility barrier or privacy leak.

Initial infrastructure failures remain visible when a retry passes. Product, state, target, privacy, and policy failures are not retried into silence.

Classify before deciding

Classify product, state, target, infrastructure, visual, accessibility, privacy, and policy findings. Route each subject to an actor with appropriate authority.

An effective Decision binds actor, authority, Journey, version, Run, Observations, evidence, outcome, rationale, policy, time, and supersession. Accepted risk retains owner and expiry. Expired exceptions reopen readiness.

Require owner-specific readiness

Engineering confirms build and product evidence. Support or documentation confirms outward guidance. Accessibility or design confirms its evidence and Decisions. Marketing confirms approved launch media. Each action has required evidence and an assigned owner.

One release manager can coordinate but should not fabricate the separate owner judgments.

Prove outward consequences

Connect changed product outcomes to documentation, support, training, demos, launch media, and other Publications. For each affected output, record keep, refresh, merge, redirect, block, or retire.

An updated Rendition needs an approving Decision and content identity. Delivery needs a receipt and stable/version URL relationship. Verify the served destination where possible.

Preserve unresolved Signals

Support conversations, product feedback, and other experience Signals can indicate affected cohorts without proving Journey mapping. Retain source reference, privacy class, bounded evidence, mapping confidence, and human-confirmation state.

Release evidence is more credible when it exposes uncertainty rather than turning every Signal into a confirmed defect.

Sign the Release Book

Compile the validated facts into the canonical ten-section Release Book. Hash each item, hash the body, and sign the domain-separated content hash with Ed25519. Produce a portable offline package with the public key.

Keep issuer keys stable and monitor the independently trusted key fingerprint. Embedding a key proves integrity under that key, not origin trust by itself.

Verify offline

An account-free verifier checks:

• package contract and schema;
• section order and duplicate item IDs;
• every item hash;
• body content hash;
• public-key fingerprint;
• Ed25519 signature.

Use the Release Book Verifier. Review the actual claims and evidence after cryptographic verification passes.

Avoid false evidence

Do not include package-only capability as completed customer behavior. Do not relabel fixtures as customer outcomes. Do not report a queued Publication as delivered. Do not hide unsupported contexts. Do not change dates without material evidence. Do not treat an accepted risk as a pass.

Evidence retention and privacy

Assign retention by evidence type and release obligation. Keep public Release Book references minimal and sanitized. Private Run artifacts, storage state, customer identifiers, internal logs, and security-sensitive diagnostics remain under workspace access, holds, and deletion policy.

When evidence expires or is lawfully deleted, preserve the allowable integrity and decision record without pretending the underlying artifact remains available. A public hash can prove identity of bytes previously reviewed; it cannot reconstruct deleted content.

Key management

Use an Ed25519 issuer key controlled by the release authority, not a fixture key. Keep the private key out of source and client bundles. Publish the public-key fingerprint through a separately trusted channel. Define rotation, compromise, revocation, and historical verification behavior.

The embedded key in an offline package makes verification account-free but does not establish origin trust. A malicious package can sign itself with its own key.

Corrections

Never edit a signed Release Book in place. Create a new signed revision with explicit prior revision, correction Decision, and Observation lineage. Preserve stable and immutable URL behavior. If the old record exposed unsafe content, restrict delivery while keeping an audit-safe correction trail.

Consumer workflow

A human reviewer starts with release identity and outcome scope, checks unresolved risk and missing contexts, inspects evidence and Decisions, confirms outward receipts, and then verifies the cryptographic package. A machine consumer validates schema and integrity before indexing items. Neither consumer should infer truth from signature alone.

Minimum release-evidence checklist

1. exact release identity;
2. changed source and affected Journey mapping;
3. current immutable Journey Versions;
4. declared and executed contexts;
5. content-addressed Runs;
6. peer evidence and failure classification;
7. attributable current Decisions;
8. complete owner readiness;
9. affected outward-output consequences;
10. Publication receipts;
11. unresolved Signals and risk;
12. signed Release Book and trusted key process.

Measure evidence quality

Track valid release records, current Decisions, executed context coverage, Publication receipt coverage, expired risk, unresolved Signals, and human/machine reconciliation. Do not substitute deployment frequency, test count, or generated document volume for release truth.

Independent key trust and substantive evidence review remain mandatory.

Read Software Release Book, Release Readiness Beyond a Checklist, and the Open Release Book Manifest.