Open Release Book Manifest

The Open Release Book Manifest defines a portable, content-addressed, item-hashed, Ed25519-signed record of release truth. It reconciles source changes, changed Journeys and contexts, verification results, Decisions and accepted risk, readiness actions, Publications, approved media, unresolved signals, affected cohorts, integrity, and stable/version URLs.

The manifest is an open technical contract. A cryptographically valid Release Book proves integrity under a key; it does not prove that the key should be trusted or that the release claims are correct.

Contract resources

• Contract index
• Signed Release Book JSON Schema
• Offline package JSON Schema
• Signed verifier example
• Account-free Release Book Verifier

The schemas use JSON Schema Draft 2020-12 and stable versioned URLs. The example uses a public fixture key and synthetic records. It is not release or customer evidence.

Canonical section order

Version 1 requires these ten sections in order:

1. identity;
2. source changes;
3. Journeys and contexts;
4. verification;
5. Decisions and risk;
6. support and documentation;
7. Publications;
8. approved media;
9. signals and cohorts;
10. integrity and URLs.

Human, owner, and machine views must reconcile item-for-item over the same signed records. A view can filter or present information, but it cannot invent a separate fact set.

Release identity

The identity records release ID, name, version, commits, pull requests, builds, environments, and release time. Builds must bind to declared commits and environments. This prevents a Release Book from combining unrelated deployment facts under one title.

Exact Journey evidence

Changed Journey items identify the Journey Version, executed context cells, change references, and owner. Verification items reference content-addressed Runs and exact evidence. Decisions must link to Observations and evidence inside those Runs.

The compiler fails closed when a Run hash is wrong, a changed Journey lacks an included executed context, or a Decision points outside its exact Run.

Readiness ownership

The current contract requires one completed action for each owner group:

• engineering;
• support or documentation;
• accessibility or design;
• marketing.

Each action identifies its assigned owner and required evidence. Revision conflicts and missing evidence fail. A generic release-manager checkbox cannot silently stand in for every subject owner.

Publications and approved media

Publication items require canonical identity, stable and immutable HTTPS URLs, source evidence, and a delivery receipt. Approved media requires a content hash, included approval Decision, exact Run evidence, and an artifact reference.

An accepted upload or generated file is not a delivered release consequence without the receipt.

Signals, cohorts, and risk

The Release Book can retain unresolved Signals and affected cohorts without pretending uncertain mapping is verified. Accepted-risk Decisions remain explicit and can expire. An expired exception changes status rather than remaining a permanent green result.

Private source data should remain bounded by its retention and privacy policy. The public Release Book contains only intentional references and sanitized evidence.

Integrity model

Each item is canonicalized by recursively sorting object keys, preserving array order, and serializing JSON primitives exactly. The item hash is SHA-256 over the canonical item body without itemHash.

The Release Book content hash is SHA-256 over the canonical body. The Ed25519 signature signs the canonical domain-separated value:

{"contentHash":"<sha256>","domain":"journey/release-book/v1"}

The offline package includes the SPKI public key. Its key ID is ed25519: plus the SHA-256 of the DER-encoded SPKI key.

Verification procedure

An account-free verifier must:

1. validate package contract and schema version;
2. validate the canonical section order;
3. reject duplicate item identities;
4. recompute every item hash;
5. recompute the complete body hash;
6. compute and compare the public-key fingerprint;
7. verify the Ed25519 signature over the domain-separated content hash;
8. report each result separately;
9. avoid converting integrity into release approval.

The browser Release Book Verifier performs these steps locally without uploading the package.

Stable and immutable identities

A Release Book should expose one stable URL for the current approved version and a distinct immutable URL for each release version. Both use HTTPS. Historical versions remain addressable for audit, while the stable URL continues the release intent.

Do not overwrite an immutable version or redirect it to unrelated release content.

License and evolution

The public manifest schemas and example are released under Apache-2.0; benchmark datasets use their stated dataset license. Version 1 additions must remain backward compatible or introduce a new schema version and migration guidance.

Changes require a changelog, test fixtures, valid and tampered examples, browser and Node verification parity, and stable version anchors. Never alter canonicalization or signature domain silently.

The example key is intentionally public and must never be trusted for a real release. Production issuers supply their own protected key and an independently discoverable public fingerprint.

Consumers should obtain or pin that fingerprint outside the package.

Trust is contextual.

Read Software Release Book, Release Evidence for Product Journeys, and the Release Truth Benchmark methodology.