Why the promotion exists

ADR-0005, verbatim:

• **content_hash SHOULD be present whenever the Producer holds the parent bytes.** It is the strongest identity claim available (it binds to exact bytes and to any C2PA manifest) and the only one stable across producers, but it does not satisfy the resolvability rule on its own: a digest says what the parent is and not where a statement about it can be found. A parent reference with no content_hash draws a conformance warning, and is an error in a named high-trust profile — a profile that is itself a ratification deliverable.

Draft §3.3 states the same rule normatively — "A parent reference carrying no content_hash SHOULD draw a conformance warning, and MUST be an error in a named high-trust profile (§3.5)" — and the two-severity shape is deliberate on both sides of the split:

• Warning in the base profile, because the absence is sometimes correct. ADR-0005's own Consequences record the case: a Producer that composed from a parent it no longer holds, or that never held the bytes, cannot state a content_hash and is not lying when it omits one. Making that an error in the general profile would price a truthful Record out of conformance.
• Error here, because a deployment that has decided lineage claims must be checkable needs the one identifier that is checkable across producers. Every other parent identifier is a pointer: record_uri and `{producer_id, record_id}` say where a statement about the parent can be found, which is a resolvability property and not an identity one, and pixel_hash resolves to a candidate set rather than to an asset (E27). Only content_hash lets a Consumer confirm that the thing it resolved is the thing the Producer meant.

A profile is the right instrument for that difference. The alternative — one severity for everybody — either blocks honest Records or leaves a high-assurance deployment with no way to say what it requires, and both are worse than naming the stricter policy and letting an operator select it.