Product Journey Release Verification

Product Journey Release Verification connects a release’s commits and builds to changed Journey Versions, declared contexts, exact evidence, attributable Decisions, outward-content consequences, owner readiness, and a signed Release Book.

Bind the release

Record release ID/version, commits, pull requests, builds, environments, and time. Reject evidence from another build or environment.

Resolve changed outcomes

Map code, route, component, target, state, and flag changes to affected Journeys. Direct graph evidence can establish impact; similarity produces candidates for Review.

Select contexts

Declare roles, plans, data, flags, locales, themes, viewports, clocks, dependencies, motion, and side effects that change meaning. Record selected, skipped, and unsupported cells. Avoid a blind Cartesian matrix.

Run and retain evidence

Bind native source, State Capsule, runner identity, attempts, timelines, and functional, visual, accessibility, state, target, privacy, policy, network, and console evidence. Preserve initial failures and retries.

Diagnose

Product failure, state mismatch, missing target, visual change, accessibility barrier, privacy/policy violation, and infrastructure exception require different owners and actions. Only infrastructure retries automatically under policy.

Decide

Record actor, authority, subject, exact evidence, outcome, rationale, policy, expiry, and supersession. Accepted risk remains visible and expires. A passing test does not create an approval.

Resolve outward impact

Identify affected documentation, support, training, demos, launch media, and other Publications. Choose keep, refresh, merge, redirect, block, or retire. Require approved Renditions and delivery receipts for changed versions.

Complete readiness

Engineering, support/docs, accessibility/design, and marketing complete assigned evidence-backed actions in one revisioned workspace. One coordinator cannot invent all four judgments.

Sign and verify

Compile the ten-section Release Book, hash every item and body, sign the domain-separated content hash with Ed25519, and verify the offline package. Independently trust the issuer key and review substantive claims.

Example failure

The Run passes, but the help article has no current receipt and launch media shows an old role. Engineering evidence is green; outward readiness is not. The Release Book retains the gap instead of averaging it away.

Correction and rollback

When a released outcome is wrong, record the affected Journey Versions, contexts, Publications, and cohorts. A rollback can restore code while documentation or demos still describe the failed release. Treat each outward version explicitly.

Issue a corrected signed Release Book rather than editing prior signed bytes. Preserve the prior version and independently trusted key history.

Account-free verification boundary

Offline verification checks section order, item hashes, body hash, public-key fingerprint, and Ed25519 signature. It proves integrity under the included key. Obtain the issuer fingerprint independently and inspect evidence/Decisions before trusting readiness.

Metrics

Track changed Journeys with current evidence, selected/unsupported contexts, effective Decisions, owner actions, Publication receipts, expired risk, unresolved Signals, and verified Release Books. Deployment frequency and test count remain separate.

Monitor human/machine Release Book reconciliation, signature verification, key rotation, correction revisions, and served-hash mismatch. A valid signature with an untrusted key or false claim is not readiness.

Keep historic release records addressable under immutable URLs and route the stable URL to the current approved version.

Never overwrite signed history after any release correction.

Anti-patterns

• approving from CI status without exact evidence;
• retrying product failures into green;
• calling accepted risk a pass;
• omitting unsupported contexts;
• marking docs ready after an upload without served verification;
• updating release dates without material hashes;
• using a fixture key as production trust.

First implementation

Use one release with one changed critical Journey and one affected Publication. Complete the full path, then remove a receipt or expire a Decision and confirm verification/readiness fails.

Continue with Product Journey Runs, Product Journey Review, and Release Evidence for Product Journeys.