§4 Consumer checklist — 1.0.0 → 1.0.1

Required changes: none. A 1.0.0 consumer parses every 1.0.1 Record. That is the point of the two-plane design.

Recommended, in rough order of value:

1. Adopt the 1.0.1 schema for validation. You will start rejecting Records that were always non-conformant — wrong-width perceptual digests, undeclared members in the identity objects. Decide deliberately whether to reject or to quarantine; both are defensible, silently accepting is not.
2. Run the conformance profile, not just the schema. The schema cannot express referential integrity, role↔kind matching, digest verification, or chain chronology. Everything Appendix D #4 catalogued lives in the profile.
3. Stop treating pixel_hash as a primary key (annex E27, finding SPEC-27). It groups rendered identity. Two producers legitimately publish different Records with the same pixel_hash; asset and database identity belong to your system, keyed by whatever your system means by "asset" — commonly (producer, pixel_hash). If you key rows on pixel_hash alone you will lose records the moment a second producer appears.
4. Never compare pixel_hash values across cpnp_version. Read the field. It identifies a hash universe, and a defaulted value is how consumers end up comparing across universes (WIRE-13, WIRE-14).
5. Read identity.perceptual[].alg before comparing digests. Do not assume an algorithm from a digest's length, and do not compare across algorithms.
6. Filter by grade through E19's derivation. ocr_pixels→A, caption_auto→A−, caption_human/alt_text/title/description→B, surrounding_text/page_context→C. Grade-C sources are untrusted by definition (§12, context poisoning).
7. Treat perceptual digests and embeddings as similarity signals only. Never authentication, never integrity, never provenance. That is the byte tier and C2PA (§5, §12).
8. Believe redacted over absent. They are different states with different legal meanings. stripped_suspected is a third. A Record that conflates them is telling you something false about what happened to the asset.
9. Check image.source_bytes_ref.sha256 against identity.content_hash.value before fetching. If they disagree, the reference is not the asset the Record describes (annex E25).