Public Release Manifest and Exact Assets

1. Separate release identity from URLs and filenames

Assume a public release contains Persian and English JSON, two images, and a stylesheet. Seeing the same filenames on a CDN does not prove that the reviewed bytes are the bytes now being served. URLs and filenames are delivery locations. Release identity must bind a manifest version and digest to exact asset descriptors. If the bytes behind an unchanged URL change, promotion must fail closed even when the page still looks correct.

2. CON-005 ownership boundary

CON-005 owns Public Release Manifest & Exact Asset Set v1: release ID/version, manifest digest, required asset set, asset role, media type, byte size, digest, locale/variant, and references to source, claim, rights, and approval evidence. CON-001 owns source/version authority; CON-002 owns claim evidence; CON-003 owns rights and embargo; CON-004 owns approval validity; CON-006 through CON-010 own public routing and rollback. This lesson binds those decisions without recreating them.

3. Use a descriptor as the unit of exact asset identity

For every asset, record an explicit descriptor: role, logical_name, media_type, size, and digest. OCI is a useful pattern because its descriptors bind media type, digest, and byte size and support independent verification of retrieved content. MAKNOW is not claiming that its editorial release manifest is an OCI image manifest; it borrows the content-addressed pattern to remove filename and URL ambiguity.

4. Digest and size prove different things

A matching digest with a conflicting declared size is an inconsistent descriptor, while a matching size without a digest says nothing about exact bytes. The release matrix therefore records both digest_verified and size_verified. byte_identity_ok is true only when both checks pass for every required asset.

5. Lock the required asset set before verification

Before fetching or promoting, declare exactly which assets the release requires. If a new locale file becomes required but the candidate manifest omits it, the problem is not merely a missing download; it is a completeness failure. Version the required set so a reviewer can distinguish an intentionally optional asset from an omitted requirement.

6. Preserve role and locale/variant as composition metadata

Two assets may have different digests but similar names, or may be desktop and mobile derivatives of one source. Keep role, locale, and variant alongside byte identity. A digest answers which bytes exist; role and locale explain what those bytes mean inside the release composition.

7. Treat mutable locators as delivery hints

A URL such as https://cdn.example/.../hero.jpg can point to one digest today and another tomorrow. Preserve the locator, but do not make it authoritative. The promotion pipeline fetches or reads the object and compares observed size/digest to the descriptor. Unchanged filename plus changed bytes yields BLOCK_DIGEST_MISMATCH.

8. Bind source, claim, rights, and approval independently

Assets or the release carry references such as source_binding_ref, claim_set_ref, rights_decision_ref, and approval_validity_ref. These references do not manufacture the upstream evidence; they bind the release to versioned upstream decisions. If an approval is revoked, exact bytes may remain valid while the release is no longer eligible.

9. Keep exact bytes and governance as separate axes

byte_identity_ok=true does not prove publication permission. Bytes can be exact while rights are embargoed or source authority is unbound. Conversely, rights and approval can be valid while a CDN object has changed. The correct release decision intersects byte/completeness evidence with current governance eligibility.

10. Use a manifest digest to bind the composition itself

After canonicalizing the descriptor set and relevant decision metadata, compute a manifest digest. That digest identifies the release composition. When the exact asset set changes, issue a new manifest version and digest instead of mutating the historical manifest in place. This preserves auditability and enables exact rollback.

11. Bound the role of Subresource Integrity

Subresource Integrity demonstrates binding an expected web resource representation to cryptographic integrity metadata that the user agent can check. That is useful evidence for exact-resource binding, but SRI is not a complete release-governance system: it does not model required locale sets, editorial rights, approvals, or source provenance. Use it as evidence for K3, not as a substitute for the MAKNOW manifest.

12. Preserve typed decision states

This lesson does not collapse every failure into one red flag. Example states include RELEASE_READY, BLOCK_DIGEST_MISMATCH, BLOCK_ASSET_MISSING, BLOCK_APPROVAL_INVALID, BLOCK_RIGHTS_INELIGIBLE, BLOCK_SOURCE_UNBOUND, and BLOCK_MANIFEST_VERSION. The reason should identify the failed evidence slice so remediation can remain bounded.

13. Negative example: same filename, different bytes

hero-fa.webp was reviewed at digest sha256:A. After review, the object at the same URL is overwritten and now has digest sha256:B. A URL-only workflow silently publishes the wrong object. Descriptor verification detects the mismatch, makes byte_identity_ok=false, and blocks promotion even if rights and approval remain current.

14. Transfer: new derivative and new locale asset

Keep the same release family, replace one image with a newly approved derivative, and add a required de locale asset. This changes composition, so it requires a new manifest version and digest. The old release remains historically reproducible. The new release must close completeness, digest verification, and governance bindings for the new set rather than inheriting proof from the previous manifest.

15. Auditable output

The final artifact is Public Release Manifest & Exact Asset Set v1. A reviewer should be able to answer without hidden UI state: Which assets are required? What role/media type/size/digest identifies each one? Which locator is used? Which source/claim/rights/approval versions are bound? Are assets present and verified? Is the manifest identity new when composition changed? Why is the release ready or blocked? Unknown or revoked states remain explicit; filenames, URLs, and green badges never turn them into success.