Document Meta Muse Image Content Seal support with oracle-verified corpus

Muse Image (muse-image-1.0, Meta Superintelligence Labs, 2026-07-07) ships
every output with Content Seal, a proprietary invisible pixel watermark, and
no visible mark. Establish support documentation and a verified corpus:

- data/contentseal/: five own generations via the Meta Model API, every
  oracle verdict recorded in manifest.csv (44 rows, settled-text protocol,
  fresh-navigation variant for calibration rows)
- Oracle: meta.ai/identification web tool only; no API endpoint exists in
  the Meta Model API (verified against dev.meta.ai/docs); internal REST
  pair documented with its server-side sliding-window rate limit
- Removal: default qwen-zimage profile clears Content Seal (oracle-verified
  on the worst source); strength floor derived at 0.1 by the standard
  worst-boundary-plus-cross-source-spread method, recorded but not encoded
  as a constant since no provenance signal routes Muse output onto a vendor
  cohort
- Seal robustness measured: survives resize, JPEG q85, metadata stripping,
  CDN WebP transcode; dies to center crops and diffusion regeneration
- tests/test_contentseal_corpus.py guards manifest integrity

Co-Authored-By: Claude Fable 4.5 <noreply@anthropic.com>

docs/known-limitations.md

@@ -111,6 +111,14 @@ For important outputs:
 Provider systems can change, so a result verified on one file, seed, or version
 is not a permanent certification.
 
+Meta Content Seal (Muse Image) is in the same family: no local decoder, presence
+recognizable only through the XMP `trainedAlgorithmicMedia` companion tag while
+that metadata survives, and removal verifiable only through the anonymous
+`meta.ai/identification` oracle, which rate-limits by IP per day. The oracle's
+negative is weaker than its positive: Reuters measured it missing 55% of cropped
+Muse images, so treat a negative on a cropped or heavily edited file as
+inconclusive rather than clean.
+
 ### Video SynthID removal is lossy and content-dependent
 
 The `video invisible` command and `remove_video_invisible` API regenerate video

docs/module-internals.md

@@ -1149,6 +1149,40 @@ sizes the curve's own values verify clean, which is what a resolution-scaled
 requirement would predict. There is no measured size at which the shipped curve fails,
 so it is left alone.
 
+### Meta Content Seal boundaries for qwen-zimage
+
+Measured 2026-08-26 against the anonymous oracle `meta.ai/identification`
+(verdicts read from the settled page text; corpus and full row-level provenance in
+`data/contentseal/manifest.csv`). Muse Image carries no C2PA, so
+`vendor_for_strength` returns None for it and these images ride the default
+resolution-adaptive curve; there is deliberately no `meta` entry in the flat vendor
+map, because no provenance signal can establish that cohort automatically and an
+unreachable constant would be dead code.
+
+| source (2.56 MP generation) | detected at | clean from |
+|---|---|---|
+| gen_lighthouse_watercolor | 0.0525 | 0.06 |
+| gen_fox_forest | 0.03 | 0.0375 |
+| gen_night_city | 0.03 | 0.0375 |
+| gen_studio_mug | -- | 0.03 |
+| gen_text_poster | -- | 0.015 |
+
+Full spread: worst first-clean boundary (0.0525, 0.06] on lighthouse, easiest
+source already clean at 0.015. Following the same derivation as the OpenAI and
+Microsoft floors (worst clean boundary plus one full observed cross-source
+spread): 0.06 + (0.0525 - 0.015) = 0.0975, rounded up to **0.1**. This is a
+candidate `meta` floor, not yet a shipped constant: Muse outputs carry no C2PA,
+so `vendor_for_strength` has no signal that could route them onto the flat
+vendor map automatically. Encoding 0.1 as `QWEN_ZIMAGE_META_STRENGTH` makes
+sense only once the tool gains an explicit way to opt into a Meta cohort (for
+example a CLI `--vendor meta` override); the default resolution-adaptive curve
+(~0.1305 at 2.56 MP) already clears every measured source, so default behavior
+needs no change. Oracle verdicts carry a per-generation ID and creation timestamp
+embedded in the watermark payload; both survived the 512 px resize and JPEG q85
+rows, so payload recovery outlives the detection threshold. Oracle session
+limits are per-IP, server-side, and sliding-window: clearing cookies and storage
+does not reset them, and a burst exhausts the window minutes after it reopens.
+
 ### Static prompt embeddings
 
 Both stages prompt with module constants, and at CFG 1.0 DiffSynth's

docs/supported-signals.md

@@ -154,6 +154,31 @@ is the external oracle: it reports pixel `Watermark` and embedded `C2PA` results
 separately; a control-positive, output-negative pair is the available per-file
 verification path.
 
