Check the C2PA manifest bound to a rendered document (C2PA 2.4 §A.7)

[Tippel-AI]

A claim in our own docs was wrong

README.md and docs/DISCLAIMER.md stated that there is no established
machine-readable standard for marking generated text in an HTML document "the
way C2PA marks media", and used that to justify checking only the watermark on a
rendered page.

That was false when it was written. C2PA Technical Specification 2.4 (April
2026) added:

• §A.7 — Embedding Manifests into HTML. A normative binding for HTML
  documents, with three delivery forms: an inline <script type="application/c2pa">,
  an external <link rel="c2pa-manifest">, and an RFC 8288 Link: HTTP header
  with rel=c2pa-manifest (§15.5.3.2).
• §18.28 — AI Disclosure. A c2pa.ai-disclosure assertion carrying
  modelType and humanOversightLevel, mapped to IPTC
  digitalSourceType: trainedAlgorithmicMedia. The 2.4 changelog describes it as
  "a new AI Disclosure Assertion (c2pa.ai-disclosure) for machine-readable AI
  transparency info".

Verified 31.08.2026 against
https://spec.c2pa.org/specifications/specifications/2.4/specs/C2PA_Specification.html

The docs are corrected in the same PR that opens this issue. This issue is the
rule the correction points at.

Why it matters more than it looks

This is the exact surface markproof exists for. A C2PA manifest bound to an HTML
document by byte offset is more fragile than one embedded in a JPEG, not less:
C2PA's own §A.7.1.3 warns that any CMS, CDN or formatter that re-serialises the
document invalidates the binding. A template change, a minifier, an HTML-rewriting
CDN feature — each silently breaks the mark while the page still renders
perfectly. Nothing crashes, no test goes red. That is the whole thesis of this
project, in a format we currently do not check.

It also closes a real gap for anyone generating web copy: they now have a
standards-based way to comply with Art. 50(2), and no way to find out whether it
survived to the reader.

Proposed rule

MPF-M-002 — a C2PA manifest is bound to the delivered document and declares an
AI source type.

• New check type, or an extension of c2pa-verify to ui probes.
• Must resolve the manifest the way a verifier would: inline script, external
  link, and the Link: response header. The header form needs the UI probe to
  surface response headers, which it does not do today.
• Must verify the byte-offset binding against the document as delivered, since
  that is precisely what re-serialisation breaks.
• Should report the c2pa.ai-disclosure assertion's humanOversightLevel rather
  than only pass/fail — fully_autonomous and human_validated are different
  claims and a report that flattened them would lose the interesting part.

Dependency

The official c2pa-rs / c2pa-python SDK does not support HTML. The only known
implementation of §A.7 is a third-party library. Before building, establish
whether we verify through a dependency or implement the binding check directly —
the parsing side is not large, and taking a young dependency into the evaluation
path of a compliance tool needs an argument.

Acceptance

• Decision recorded on dependency vs own implementation
• Manifest resolution covering all three delivery forms
• Binding verified against the delivered bytes, with a test that a
  re-serialised document fails
• humanOversightLevel and digitalSourceType surfaced in the finding
• docs/RULES_SOURCES.md §10.6 updated when the rule lands