Improve C2PA attribution and ByteDance metadata handling

docs/module-internals.md

@@ -367,6 +367,11 @@ for partial and synthetic fixtures that the official reader rejects.
 Vendor attribution comes from the registry in
 [`_internal/constants.py`](../src/remove_ai_watermarks/_internal/constants.py). Derived
 issuer and platform maps should not be maintained separately.
+For an AI C2PA claim, a recognized product in `claim_generator` takes precedence
+over the certificate issuer: an application can sign through an upstream model
+provider without becoming that provider's product. Only exact product mappings
+receive this precedence; an unknown claim generator still falls back to issuer
+attribution.
 
 ### Metadata scanning and stripping
 
@@ -387,6 +392,11 @@ Key contracts:
   "the credentials could not be read", and the second silently downgrades a verdict.
 - JPEG stripping walks metadata segments and preserves the entropy-coded image
   scan.
+- Exact app-export JSON disclosures in EXIF `ImageDescription` or `UserComment`
+  share one parser. Known AI-product provenance is removable without by itself
+  asserting that the pixels were generated; explicit `aigc_info` discriminator
+  values and Dreamina `exportType=generation` do assert AI origin. Ordinary
+  Aweme, retouch, and `lv` editor exports are preserved.
 - ISOBMFF containers use
   [`_internal/isobmff.py`](../src/remove_ai_watermarks/_internal/isobmff.py).
 - Native MP4/MOV TC260 `AIGC` entries are read from

docs/supported-signals.md

@@ -67,6 +67,9 @@ The inspection and stripping code handles signals in these groups:
 
 - C2PA Content Credentials and supported cloud manifest references;
 - EXIF and XMP generator fields;
+- exact app-export provenance and AIGC disclosures from supported
+  ByteDance-family products, with product-only provenance excluded from the
+  generated-image verdict;
 - IPTC AI disclosure fields;
 - PNG text chunks and embedded generation parameters;
 - China TC260 AIGC labels in supported image placements and the normative
@@ -153,7 +156,7 @@ not a universal clean verdict.
 | FLUX | None registered | Diffusion regeneration; optional open decoder | C2PA for supported sources |
 | Adobe Firefly | None registered | No proprietary local decoder | C2PA; optional TrustMark decoder |
 | Midjourney | None registered | No registered pixel decoder | EXIF, XMP, and IPTC signals |
-| ByteDance generators | Doubao and Jimeng marks | No registered pixel decoder | TC260 AIGC and supported C2PA signals |
+| ByteDance generators | Doubao and Jimeng marks | No registered pixel decoder | TC260 AIGC, supported C2PA, and exact app-export AIGC disclosures |
 | Qwen | Qwen mark | No registered pixel decoder | TC260 AIGC |
 | Kling | Kling image and video marks | No registered pixel decoder | TC260 AIGC |
 | Hailuo / MiniMax video | Hailuo composite video label | No registered pixel decoder | TC260 AIGC where present |

docs/watermarking-landscape.md

@@ -22,8 +22,15 @@ icon-only variants need separate calibrated silhouettes.
 
 **Black Forest Labs (FLUX)** API output signs C2PA: `claim_generator_info "Black Forest Labs API"` + a `c2pa.ai_generated_content` assertion + `trainedAlgorithmicMedia` (issuer `b"Black Forest Labs"` added to `C2PA_ISSUERS`, platform "Black Forest Labs (FLUX)").
 
+Some applications sign C2PA through an upstream model or infrastructure
+provider. For AI claims, exact product mappings in `claim_generator` therefore
+take precedence over issuer attribution. Supported mappings include Higgsfield
+AI, Topaz Labs Image API, and TikTok Ad Creative Toolbox; an unknown claim
+generator still falls back to the certificate issuer.
+
 **ByteDance Volcano Engine (Volcengine)** — the cloud behind Doubao / Jimeng — signs its AI image output with a cert from `certificate_center@volcengine.com` + `trainedAlgorithmicMedia` (issuer `b"volcengine"` → "ByteDance (Volcano Engine)", platform "ByteDance (Doubao / Jimeng / Volcano Engine)"); note this is the C2PA-signed surface, distinct from the XMP/PNG TC260 `AIGC` label Doubao also uses. ByteDance's **international brand (BytePlus / Seedream / Seededit)** signs the same content as **"Byteplus Pte. Ltd."**. The bare `volcengine` needle missed it, so BytePlus output was mis-attributed to "Adobe Firefly" through an incidental "Adobe XMP" toolkit string. Issuer `b"Byteplus"` now maps directly to "BytePlus (ByteDance)". ByteDance's consumer app **Dreamina** (the international Jimeng brand) signs as **"Bytedance Pte. Ltd."** with a `Dreamina/x.y` claim generator but, unlike the Volcano Engine surface, ships **no `trainedAlgorithmicMedia`**. Issuer `b"Dreamina"` maps to "ByteDance (Dreamina)" with **`asserts_ai=True`**. Registering the broader **issuer** `b"Bytedance Pte"` was deliberately avoided because that same entity also signs non-AI CapCut edits; keying on the `Dreamina` generator token is precise.
 - **EXIF/XMP/PNG-text generator tag (caught by `exif_generator`):** **Ideogram** writes EXIF `Make="Ideogram AI"` (collected 2026-05-24 — no C2PA, no SynthID, no imwatermark; the Make tag is the only signal). Additional verified generator stamps include **NovelAI** (`Software`, `Source`, and `Title` PNG text chunks), **Reve** (`Software` or XMP `CreatorTool` = `reve.com`), and **Aphrodite AI** (`Make` or `Software` = `Aphrodite AI`).
+- **App-export provenance and AIGC JSON:** supported ByteDance-family exports can place a JSON object in EXIF `ImageDescription` or `UserComment`, independently of C2PA or TC260. Exact `product` values for Doubao, Xinghui, and Dreamina are removable product provenance, but do not alone prove that the pixels were generated. Dreamina additionally requires `exportType=generation` for that verdict. A nested Aweme `aigc_type=1` or private ByteDance `aigc_label_type=1` / `2` is an AIGC disclosure; `0` is inconclusive and can occur on a Dreamina generation export. Plain Aweme, retouch, and `lv` exports are preserved. The lower-case private field is deliberately not interpreted as the normative TC260 `Label`, whose values `1` / `2` / `3` mean generated / possibly generated / suspected generated under [GB 45438-2025](https://www.tc260.org.cn/upload/2025-03-15/1742009439794081593.pdf).
 - **xAI / Grok — its own EXIF signature scheme, NOT C2PA (DETECTED by `metadata.xai_signature`, built 2026-05-26).**
 
 Grok JPEG downloads (Aurora model) carry **no C2PA, no XMP, no SynthID, no IPTC** — only EXIF `Artist` = a UUID and EXIF `ImageDescription` = `Signature: <base64>` (a crypto signature, unverifiable locally without xAI's public key). This empirically kills the earlier unverified "xAI signs C2PA as xAI" lead — xAI is not even a C2PA member. `exif_generator` misses it (neither field holds an `AI_GENERATOR_TOKENS` token), so a dedicated detector `xai_signature(path)` matches the pair (`ImageDescription ~ ^Signature: [A-Za-z0-9+/=]{64,}` AND UUID `Artist`); wired into `has_ai_metadata`, `get_ai_metadata` (key `xai_signature`), and `identify` (signal `xai_signature`, platform "xAI (Grok / Aurora)").