+Meta Muse Image stamps every output with Content Seal, a proprietary invisible
+pixel watermark, and ships no visible mark (the legacy `Imagined with AI`
+corner mark belongs to the pre-2026 Imagine pipeline and is not registered).
+This project has no local Content Seal decoder. Meta Model API outputs and
+Meta CDN copies carry an XMP `iptcExt:DigitalSourceType =
+trainedAlgorithmicMedia` companion tag, which `identify` reports through the
+existing Made-with-AI path; that IPTC code is a standard, not a Meta-exclusive
+signal, so it cannot key a strength cohort the way the C2PA issuer does. The
+external oracle is `https://meta.ai/identification`: anonymous, no login,
+accepts image, video, and audio, enforces an unspecified daily identification
+limit, and answers with model attribution (`Muse Image 1 - Meta`) plus a
+per-generation ID and creation timestamp read from the watermark payload. No
+identification endpoint exists in the Meta Model API itself (the reference at
+dev.meta.ai documents only generation and edits for images), and the official
+documentation never mentions the seal. The
+default `qwen-zimage` profile clears Content Seal at the default
+resolution-adaptive strength (oracle-verified on 2.56 MP generations); measured
+strength boundaries are recorded in `data/contentseal/manifest.csv` and
+[module internals](module-internals.md#meta-content-seal-boundaries-for-qwen-zimage)
+(derived Meta floor 0.1 by the standard spread method, not shipped as a constant
+because no provenance signal can route Muse output onto a vendor cohort).
+The seal survives resizing, JPEG recompression, and metadata stripping; it dies
+to center crops of a third to a half, matching the Reuters 2026-07-11 finding
+that Meta's detector missed 55% of cropped Muse images.
+
 For MP4, MOV, and M4V, `video invisible` or the explicit
 `video all --invisible` option can regenerate the video through a VAE and strip
 source metadata. The shipped profile is oracle-certified, but it is not a local
@@ -174,6 +199,7 @@ not a universal clean verdict.
 | Google Gemini | Sparkle | Diffusion regeneration for SynthID | C2PA and related source signals |
 | Google Veo video | Veo diamond and legacy text | Oracle-certified VAE removal for SynthID | C2PA and related source signals |
 | OpenAI image generators | None registered | Diffusion regeneration for supported invisible signals | C2PA and generator provenance |
+| Meta Muse Image | None on Muse output (legacy `Imagined with AI` unregistered) | Diffusion regeneration for Content Seal, oracle-verified on the default profile | XMP IPTC `trainedAlgorithmicMedia` companion tag; no local Content Seal decoder |
 | Microsoft Paint and Photos | None registered | External Microsoft oracle for InvisMark; no validated local decoder | Paint C2PA soft-binding algorithm and identifier |
 | Stable Diffusion and SDXL | None registered | Diffusion regeneration; optional open decoder | Embedded parameters and text metadata |
 | FLUX | None registered | Diffusion regeneration; optional open decoder | C2PA for supported sources |

docs/watermarking-landscape.md

@@ -133,7 +133,7 @@ auditable detection boundary than the provider-specific synthetic path here.
 
 **The faint-visible-mark precision/recall wall is fundamental, not a heuristic artifact.** The visible-watermark-detection literature has moved to LEARNED segmentation / object-detection (WDNet WACV'21 arXiv:2012.07616; SLBR ACM MM'21, open code+weights; the PRCV'18 large-scale detector; Su et al. survey 2025), but three verified findings bound what a learned detector actually buys: (1) a claim that a confidence threshold "cleanly separates" true from false matches even with a learned CNN front-end was **REFUTED** in verification (arXiv:1705.08593) -- the precision/recall wall persists even with learned features. (2) Learned detectors need a LARGE, pattern-diverse labeled dataset trained on synthetic composites (PRCV'18: 60k images / 80 watermark classes; CLWD: 60k / 160 marks), and off-distribution degradation is a documented real axis (models trained on limited-pattern LVW transfer worse; diversity of training patterns drives generalization). (3) Inference is cheap (WDNet ~8 ms at 256x256) -- the cost is the data pipeline, not runtime. Net: a learned detector shifts the frontier but does NOT remove the wall; for a SINGLE mark the cheapest next step is a small patch classifier (real-sparkle vs false-positive) on top of the existing NCC localizer, not a full segmentation model. SLBR is a ready baseline. The current NCC + false-positive gate (core-ring brightness margin + gradient-NCC crispness + white-core saturation) is a sound operating point, and the residual miss is the information-theoretic wall the literature confirms.
 
-**Visible-mark landscape beyond the registry.** Meta stamps a visible "Imagined with AI" mark (bottom-LEFT, a small symbol) on its OWN Meta AI / "Imagine" output; for third-party images it relies on C2PA / IPTC, not a visible mark. Samsung Galaxy AI additionally uses a **four-star icon** variant in a corner alongside the localized text wordmark `samsung_engine` calibrates (only the Italian text variant is covered) -- the icon is a distinct, uncovered variant. Every source agrees visible + metadata marks are trivially removable (crop / screenshot, ~2 s), which is the tool's premise.
+**Visible-mark landscape beyond the registry.** Since Muse Image (2026-07) Meta's own generation output carries NO visible mark, only the invisible proprietary Content Seal; the legacy visible "Imagined with AI" mark (bottom-LEFT, a small symbol) belongs to the pre-2026 Meta AI / "Imagine" pipeline and remains unregistered (string verified, position not). For third-party images Meta relies on C2PA / IPTC, not a visible mark. Samsung Galaxy AI additionally uses a **four-star icon** variant in a corner alongside the localized text wordmark `samsung_engine` calibrates (only the Italian text variant is covered) -- the icon is a distinct, uncovered variant. Every source agrees visible + metadata marks are trivially removable (crop / screenshot, ~2 s), which is the tool's premise.
 
 **Regulatory driver -- China GB 45438-2025 is the strongest VISIBLE-mark mandate.** The CAC / TC260 "Measures for Labeling AI-Generated Synthesized Content" (issued March 2025, **effective 2025-09-01**, technical standard **GB 45438-2025**, building on the TC260 Aug-2023 practice guide) MANDATE a **visible** label for AI images -- a visible textual mark whose height must be **>= 5% of the image's shortest side** -- plus the metadata (implicit) label. Several such CJK text marks are now registered; see [supported signals](supported-signals.md) for the current list. By contrast EU AI Act Article 50 mandates only the MACHINE-READABLE mark (enforceable 2026-08-02, grace to 2026-12-02); a visible label is proposed and modality-specific (visible for images) but is NOT a hard "fixed icon" mandate -- a claim that Art 50 requires a clearly-visible fixed icon for images was refuted in verification. Primary-source dates verified against the article/standard text, not search summaries.
 
@@ -161,6 +161,8 @@ Two consequences we can exploit: (1) the 5% floor is a **scale prior** -- a comp
 
 **Tencent Yuanbao: RESOLVED 2026-07-25, registered (`yuanbao_engine.py`).** The standard mark is a compact two-line italic `元宝` over `AI生成` block at bottom-right. It switches between light and dark strokes with the scene, so detection uses polarity-independent local contrast rather than a white top-hat. The separate one-line overlay variant remains evidence-limited to one example.
 
+**Meta Muse Image / Content Seal: current state VERIFIED 2026-08-26 against live artifacts.** Muse Image (launched 2026-07-07, first image model from Meta Superintelligence Labs) puts no visible mark on output. Every output carries Content Seal, a proprietary invisible pixel watermark; research lineage is open (`github.com/facebookresearch/content-seal`, Pixel Seal / VideoSeal / Watermark Anything), but the deployed implementation is proprietary and unpublished. API outputs and Meta CDN copies also carry XMP `iptcExt:DigitalSourceType = trainedAlgorithmicMedia` (a standard IPTC code, not Meta-exclusive). The only reader is the anonymous web oracle `meta.ai/identification`, which returns model attribution plus a per-generation ID and timestamp embedded in the payload. Verified robustness (our corpus, `data/contentseal/`): seal survives CDN WebP transcode, 512 px resize, JPEG q85, and full metadata stripping; it is lost to center crops of 33-50% linear size (Reuters measured 55% detector misses on cropped images, 2026-07-11). The default `qwen-zimage` profile clears it (oracle-verified). Legacy paragraph retained below.
+
 **Meta `Imagined with AI` (string VERIFIED (a) from Meta's own newsroom; POSITION NOT VERIFIED).** Sources conflict on placement. Do not encode a corner without a verified sample. `identify` reads the supported IPTC disclosure; it does not decode Meta's proprietary invisible watermark. Source: `https://about.fb.com/news/2024/02/labeling-ai-generated-images-on-facebook-instagram-and-threads/`.
 
 **Samsung English/other locales: still not established.** Samsung's own support page says only that "A Galaxy AI watermark will appear on AI-generated images" -- no string, no corner. Every community thread carrying the exact English string returned HTTP 403 to WebFetch, so the search paraphrase (bottom-left) is deliberately NOT recorded as fact. Feature-tier detail (b): the mark is applied by Generative Edit / sketch-to-image but reportedly NOT by Object Eraser, so Samsung absence is feature-dependent. The four-star icon variant: nothing found.