Release 0.37.1 with the Chroma tokenizer dependency

The check read `latest_version` on the node object, which reports only the
ACTIVE version. The registry reviews an upload before activating it, so for the
length of that review a correctly published version looks exactly like a release
that was never synced -- and 0.37.0 hit precisely that: the node repo bumped to
0.1.37 requiring >=0.37.0, the registry accepted it as
NodeVersionStatusPending, and the check called it missing.

Read the versions list instead and branch on the status: active passes, pending
passes while saying so in the summary rather than claiming the node is live, and
anything else fails. A missing version still fails hard, which is the case this
check exists for. Sort the matches by createdAt rather than trusting the
endpoint's current newest-first ordering.

Verified against the live registry in all three states: 0.37.0 pending, 0.36.0
active, 0.99.0 absent and erroring.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

.claude/rules/development.md

@@ -25,6 +25,21 @@ Boundary modules for cv2, Torch, and Diffusers may carry narrow per-file relaxat
 
 From a worktree, `uv run` imports the package from the MAIN checkout -- that is where the editable install points. A script measuring a worktree's edit must insert that worktree's `src` at `sys.path[0]` and assert `module.__file__` resolves inside it, or it silently compares unmodified code against itself.
 
+## Visible-mark example gallery
+
+Every registered mark carries a committed example: `data/fixtures/visible/<key>/example.png`
+(image marks) and `example.mp4` (video marks), regenerated by
+`scripts/render_visible_examples.py`. `tests/test_visible_examples.py` is the canary: it
+fails when a mark is registered without an example and when an engine stops detecting its
+own example. The examples are deterministic synthetic composites of the committed
+silhouettes. When the generator fails after a geometry or gate change, fix the generator
+(and the engine) together; do not hand-edit the binaries.
+
+Visible-mark content must distinguish the registry key, the provider's canonical
+product name, and the literal text rendered in the mark whenever those differ. Verify
+external provider names against the provider's official source rather than inferring
+them from an asset filename or OCR text.
+
 ## Model-adjacent tests
 
 Do not classify an entire module as untestable because its main path downloads a model. Keep pure behavior covered without downloads, including:
@@ -39,6 +54,9 @@ Do not classify an entire module as untestable because its main path downloads a
   stage's; `sdxl-zimage` shipped doing exactly that and crashed on every image with a
   face. When one profile inherits another's stage, guard the invariants that stage
   relies on, not just the code path.
+- the photo-classify gate in `test_classify.py`: DEFINITELY is ridge AND MLP,
+  POSSIBLY does not emit a provider, and `identify` does not import
+  `remove_ai_watermarks.classify`.
 - the `InvisibleOptions` defaults, in `test_api.py`. When one signature promises to
   mirror another, compare them field by field rather than pinning the values you happen
   to know about, so the next field added on one side and not the other fails at the
@@ -65,6 +83,32 @@ that is what actually happened.
 
 Use availability checks only for paths that actually load large models.
 
+A verdict branch must be reachable with the dependency stack as shipped. High-confidence
+C2PA attribution required `signingCredential.trusted`, a code the reader emits only when a
+trust anchor list is loaded, and none ships -- so the branch was dead in production for
+every vendor while a hand-built info dict stamping that code kept it green from 0.27.0
+through 0.30.0. Assert reachability against the committed fixtures rather than a synthesized
+status set; `TestIdentifyRealSamples::test_no_committed_fixture_reports_a_trusted_signer`
+is that guard. Read a capability the stack does not have as a missing input, never as a
+negative finding.
+
+## The docs are a seam, and they drift like one
+
+`tests/test_docs_cover_the_public_surface.py` reads the live Click tree and the
+live `InvisibleOptions` dataclass and requires every knob to be NAMED in the
+user-facing pages. The code-to-code seams were already guarded and the
+code-to-docs seam was not, so it drifted exactly the way an unguarded seam does:
+`docs/cli.md` named none of `--adaptive-polish`, `--controlnet-scale`,
+`--detect/--no-detect`, `--humanize`, `--strength`, `--tile-size`,
+`--tile-overlap` or `--unsharp`, and `docs/python-api.md` named 9 of the 16
+option fields.
+
+Group option spellings by the Click PARAMETER, never by string surgery on the
+names. A boolean pair can be spelled anything -- `--strip-metadata/--keep-metadata`,
+`--keep-standard/--remove-all` -- so deriving the partner from a `--no-` prefix
+silently splits those pairs and demands both halves. Either spelling documents
+the pair.
+
 ## One measurement, one gate seam
 
 A detector is split into a trust-level-blind scan and a verdict that applies the
@@ -79,6 +123,11 @@ rules follow, and both were broken in practice before they were written down:
 - Detection and the removal mask must read ONE sweep. The winning box travels on
   `TextMarkDetection.match_box` and the registry threads the detection into the mask
   builder; a mask path that re-runs its own sweep is how the two drift apart.
+- When the research lattice runtime in `scripts/synthid_runtime/` routes by image
+  geometry, preserve the returned `SynthIDDetection.detector` in score manifests
+  and downstream routers. Record an inactive expert as explicitly unsupported;
+  never attribute a routed large-image score to the fixed expert. This expert is
+  not part of the public package.
 
 The C2PA manifest-store JSON is NOT stable across reads: the reader regenerates manifest
 URNs and instance ids. Compare the derived `c2pa_info`, never the raw store.
@@ -98,6 +147,11 @@ record is byte-identical, and a green test suite does not establish that on its
 change that is meant to FIX detection is the exception that proves the rule: the diff
 must then be exactly the files you intended to change, named in advance.
 
+When the baseline is a published release rather than the previous commit, get it with
+`uv run --isolated --no-project --with 'remove-ai-watermarks[heif]==<version>' python <script>`:
+it resolves that release from PyPI without touching the working tree or the editable
+install. Quote the extra -- bare `pkg[extra]` is a glob in zsh.
+
 Two corollaries in `dwt_dct.py`, where "close enough" has an exact meaning. The bit test
 is `peak % 36 > 18.0` and for uint8 input the exact Haar value is a multiple of 0.5, so it
 lands ON the threshold once per 72 blocks and a 1-ulp difference flips real bits: leave the

.env.example

@@ -1,3 +1,7 @@
 # HuggingFace token (optional; only needed for gated/private models)
 # Get yours at: https://huggingface.co/settings/tokens
 # HF_TOKEN=
+
+# OpenAI API key (optional; only for explicit verify-openai-synthid uploads)
+# Create and manage keys at: https://platform.openai.com/api-keys
+# OPENAI_API_KEY=

.github/workflows/distribute.yml

@@ -4,7 +4,7 @@ name: Distribute on release
 # PyPI is handled by publish.yml. This workflow event-drives the three channels
 # that would otherwise be manual:
 #   - Homebrew tap: rewrite the formula's url + sha256 to the new sdist.
-#   - HF Space: factory-rebuild so it reinstalls the latest sdist from PyPI.
+#   - HF Space: factory-rebuild the version already pinned in the Space repo.
 #   - ComfyUI: sync, test, and publish the node against the exact library release.
 # All wait for the freshly published sdist to appear on PyPI first, since the
 # Release event fires in parallel with publish.yml's upload.

.github/workflows/publish-photo-classify-hf.yml

@@ -0,0 +1,72 @@
+name: Publish photo classifier to Hugging Face
+
+# Manual only. Not part of a library release. The Space demo
+# (wiltodelta/remove-ai-watermarks) stays on distribute.yml / raiw-hf-space.
+#
+# Hub model: wiltodelta/raiw-photo-classify
+# Secret: HF_TOKEN, write-role Hugging Face token (same secret Space sync uses).
+#
+# Weights are not in git. Full mode downloads them from a GitHub Release
+# of this repository, then uploads with the card from docs/photo-classify-hf/.
+
+on:
+  workflow_dispatch:
+    inputs:
+      confirm:
+        description: "Type publish"
+        required: true
+      mode:
+        description: "full = card plus weights from the release tag; card = README and operating-point only"
+        type: choice
+        options:
+          - full
+          - card
+        default: full
+      weights_tag:
+        description: "GitHub Release tag that holds clip-l-ft.pt, probe, detector.pt, provider.pt"
+        required: false
+        default: photo-classify-freeze-2026-08-31
+
+jobs:
+  publish:
+    if: ${{ github.event.inputs.confirm == 'publish' }}
+    runs-on: ubuntu-latest
+    timeout-minutes: 180
+    permissions:
+      contents: read
+    steps:
+      - uses: actions/checkout@v7
+
+      - uses: astral-sh/setup-uv@v7
+        with:
+          python-version: "3.12"
+
+      - name: Download freeze weights from the GitHub Release
+        if: ${{ github.event.inputs.mode == 'full' }}
+        env:
+          GH_TOKEN: ${{ github.token }}
+          TAG: ${{ github.event.inputs.weights_tag }}
+        run: |
+          set -euo pipefail
+          mkdir -p weights
+          gh release download "$TAG" --repo "${{ github.repository }}" --dir weights
+          ls -l weights
+
+      - name: Publish to Hugging Face
+        env:
+          HF_TOKEN: ${{ secrets.HF_TOKEN }}
+          MODE: ${{ github.event.inputs.mode }}
+          SHA: ${{ github.sha }}
+        run: |
+          set -euo pipefail
+          if [ -z "${HF_TOKEN:-}" ]; then
+            echo "HF_TOKEN secret is not set" >&2
+            exit 1
+          fi
+          extra=(--message "Photo-classify freeze (GitHub ${SHA:0:7})")
+          if [ "$MODE" = "card" ]; then
+            extra+=(--card-only)
+          else
+            extra+=(--src weights)
+          fi
+          uv run --no-project --with huggingface-hub python scripts/publish_photo_classify_hf.py "${extra[@]}"

.github/workflows/test.yml

@@ -5,6 +5,9 @@ on:
     branches: [main]
   pull_request:
 
+permissions:
+  contents: read
+
 concurrency:
   group: tests-${{ github.ref }}
   cancel-in-progress: true

.github/workflows/verify-release.yml

@@ -0,0 +1,247 @@
+name: Verify release surfaces
+
+# Post-release verification: after distribute.yml fans a release out to
+# Homebrew, the HF Space, and the ComfyUI Registry, confirm every published
+# surface actually landed and works. This workflow is the automated twin of
+# the manual checklist in docs/release-and-distribution.md ("Release
+# verification"), not a replacement for the library's own test suite (which
+# already ran in test.yml and publish.yml).
+
+on:
+  workflow_dispatch:
+    inputs:
+      version:
+        description: "Version to verify (no leading v). Blank = latest on PyPI."
+        required: false
+  workflow_run:
+    workflows: ["Distribute on release"]
+    types: [completed]
+
+# No step reads the GitHub token any more: the ComfyUI check moved to the
+# registry's public API. Keep the job read-only so it cannot write on a repo
+# whose default token permission is read/write.
+permissions:
+  contents: read
+
+jobs:
+  verify:
+    # Only run on a successful distribute (not on manual dispatch, where the
+    # version input or PyPI-latest provides the target).
+    if: ${{ github.event_name == 'workflow_dispatch' || github.event.workflow_run.conclusion == 'success' }}
+    runs-on: ubuntu-latest
+    timeout-minutes: 25
+    env:
+      # The Space id appears in the Hub API, the raw-file URL and the app host,
+      # spelled three different ways. Name it once so a move cannot half-land.
+      SPACE_REPO: wiltodelta/remove-ai-watermarks
+      SPACE_URL: https://wiltodelta-remove-ai-watermarks.hf.space
+
+    steps:
+      - name: Resolve target version
+        id: v
+        run: |
+          set -euo pipefail
+          if [ -n "${{ github.event.inputs.version }}" ]; then
+            v="${{ github.event.inputs.version }}"
+          else
+            v=$(curl -fsSL https://pypi.org/pypi/remove-ai-watermarks/json \
+              | python3 -c "import sys,json;print(json.load(sys.stdin)['info']['version'])")
+          fi
+          echo "version=$v" >> "$GITHUB_OUTPUT"
+          echo "Verifying release $v"
+
+      # -- PyPI ---------------------------------------------------------------
+      - name: Verify PyPI
+        env:
+          VERSION: ${{ steps.v.outputs.version }}
+        run: |
+          set -euo pipefail
+          echo "Checking PyPI for $VERSION..."
+          rel=$(curl -fsSL "https://pypi.org/pypi/remove-ai-watermarks/$VERSION/json")
+          echo "$rel" | python3 -c "
+          import json, sys
+          d = json.load(sys.stdin)
+          assert d['info']['version'] == '$VERSION', f\"PyPI version mismatch: {d['info']['version']}\"
+          assert d['urls'], 'No files on PyPI'
+          has_wheel = any(u['packagetype'] == 'bdist_wheel' for u in d['urls'])
+          has_sdist = any(u['packagetype'] == 'sdist' for u in d['urls'])
+          assert has_wheel, 'No wheel on PyPI'
+          assert has_sdist, 'No sdist on PyPI'
+          print(f'  PyPI: {len(d[\"urls\"])} files (wheel + sdist) for $VERSION')
+          "
+
+      # -- Clean install from PyPI ---------------------------------------------
+      - name: Install uv
+        run: curl -LsSf https://astral.sh/uv/install.sh | sh
+
+      - name: Verify clean install
+        env:
+          VERSION: ${{ steps.v.outputs.version }}
+        run: |
+          set -euo pipefail
+          echo "Installing remove-ai-watermarks==$VERSION in a clean environment..."
+          export PATH="$HOME/.local/bin:$PATH"
+          result=$(uvx --from "remove-ai-watermarks==$VERSION" remove-ai-watermarks --version 2>&1) \
+            || { echo "::error::Clean install failed: $result"; exit 1; }
+          echo "  Clean install: $result"
+
+      # -- Homebrew --------------------------------------------------------------
+      - name: Verify Homebrew formula
+        env:
+          VERSION: ${{ steps.v.outputs.version }}
+        run: |
+          set -euo pipefail
+          echo "Checking Homebrew tap formula..."
+          formula=$(curl -fsSL \
+            "https://raw.githubusercontent.com/wiltodelta/homebrew-tap/main/Formula/remove-ai-watermarks.rb")
+          echo "$formula" | grep -q "remove_ai_watermarks-$VERSION.tar.gz" \
+            || { echo "::error::Homebrew formula does not reference $VERSION"; \
+                 echo "Formula URL line:"; echo "$formula" | grep '^url'; exit 1; }
+          echo "  Homebrew: formula points to $VERSION"
+
+      # -- ComfyUI ------------------------------------------------------------------
+      - name: Verify ComfyUI registry node requires this release
+        env:
+          VERSION: ${{ steps.v.outputs.version }}
+        run: |
+          set -euo pipefail
+          echo "Checking the ComfyUI Registry node..."
+          # Read the published versions directly. Do NOT proxy through the sync
+          # workflow's run status: the node repo runs that workflow on a daily
+          # schedule too, so a green nightly says nothing about THIS release.
+          #
+          # And read the versions list, not `latest_version` on the node object.
+          # The registry reviews a new upload before activating it, and
+          # `latest_version` reports only the active one -- so for the whole
+          # review window a correctly published version looks identical to one
+          # that was never uploaded. Those are opposite situations: one is a
+          # queue nobody here controls, the other is a broken release.
+          versions=$(curl -fsSL "https://api.comfy.org/nodes/remove-ai-watermarks/versions")
+          status=$(printf '%s' "$versions" | VERSION="$VERSION" python3 -c "
+          import json, os, sys
+          version = os.environ['VERSION']
+          floor = f'>={version}'
+          matches = [
+              v for v in json.load(sys.stdin)
+              if any(floor in d for d in (v.get('dependencies') or []))
+          ]
+          if not matches:
+              sys.exit(f'::error::No ComfyUI node version requires {version}; the sync never published one')
+          # Sort rather than trusting the response order: the endpoint happens to
+          # return newest-first today and nothing documents that it must.
+          newest = max(matches, key=lambda v: v.get('createdAt') or '')
+          print(f\"{newest.get('version')} {newest.get('status')}\")
+          ")
+          node_version=${status%% *}
+          node_status=${status##* }
+          echo "  ComfyUI: node $node_version requires $VERSION (status $node_status)"
+          case "$node_status" in
+            NodeVersionStatusActive)
+              echo "- ComfyUI: registry node $node_version requires $VERSION and is live" >> "$GITHUB_STEP_SUMMARY"
+              ;;
+            NodeVersionStatusPending)
+              # Published and waiting on the registry's own review. Say exactly
+              # that in the summary rather than reporting it as live, and do not
+              # fail: an external moderation queue going red on every release
+              # trains everyone to ignore this workflow.
+              echo "::notice::ComfyUI node $node_version is published and awaiting registry review."
+              echo "- ComfyUI: registry node $node_version requires $VERSION, awaiting registry activation" >> "$GITHUB_STEP_SUMMARY"
+              ;;
+            *)
+              echo "::error::ComfyUI node $node_version is $node_status"
+              exit 1
+              ;;
+          esac
+
+      # -- HF Space -------------------------------------------------------------------
+      - name: Verify the HF Space serves this release
+        env:
+          VERSION: ${{ steps.v.outputs.version }}
+        run: |
+          set -euo pipefail
+          echo "Checking the HF Space pin..."
+          # The Space pin bump is a MANUAL step (see docs/release-and-distribution.md):
+          # distribute.yml only factory-rebuilds whatever is already pinned. Failing
+          # here is the point -- a demo left on an older release is an incomplete
+          # release, and only this check can say so.
+          reqs=$(curl -fsSL "https://huggingface.co/spaces/$SPACE_REPO/raw/main/requirements.txt")
+          pinned=$(printf '%s\n' "$reqs" | sed -n 's/^remove-ai-watermarks==\([0-9][0-9a-zA-Z.]*\).*/\1/p' | head -1)
+          if [ -z "$pinned" ]; then
+            echo "::error::Space requirements.txt has no remove-ai-watermarks== pin"
+            exit 1
+          fi
+          if [ "$pinned" != "$VERSION" ]; then
+            echo "::error::HF Space is pinned to $pinned, not $VERSION."
+            echo "  Bump remove-ai-watermarks in wiltodelta/raiw-hf-space (pyproject.toml,"
+            echo "  uv lock, re-exported requirements.txt) and push; sync-to-hf.yml mirrors it."
+            exit 1
+          fi
+          echo "  HF Space: requirements pin is $pinned"
+
+      - name: Verify the HF Space is running and answering
+        env:
+          VERSION: ${{ steps.v.outputs.version }}
+        run: |
+          set -euo pipefail
+          # A factory rebuild leaves the Space BUILDING for a while; wait for the
+          # runtime stage the API reports rather than for a bare HTTP 200, which a
+          # build page also returns.
+          for attempt in $(seq 1 20); do
+            stage=$(curl -fsSL "https://huggingface.co/api/spaces/$SPACE_REPO" \
+              | python3 -c "import json,sys;print((json.load(sys.stdin).get('runtime') or {}).get('stage',''))")
+            echo "  attempt $attempt: runtime stage=$stage"
+            [ "$stage" = "RUNNING" ] && break
+            case "$stage" in
+              BUILD_ERROR|RUNTIME_ERROR|CONFIG_ERROR)
+                echo "::error::HF Space runtime stage is $stage"; exit 1 ;;
+            esac
+            sleep 15
+          done
+          if [ "$stage" != "RUNNING" ]; then
+            echo "::error::HF Space never reached RUNNING (last stage: $stage)"
+            exit 1
+          fi
+
+          # Alive is not the same as working. Drive the two CPU surfaces the demo
+          # exists for, against the Space's own committed example, and require a
+          # real verdict rather than any HTTP 200.
+          export PATH="$HOME/.local/bin:$PATH"
+          curl -fsSL -o /tmp/example.png \
+            "https://huggingface.co/spaces/$SPACE_REPO/resolve/main/examples/doubao-aigc.png"
+          uv run --no-project --with 'gradio_client>=1,<2' python - <<'PYEOF'
+          import os
+          import sys
+
+          from gradio_client import Client, handle_file
+
+          # The committed example is a 5 MB PNG, and httpx's default 5 s write
+          # timeout aborts that upload on a slow link before the Space ever sees
+          # it -- which would read as a broken demo rather than a slow one.
+          client = Client(os.environ["SPACE_URL"], verbose=False, httpx_kwargs={"timeout": 300})
+
+          report = client.predict(path=handle_file("/tmp/example.png"), api_name="/run_identify")
+          if "Verdict:" not in report:
+              sys.exit(f"::error::/run_identify returned no verdict: {report[:200]!r}")
+          print(f"  HF Space identify: {report.splitlines()[0]}")
+
+          _image, _file, info = client.predict(
+              path=handle_file("/tmp/example.png"),
+              sensitivity_label="auto (recommended)",
+              api_name="/run_visible",
+          )
+          if "Removed:" not in info:
+              sys.exit(f"::error::/run_visible removed nothing on the Doubao example: {info!r}")
+          print(f"  HF Space visible: {info.splitlines()[0]}")
+          PYEOF
+          echo "- HF Space: pinned to $VERSION, RUNNING, identify + visible answered" >> "$GITHUB_STEP_SUMMARY"
+
+      - name: Summary
+        env:
+          VERSION: ${{ steps.v.outputs.version }}
+        run: |
+          # Every check above appends its own line to the step summary as it passes,
+          # and every one of them fails the job instead of warning. So this heading
+          # can only be reached when all of them actually held -- an unconditional
+          # "verified" block printed here once claimed surfaces nobody had checked.
+          sed -i "1i ## Release $VERSION verified" "$GITHUB_STEP_SUMMARY"
+          cat "$GITHUB_STEP_SUMMARY"

.gitignore

@@ -30,6 +30,10 @@ _refs/
 yolov8n.pt
 .coverage
 
+# Local prototype and evaluation outputs (scripts/chroma_scrub_prototype.py and
+# friends); the durable record of an oracle verdict lives under data/evaluations/
+out/
+
 # Claude Code local settings
 .claude/settings.local.json
 .claude/scheduled_tasks.lock

CLAUDE.md

@@ -31,6 +31,8 @@ Optional features and installation groups are documented in [`docs/installation.
 
 `maintain.sh` runs dependency freshness and security checks, Ruff, Pyright scoped to `src/`, and the parallel test suite. Full-project Pyright is not the project gate because the ML dependency graph can exhaust Node memory.
 
+This gate does NOT pass `--ignore-unfixed` to uv-secure, so a transitive CVE with no released fix stops it before Ruff, Pyright and the tests ever run. That is deliberate and it is not a blocker: run those three separately and report them, per the triage in [`docs/development.md`](docs/development.md). A red gate here is not the same signal as a red gate in a sibling repository that does ignore unfixed findings.
+
 Command, gate, typing, and model-test invariants auto-load from [`.claude/rules/development.md`](.claude/rules/development.md). Environment recovery, CI behavior, and fixture policy live in [`docs/development.md`](docs/development.md).
 
 Before a release, read [`docs/release-and-distribution.md`](docs/release-and-distribution.md). Treat the release as complete only after PyPI, Homebrew, the Hugging Face Space, and the ComfyUI Registry are verified; conda is not published. Keep the source-distribution public allowlist.
@@ -39,7 +41,7 @@ Before a release, read [`docs/release-and-distribution.md`](docs/release-and-dis
 
 [`docs/module-internals.md`](docs/module-internals.md) is the canonical per-module map, including design decisions, thresholds, calibration history, incident records, and regression guards. Read the relevant section before changing a subsystem.
 
-Research and current constraints are routed through [`docs/index.md`](docs/index.md), especially [`docs/known-limitations.md`](docs/known-limitations.md), [`docs/supported-signals.md`](docs/supported-signals.md), [`docs/synthid.md`](docs/synthid.md), and [`docs/watermarking-landscape.md`](docs/watermarking-landscape.md).
+Research and current constraints are routed through [`docs/index.md`](docs/index.md), especially [`docs/known-limitations.md`](docs/known-limitations.md), [`docs/supported-signals.md`](docs/supported-signals.md), [`docs/synthid.md`](docs/synthid.md), and [`docs/watermarking-landscape.md`](docs/watermarking-landscape.md). Pixel photo classification is [`docs/photo-classify.md`](docs/photo-classify.md); it is not `identify`. Classifier research is split between general [`AI-generated image classifiers`](docs/ai-generated-image-classifiers.md) and [`SynthID source classifiers`](docs/synthid-classifiers.md). Other SynthID campaign logs are [`docs/synthid-detector-research.md`](docs/synthid-detector-research.md) and [`docs/synthid-removal-research.md`](docs/synthid-removal-research.md). The pre-split chronological archive is [`docs/synthid-detector-removal-plan.md`](docs/synthid-detector-removal-plan.md).
 
 ## Data safety
 
@@ -51,4 +53,4 @@ Topic-specific rules live in `.claude/rules/*.md` and are auto-loaded when match
 
 | File | Covers |
 |---|---|
-| `development.md` | Command contracts, project gate, typing boundaries, model-adjacent tests, and the detection-path measurement rule |
+| `development.md` | Command contracts, project gate, typing boundaries, model-adjacent tests, the docs-coverage seam, and the detection-path measurement rule |

README.md

@@ -2,18 +2,19 @@
 
 Remove AI provenance marks from images and video you generated yourself:
 
-- known visible labels such as the Gemini sparkle and vendor text marks;
+- known visible labels such as the Google Gemini sparkle watermark and vendor text marks;
 - invisible pixel watermarks through diffusion regeneration;
 - C2PA, EXIF, XMP, IPTC, and related AI metadata.
 
 Video support covers provenance identification, complete visible-plus-metadata
-cleaning, directory batches, visible Sora, Veo, Seedance, Dola, Hailuo, and
-Kling mark removal, and oracle-certified VAE regeneration for video SynthID
+cleaning, directory batches, visible Sora, Veo, Seedance, Doubao, Dola,
+Hailuo AI, and Kling AI mark removal, and oracle-certified VAE regeneration for video SynthID
 removal.
 
 > [raiw.cc](https://raiw.cc) runs this library as a hosted service, with the GPU
-> included and nothing to install. Visible mark and metadata removal are free
-> there; invisible watermark removal is paid.
+> included and nothing to install. Visible mark and metadata removal at Standard
+> output up to 12 MP are free there; original resolution above 12 MP and invisible
+> watermark removal are paid.
 
 [![PyPI](https://img.shields.io/pypi/v/remove-ai-watermarks?logo=pypi&logoColor=white)](https://pypi.org/project/remove-ai-watermarks/)
 [![Python](https://img.shields.io/pypi/pyversions/remove-ai-watermarks?logo=python&logoColor=white)](https://pypi.org/project/remove-ai-watermarks/)
@@ -31,6 +32,8 @@ removal.
 | Goal | Command | GPU |
 | --- | --- | --- |
 | Find provenance signals and watermarks | `identify` | No |
+| Classify a photograph from pixels (opt-in, not provenance) | `classify` | No |
+| Verify supported OpenAI SynthID from pixels with the official remote API | `verify-openai-synthid` | No |
 | Remove known visible AI marks | `visible` | No |
 | Erase a region you select | `erase` | No |
 | Strip AI metadata | `metadata` | No |
@@ -44,11 +47,17 @@ removal.
 | Run visible, invisible, and metadata removal | `all` | Recommended |
 | Process a directory | `batch` | Depends on mode |
 
+Microsoft Paint and Photos InvisMark declarations are routed automatically to
+pixel regeneration. The `all` command removes both the hidden pixel watermark and
+its linked C2PA manifest; metadata stripping alone removes only the manifest.
+
 ## Installation modes
 
 | Need | Install |
 | --- | --- |
 | Metadata inspection and stripping | `remove-ai-watermarks` |
+| Photograph AI-versus-camera classification | `remove-ai-watermarks[classify]` |
+| Official remote OpenAI SynthID verification | `remove-ai-watermarks[verify]` |
 | Visible detection and removal | `remove-ai-watermarks[visible]` |
 | Visible video processing | `remove-ai-watermarks[video]` |
 | Video SynthID removal | `remove-ai-watermarks[video,diffusion]` |
@@ -75,6 +84,34 @@ Inspect an image:
 remove-ai-watermarks identify image.png
 ```
 
+To classify a photograph from pixels (AI versus camera, optional provider),
+install the extra and call `classify`. `identify` never starts it:
+
+```bash
+uv tool install --force "remove-ai-watermarks[classify]"
+remove-ai-watermarks classify image.png
+```
+
+Guide: [photo pixel classification](docs/photo-classify.md).
+
+Signed provenance is the supported route for SynthID and `identify` reads it.
+There is no local SynthID pixel detector in the package. Research on a
+periodic lattice expert is in `scripts/synthid_runtime/` and
+[synthid-detector-research.md](docs/synthid-detector-research.md).
+
+For supported OpenAI images, the optional official verifier provides a pixel
+watermark verdict:
+
+```bash
+uv tool install --force "remove-ai-watermarks[verify]"
+remove-ai-watermarks verify-openai-synthid image.png --acknowledge-upload
+```
+
+The command removes AI provenance metadata from a temporary copy, verifies that
+the decoded pixels are unchanged, uploads only that copy to OpenAI, and consumes
+only the independent SynthID response. It never runs implicitly from `identify`.
+An API key, endpoint access, and explicit upload acknowledgement are required.
+
 For visible watermark removal, install the pixel dependencies:
 
 ```bash
@@ -164,8 +201,8 @@ the specificity order shown below. Pass an explicit mark to restrict detection
 to one provider.
 Sora covers the moving Sora 2 mascot and wordmark. Veo covers both the current
 four-point diamond and the legacy `Veo` text. Seedance covers the fixed boxed
-`AI` label, Dola covers the fixed `Dola AI` text, Hailuo covers the composite
-`MINIMAX | hailuo AI` label, and Kling covers the bottom-right `KLING AI`
+`AI` label, Dola covers the fixed `Dola AI` text, Hailuo AI covers the composite
+`MINIMAX | hailuo AI` label, and Kling AI covers the bottom-right `KLING AI`
 label with its version suffix. A completed encode is published atomically. No
 output is written when no stable mark is found.
 HDR, PQ/HLG, and greater-than-8-bit inputs are rejected before encoding rather
@@ -187,7 +224,7 @@ remains useful for unusually important files or after provider changes, but it
 is not a product result state.
 
 For invisible watermark removal, install the `qwen-zimage` extra. **An NVIDIA GPU
-is required**: both profiles are CUDA-only, and there is no CPU or MPS fallback.
+is required**: all profiles are CUDA-only, and there is no CPU or MPS fallback.
 
 ```bash
 uv tool install --force "remove-ai-watermarks[qwen-zimage]"
@@ -226,12 +263,22 @@ features, and development setup.
 | --- | --- |
 | ![Image with a visible Gemini watermark](demo_banana_before.png) | ![Image after visible watermark removal](demo_banana_after.png) |
 
+The `after` raster is generated from the tracked `before` raster by the public path:
+
+```bash
+uv run remove-ai-watermarks visible demo_banana_before.png \
+  --backend cv2 -o demo_banana_after.png
+```
+
 ### High quality invisible removal
 
 `qwen-zimage` is the default profile: a Qwen-Image-2512 Lightning pass under Canny
 ControlNet, followed by SAM-masked Z-Image repair of any detected face. The
 alternative, `sdxl-zimage`, swaps the global stage for SDXL and keeps the same face
-stage. Both are CUDA only.
+stage. A third profile, `chroma-zimage`, uses the Apache-2.0 Chroma1 global pass
+with its own flat vendor floors; see `docs/chroma1-engine-research.md` for the
+calibration. `--pipeline auto` picks chroma-zimage for OpenAI and Microsoft
+provenance and qwen-zimage otherwise. All are CUDA only.
 
 ```bash
 uv tool install --force "remove-ai-watermarks[qwen-zimage]"
@@ -307,8 +354,10 @@ remove-ai-watermarks batch ./images --mode all
 
 Visible mark support includes:
 
-- Google Gemini and Nano Banana sparkle;
-- Doubao, Jimeng, Qwen, Kling, Yuanbao, Baidu, LibLibAI, and RunningHub labels;
+- Google Gemini and Nano Banana visible sparkle watermark;
+- Doubao, the Jimeng wordmark and top-left `AI生成` pill, Qwen, Kling AI,
+  Yuanbao, Baidu, LiblibAI, and RunningHub labels;
+- one calibrated Microsoft top-right white AI-badge variant;
 - one calibrated Samsung Galaxy AI label variant.
 
 Metadata and provenance inspection covers C2PA, EXIF, XMP, IPTC, common
@@ -317,7 +366,9 @@ signals. Optional decoders add support for open DWT-DCT watermarks and Adobe
 TrustMark.
 
 The exact support matrix, including important locale and detector limits, lives
-in [supported signals](docs/supported-signals.md).
+in [supported signals](docs/supported-signals.md). The
+[synthetic example gallery](data/fixtures/visible/README.md) carries one canonical
+sample for every registered image and video mark.
 
 ## How it works
 
@@ -350,6 +401,9 @@ import remove_ai_watermarks as raiw
 result, removed = raiw.remove_visible("watermarked.png", "clean.png")
 print(removed)
 
+openai_synthid = raiw.verify_openai_synthid("image.png", acknowledge_upload=True)
+print(openai_synthid.status)
+
 provenance = raiw.identify_video("input.mp4")
 report = raiw.inspect_video_metadata("input.mp4")
 complete = raiw.remove_video_all("input.mp4", "clean.mp4")
@@ -392,7 +446,7 @@ invisible removal.
   detail.
 - Visible video removal recognizes the moving Sora 2 wordmark, the current Veo
   diamond plus legacy `Veo` text, the Seedance boxed `AI` label, and the fixed
-  Dola, Hailuo, and Kling labels. It does not recognize the older Sora Turbo
+  Doubao, Dola, Hailuo AI, and Kling AI labels. It does not recognize the older Sora Turbo
   corner swirl or unregistered layouts from those providers.
   The classical OpenCV backend can smear structured backgrounds; use MI-GAN or
   LaMa when recovery quality matters.
@@ -400,7 +454,7 @@ invisible removal.
   The shipped profile is oracle-certified, but no public local decoder can
   certify an arbitrary output at runtime. Recheck unusually important outputs
   after provider changes.
-- Invisible-watermark removal requires CUDA. Both profiles refuse any other
+- Invisible-watermark removal requires CUDA. All profiles refuse any other
   device at construction rather than falling back to one that cannot run them.
   Visible removal, metadata stripping and `identify` still run anywhere.
 - Provider watermark systems can change. Validate important outputs with the
@@ -432,8 +486,11 @@ reinterpret the pixel result returned `UNAVAILABLE`; that follow-up was not a
 verifier rerun and does not invalidate the built-in verdicts. A 2026-07-31
 full-clip check on a public eight-second Veo sample found `0.10` still detected
 and `0.15` not detected, so `0.15` is now the certified default. The
-reproducible hashes and verdicts live in
-`data/evaluations/video-synthid-oracle.csv`.
+reproducible hashes and verdicts for that full-clip check -- one carrier, two
+rows -- live in `data/evaluations/video-synthid-oracle.csv`. The earlier
+two-clip calibration is narrative only: its verdicts were not recorded in a
+tracked manifest, so treat the certified default as resting on the 2026-07-31
+rows.
 
 ## Documentation
 

data/README.md

@@ -7,6 +7,8 @@ data/
   fixtures/
     provenance/   Real format and provenance fixtures used by tests
                   (source records live in fixtures/README.md)
+    visible/      Synthetic per-mark example gallery (one committed example per
+                  registered visible mark; see fixtures/visible/README.md)
   calibration/
     <vendor>/     Minimal controlled inputs needed to rebuild detector assets
   synthid/
@@ -15,6 +17,8 @@ data/
     full-pipeline-quality.csv
                   Reusable full-pipeline evaluation selection
   evaluations/
+    engine-selection/
+                  Prompt-matched AI content matrix for deterministic auto-engine research
     fidelity/     Evaluation instructions and hand-verified ground truth
     video-synthid-oracle.csv
                   Reproducible full-clip Gemini SynthID verdicts
@@ -22,6 +26,12 @@ data/
 
 ## Storage rules
 
+Large local-only research data (the 211 GB Spaces corpus and the frozen
+checkpoints, research corpora, and campaign reports) lives under gitignored
+paths documented in `data/research/README.md` (ignored via `.git/info/exclude`,
+never committed). Worktree `.local-eval/` directories are scratch copies; the
+durable store is `data/research/` in the main checkout.
+
 1. Store each binary image once. Evaluation manifests and documentation point
    to its canonical location.
 2. Put executable test fixtures in `fixtures/`.
@@ -32,6 +42,9 @@ data/
    commands, hashes, and oracle verdicts instead of committing another corpus
    copy. A small curated before-and-after example may live in `docs/images/`
    when it is part of the public documentation.
+   `evaluations/engine-selection/` is the bounded exception for ORIGINAL study
+   inputs: its manifest tracks a prompt-matched OpenAI/Meta content matrix, not
+   generated model outputs or watermark-oracle evidence.
 6. Keep third-party fixture license notices in `licenses/`, outside directories
    that tests enumerate as media inputs.
 7. Runtime detector assets belong in `src/remove_ai_watermarks/assets/`.
@@ -48,16 +61,17 @@ runtime assets.
 video removal profile works, so it is also the source of truth for three shipped
 defaults: `tests/test_video_invisible.py` asserts that `noise_std`, `long_side`,
 and `fps` together match a row this manifest records as certified. Changing one
-of those three without adding the row that certifies it fails the suite. `vae` is
-deliberately outside that check because neither tracked row records one; add it
-to the assertion in the same commit as the first row that does.
+of those three without adding the row that certifies it fails the suite. Both
+historical rows mark `vae` as `unrecorded`: the repository must not infer a model
+identity from the current default. Add it to the assertion in the same commit as
+the first oracle row that records and verifies one.
 
 | Column | Meaning |
 | --- | --- |
 | `date`, `source_url`, `source_sha256` | Identify the carrier. |
 | `source_width`, `source_height`, `source_fps` | Carrier geometry. Without it the actual downscale factor of a row cannot be recovered later. |
 | `duration_seconds`, `source_verdict` | Clip length submitted and the verifier's reading of the untouched carrier. |
-| `vae`, `noise_std`, `long_side`, `fps`, `seed` | The full run configuration. |
+| `vae`, `noise_std`, `long_side`, `fps`, `seed` | The run configuration. `unrecorded` means the historical run did not preserve the VAE identity. |
 | `output_sha256` | Identifies the exact submitted file. |
 | `output_verdict` | One of `detected`, `not_detected`, `indeterminate`, `refused`. |
 | `output_verdict_text` | The verifier's wording, verbatim. |

data/contentseal/README.md

@@ -0,0 +1,101 @@
+# Content Seal oracle corpus
+
+Muse Image (`muse-image-1.0`) generations with externally verified Content Seal
+verdicts, produced through the Meta Model API on 2026-08-26 and checked against
+the public detector at `https://meta.ai/identification` (anonymous session, no
+login). Follows the `data/synthid/originals` pattern: binaries live in
+`originals/`, every derived variant is recorded in `manifest.csv` as a recipe
+plus hash and is not stored.
+
+## What this corpus establishes
+
+- The Meta Model API image endpoint (`POST /v1/images/generations`) stamps the
+  same Content Seal pixel watermark as the consumer Meta AI app: all five
+  generations verified positive with attribution "Muse Image 1 - Meta".
+- The detector response carries a per-generation ID and creation timestamp
+  embedded in the watermark payload. Both survived a 512 px LANCZOS resize and
+  a full-size JPEG q85 re-encode (same ID returned), so the payload is more
+  robust than the detection threshold.
+- Three checked center crops lost the seal: 50% and 33% linear crops of the fox
+  and the 50% crop of the text poster returned "No AI signatures from Meta were
+  found". The text poster's 33% crop was not checked because the daily oracle
+  limit was reached, so its empty verdict is not evidence either way. The checked
+  results are consistent with the Reuters 2026-07-11 analysis (55% missed after
+  cropping).
+- API outputs carry XMP `iptcExt:DigitalSourceType =
+  trainedAlgorithmicMedia`, so local `identify` flags them via the existing
+  Made-with-AI path. Metadata-stripping transforms fall back to unknown, and
+  Content Seal has no local decoder in this project: the oracle is the only
+  reader.
+- Drift finding: the 512 px resize of `gen_fox_forest` triggers a
+  medium-confidence false positive "Tencent Yuanbao (visible 元宝 / AI生成
+  mark)" in this project's `identify`. Recorded here as a reproducible case.
+
+## Oracle limits and wire format
+
+There is no public or documented checking API. Verified against the official
+developer documentation on 2026-08-26 (`https://dev.meta.ai/docs/`): the full
+Meta Model API reference lists only Responses, Chat Completions, Messages,
+Files, Images (`/v1/images/generations`, `/v1/images/edits`), and Models, with
+no identification, detection, or watermark endpoint, and the image-generation,
+Muse Image cookbook, and pricing pages never mention watermark, Content Seal,
+or provenance at all. The API applies the seal (every generation in this corpus
+carries it) while documenting nothing about it. The web tool drives an internal
+REST pair, captured from the browser network log on 2026-08-26:
+
+1. `POST https://rupload.meta.ai/gen_ai_document_gen_ai_tenant/<uuid>` with the
+   raw file bytes, `x-entity-type`, `x-entity-length`, `ai_detector_upload: true`,
+   and an anonymous `authorization: OAuth ecto1:<token>` session token minted by
+   the page.
+2. `POST https://meta.ai/api/ai-detector` with `Bearer ecto1:<token>` and body
+   `{"media_id": "...", "fileName": "...", "mimeType": "..."}`.
+
+The rate limit is enforced at that endpoint, server-side, and keyed beyond the
+browser session: the API itself returns `429 {"errorType": "rate_limited"}`,
+and clearing cookies and storage changed nothing, so driving the internal pair
+directly does not bypass it. The Meta Model API (`api.meta.ai/v1`, where the
+generation key works) has no identification endpoint; plausible paths all
+return 404. Rows with an empty `oracle_verdict` were transformed but not yet
+checkable. Read a verdict only from the settled page text after the
+result-complete state ("Upload another file"): a wait for a verdict string can
+match the previous upload's text, and the fresh-navigation protocol used for
+the calibration rows below is the race-free variant.
+
+## Strength floor calibration (qwen-zimage, seed 0)
+
+The library resolves strength per vendor with measured floors (OpenAI
+0.07675 / Google 0.27 / Microsoft InvisMark 0.15 in
+`_internal/watermark_profiles.py`). Meta Content Seal had no floor before this
+calibration; these rows measure one by the same methodology: independent
+generations, each one's first-clean boundary, floor = worst boundary plus the
+observed cross-source spread.
+
+Measured (2026-08-26/27, oracle `meta.ai/identification`):
+
+- Default pipeline clears Content Seal: tested samples came back clean at the
+  default resolution-adaptive strength (~0.1305 at 2.56 MP), including the
+  worst source.
+- Five independent generations bracketed. First-clean boundaries:
+  lighthouse (0.0525, 0.06], fox (0.03, 0.0375], night_city (0.03, 0.0375],
+  mug <= 0.03, text <= 0.015. Cross-source spread is wide (a factor of four
+  between easiest and hardest).
+- Derived Meta floor by the existing worst-boundary-plus-cross-source-spread
+  method: 0.06 + (0.0525 - 0.015) = 0.0975, rounded to **0.1**.
+- Shipped as `QWEN_ZIMAGE_META_STRENGTH`: auto mode routes standalone-AI-IPTC
+  files onto the cohort, and `--vendor meta` / `InvisibleOptions.vendor`
+  names it explicitly on stripped files (implying the scrub runs).
+## Regeneration
+
+The eight deterministic crop, resize, and JPEG variants can be reproduced and
+hash-checked from the tracked originals:
+
+```bash
+uv run python scripts/contentseal_transforms.py /tmp/contentseal-derived
+```
+
+The Meta API generations and remote GPU outputs are not reproducible from this
+repository alone. Their prompts, exact output hashes, model/profile settings,
+and oracle results are recorded in `manifest.csv`, but the generation API is
+stochastic and the private worker environment is not tracked. `MUSE_API_KEY` and
+the anonymous detector session are deliberately absent. A new calibration must
+therefore create new manifest rows rather than claiming to recreate these bytes.

data/contentseal/manifest.csv

@@ -0,0 +1,44 @@
+name,file,origin,source_url,prompt,requested_size,delivered_size,sha256,xmp_iptc_trainedAlgorithmicMedia,oracle_verdict,oracle_attribution,oracle_generation_id,oracle_created_utc,checked_at_utc,notes
+gen_fox_forest,originals/gen_fox_forest.webp,meta-model-api,,A red fox resting on a mossy log in a misty forest at dawn photorealistic shallow depth of field,1024x1024,1600x1600,6d7cecf322a5ac4b2547e2f32c767b3cb3e8a0e49f274cfd00aa31be6697eed4,yes,detected,Muse Image 1 - Meta,AXZpZGVvc2VhbHY0X2NhX3NjbLlNjYhvPAxD,2026-08-26T19:07Z,2026-08-26T19:11Z,checked twice; ID stable across uploads
+gen_text_poster,originals/gen_text_poster.webp,meta-model-api,,A cheerful flat-design poster that says 'WATERMARK FIELD DAY 2026' in bold rounded letters over a coral and cream striped background,1024x1024,1600x1600,873927662d8198e9c38b4ae71a2919ba5d417dfcd714649db1b0ae231e8cbf9b,yes,detected,Muse Image 1 - Meta,AXZpZGVvc2VhbHY0X2NhX3NjbJuIKXPAYxsd,2026-08-26T19:08Z,2026-08-26T19:08Z,
+gen_lighthouse_watercolor,originals/gen_lighthouse_watercolor.webp,meta-model-api,,A watercolor illustration of a lighthouse on a cliff at golden hour seagulls in the distance soft loose washes white paper texture,1024x1024,1600x1600,69bee7c376608568361085602c5c7406900885849bd94c5279c3924cf793b27c,yes,detected,Muse Image 1 - Meta,AXZpZGVvc2VhbHY0X2NhX3NjbB5uWbAmWmwp,2026-08-26T19:08Z,2026-08-26T19:08Z,
+gen_night_city,originals/gen_night_city.webp,meta-model-api,,A night city skyline in the rain neon reflections on wet asphalt cinematic wide shot moody,1536x1024,1920x1280,345adf6b9f777b15ef7ce7bbdfb3b355a1d9e882740809e966e9f6caafd94d48,yes,detected,Muse Image 1 - Meta,AXZpZGVvc2VhbHY0X2NhX3NjbH5uWbAmWmwp,2026-08-26T19:08Z,2026-08-26T19:08Z,
+gen_studio_mug,originals/gen_studio_mug.webp,meta-model-api,,A minimalist studio photo of a single matte ceramic mug on a pastel blue background soft shadow clean commercial look,1024x1024,1600x1600,2b7bc7fd56fa2250c66ef74f8b3e49d9666fe147d894d5baf9461b5e36077a07,yes,detected,Muse Image 1 - Meta,AXZpZGVvc2VhbHY0X2NhX3NjbAsSozV2XCzw,2026-08-26T19:08Z,2026-08-26T19:08Z,
+fox_crop50,,derived:gen_fox_forest,,center crop 0.5 linear each side then WEBP q95,,800x800,80b91995560a7c4b08596a26b3401a29afb82691fad193502697a49785eab7be,no_stripped_by_reencode,not_detected,,,,2026-08-26T19:13Z,seal lost; PIL re-encode strips XMP
+fox_crop33,,derived:gen_fox_forest,,center crop 0.33 linear each side then WEBP q95,,528x528,3b3aded8f4fcb98d0599431abccb73b9581854ae34c6bc869724cd5c86a1e35e,no_stripped_by_reencode,not_detected,,,,2026-08-26T19:13Z,seal lost
+fox_res512,,derived:gen_fox_forest,,resize long side 512 LANCZOS then WEBP q95,,512x512,19b85f615d56f5e9f55cd97bae0ee343f4f432e6bfa0a6fc7acb07dec2cc1d81,no_stripped_by_reencode,detected,Muse Image 1 - Meta,AXZpZGVvc2VhbHY0X2NhX3NjbLlNjYhvPAxD,2026-08-26T19:07Z,2026-08-26T19:13Z,generation ID and creation time identical to the original generation: watermark payload survives the resize
+fox_jpeg85,,derived:gen_fox_forest,,full-size JPEG q85 re-encode,,1600x1600,3bc7dc11bf3c16c83814df1e6485cdb6e49e21141511dda56d210cc920a8c5e3,no_stripped_by_reencode,detected,Muse Image 1 - Meta,AXZpZGVvc2VhbHY0X2NhX3NjbLlNjYhvPAxD,2026-08-26T19:07Z,2026-08-26T19:13Z,payload survives JPEG recompression; local identify returns unknown (metadata stripped)
+text_crop50,,derived:gen_text_poster,,center crop 0.5 linear each side then WEBP q95,,800x800,3f0d4075012ee4fec820209c5c1c32bb739998813325f49b1124f379162f9837,no_stripped_by_reencode,not_detected,,,,2026-08-26T19:13Z,seal lost
+text_crop33,,derived:gen_text_poster,,center crop 0.33 linear each side then WEBP q95,,528x528,95cef87002961831b21f6f47cd9a0824a67e2ee6f8503356fd5db6a3fcfcc998,no_stripped_by_reencode,,,,,,daily oracle limit reached before this row could be checked
+text_res512,,derived:gen_text_poster,,resize long side 512 LANCZOS then WEBP q95,,512x512,b319727d02e908f22e59f148050e6b4686cbd1a622bd69db51fe4072a6f66b34,no_stripped_by_reencode,,,,,,daily oracle limit reached; also the fox twin of this transform triggered the Yuanbao false positive below
+text_jpeg85,,derived:gen_text_poster,,full-size JPEG q85 re-encode,,1600x1600,76f00fcde1e974549afa5d90e1879c705e3c3631ef1f35cab901fc912cd15fa4,no_stripped_by_reencode,,,,,,daily oracle limit reached before this row could be checked
+blog_qr_manhwa,,meta-blog-cdn,https://lookaside.fbsbx.com/elementpath/media/?media_id=1807972953501959&version=1783318590&transcode_extension=webp,,,1920x1280,8ee7700dff59f21d7de393a619664a0b9360f148d18df289364ecea939b3dea9,yes,detected,Muse Image 1 - Meta,,,2026-08-26T18:59Z,not stored; re-downloadable from source_url
+blog_fractal_poster,,meta-blog-cdn,https://lookaside.fbsbx.com/elementpath/media/?media_id=1499727434782014&version=1783727678&transcode_extension=webp,,,2096x992,2a96168db026444b47ac37807fd99a88c8b7fa6866e1c93a54ab427fbe581f76,no,detected,Muse Image 1 - Meta,,,2026-08-26T18:59Z,seal survived CDN transcode without any metadata
+blog_flipbook_punch,,meta-blog-cdn,https://lookaside.fbsbx.com/elementpath/media/?media_id=2521328538303639&version=1783396590&transcode_extension=webp,,,1920x1280,35f28dc2cbdf44aed190bc8efaa0fe7bfa288a2196638712dd83bc941cc294d5,yes,detected,Muse Image 1 - Meta,,,2026-08-26T19:00Z,
+blog_teen_cat,,meta-blog-cdn,https://lookaside.fbsbx.com/elementpath/media/?media_id=1325391919706734&version=1783319609&transcode_extension=webp,,,1600x1600,c2e7df000ffa6520589d8efc5f0bcbeb759175cdaa0c827189c28a64f75d3dd7,yes,detected,Muse Image 1 - Meta,,,2026-08-26T19:00Z,
+blog_hero_1,,meta-blog-cdn,https://lookaside.fbsbx.com/elementpath/media/?media_id=2140990336800598&version=1783727678,,,1344x1792,7655639acb9f826cdb864d869530153efc1e1467ff414b5a63e80aa7b39b2fb7,no,detected,Muse Image 1 - Meta,,,2026-08-26T19:00Z,seal survived CDN transcode without any metadata
+control_synth_gradient,,synthetic-local,,PIL gradient with rectangle JPEG q90; never touched any AI pipeline,,1024x768,25f29c0b993ed1a8e41060ed50de778d875a6d94847ced180aafc5a6ad429f82,no,not_detected,,,,2026-08-26T19:01Z,negative control: No AI signatures from Meta were found
+fox_nometa,,derived:gen_fox_forest,,metadata --remove only (no pixel change),,1600x1600,685d3a5c5d74e653ec7615fc7a347a0584c277fc7fb59594d388ac619ffe3985,no_stripped,detected,Muse Image 1 - Meta,AXZpZGVvc2VhbHY0X2NhX3NjbLlNjYhvPAxD,2026-08-26T19:07Z,2026-08-26T22:19Z,metadata stripping does NOT remove Content Seal; seal lives in pixels; same generation ID as original
+fox_modal_invisible,,derived:gen_fox_forest,,modal raiw-worker qwen-zimage mode=invisible seed=0 strength=default-adaptive(approx 0.1305 at 1600x1600),,1600x1600,6daa3e9b5dde5cb443d8071c5294262742f001c02b694243764a50345769d8b8,no_stripped,not_detected,,,,2026-08-26T22:21Z,current default pipeline clears Content Seal
+text_modal_invisible,,derived:gen_text_poster,,modal raiw-worker qwen-zimage mode=invisible seed=0 strength=default-adaptive(approx 0.1305 at 1600x1600),,1600x1600,8530a82fb856b0a00651076ac1ad8a7544b5d8873cac9bd5780704fbe10f53f8,no_stripped,not_detected,,,,2026-08-26T22:22Z,current default pipeline clears Content Seal
+fox_str0.06000,,derived:gen_fox_forest,,modal raiw-worker qwen-zimage mode=invisible seed=0 strength=0.06,,1600x1600,7b5e5ae75ca20f2a3cdfcfa7666104752d9557b08ac236db6f1548434940a1f3,no_stripped,not_detected,,,,2026-08-26T22:28Z,strength calibration ladder
+fox_str0.04500,,derived:gen_fox_forest,,modal raiw-worker qwen-zimage mode=invisible seed=0 strength=0.045,,1600x1600,26da15694b3096e2f1717154db213e814cdd27f2fc40e5f924db2324213cf960,no_stripped,not_detected,,,,2026-08-27T02:28Z,strength calibration ladder; re-confirmed clean at 0.045
+fox_str0.03750,,derived:gen_fox_forest,,modal raiw-worker qwen-zimage mode=invisible seed=0 strength=0.0375,,1600x1600,b7eb0616d10042933edf22cfc30aff4df915384828289b409f6cfa4cdf2807d4,no_stripped,not_detected,,,,2026-08-26T22:30Z,fresh-page protocol; fox first-clean boundary is in (0.03 0.0375]
+fox_str0.03000,,derived:gen_fox_forest,,modal raiw-worker qwen-zimage mode=invisible seed=0 strength=0.03,,1600x1600,cff80d18d9d00000f47e0f97c419a37c13a13831795768aee8727aa9516d1401,no_stripped,detected,Muse Image 1 - Meta,,,2026-08-26T22:31Z,fresh-page protocol; seal survives 0.03
+fox_str0.02000,,derived:gen_fox_forest,,modal raiw-worker qwen-zimage mode=invisible seed=0 strength=0.02,,1600x1600,b19183ec60b63a5b73d3e1c723e7943584912857d51a4b5f85259c5c77da0e53,no_stripped,detected,Muse Image 1 - Meta,,,2026-08-26T22:28Z,settled-read protocol; monotonic below the 0.03 boundary
+text_str0.03750,,derived:gen_text_poster,,modal raiw-worker qwen-zimage mode=invisible seed=0 strength=0.0375,,1600x1600,bacfd4eca7b13616502f74497cbe4f02ef6893918870f13f9e76fdb93b43107f,no_stripped,not_detected,,,,2026-08-26T22:33Z,fresh-page protocol
+text_str0.03000,,derived:gen_text_poster,,modal raiw-worker qwen-zimage mode=invisible seed=0 strength=0.03,,1600x1600,d5c6cffbf471ef8bb74ee8c0d22cc17d9da2c446b83e46c4be67e6ea4cdd09de,no_stripped,not_detected,,,,2026-08-26T22:33Z,fresh-page protocol; text first-clean boundary is at or below 0.03 - cross-source spread vs fox confirmed
+lh_str0.03750,,derived:gen_lighthouse_watercolor,,modal raiw-worker qwen-zimage mode=invisible seed=0 strength=0.0375,,1600x1600,f5169debc5fd2792399c0ea3fa88cb1d05f523d95004bec240c73db0e9aaee51,no_stripped,detected,Muse Image 1 - Meta,,,2026-08-27T02:28Z,seal survives 0.0375 where fox is already clean
+lh_str0.03000,,derived:gen_lighthouse_watercolor,,modal raiw-worker qwen-zimage mode=invisible seed=0 strength=0.03,,1600x1600,110d2112d91dd53df5ccd1839e0e2b41c44aa1832adb0090032660e071fb1fd4,no_stripped,detected,Muse Image 1 - Meta,,,2026-08-27T02:28Z,fresh-page protocol; lighthouse holds its seal below the fox boundary: cross-source spread is wide
+text_str0.02500,,derived:gen_text_poster,,modal raiw-worker qwen-zimage mode=invisible seed=0 strength=0.025,,1600x1600,f46a6c53b4f3d39fccb1d62cca82ced2e163e4424d13c98e6468a8e083c0fa54,no_stripped,not_detected,,,,2026-08-27T02:28Z,mid rung inside the clean zone
+text_str0.02000,,derived:gen_text_poster,,modal raiw-worker qwen-zimage mode=invisible seed=0 strength=0.02,,1600x1600,a19cbe22313e0f19768c98567ea89f2d9dc30827691fc7ec2971c52f3e7c6cc6,no_stripped,not_detected,,,,2026-08-27T02:28Z,text clean at 0.02: boundary <= 0.02 - the easiest source measured
+text_str0.01500,,derived:gen_text_poster,,modal raiw-worker qwen-zimage mode=invisible seed=0 strength=0.015,,1600x1600,aa3816c75e38f3ab5afc378d349caafad56f2bb6da859a5ee68fdea57ad00d73,no_stripped,not_detected,,,,2026-08-27T02:41Z,text clean at 0.015: boundary <= 0.015 - the easiest source measured
+lh_str0.02500,,derived:gen_lighthouse_watercolor,,modal raiw-worker qwen-zimage mode=invisible seed=0 strength=0.025,,1600x1600,989c4a7a804bc8420ec4d86b9445bc3a37382c1834782a7f8842f781d69b05e2,no_stripped,,,,,,below the measured detected boundary (0.03) for this source; not individually checked
+lh_str0.02000,,derived:gen_lighthouse_watercolor,,modal raiw-worker qwen-zimage mode=invisible seed=0 strength=0.02,,1600x1600,6a4a4ec94292a145e7d73e6900b8ec6d0eede17137f2b91fba7757ec0bdba5ec,no_stripped,,,,,,below the measured detected boundary (0.03) for this source; not individually checked
+nc_str0.03750,,derived:gen_night_city,,modal raiw-worker qwen-zimage mode=invisible seed=0 strength=0.0375,,1920x1280,46f322335f801ee54427eb39275216465f9a7cfa3d918c698e4d90a2439a0815,no_stripped,not_detected,,,,2026-08-27T02:28Z,boundary (0.03; 0.0375]
+nc_str0.03000,,derived:gen_night_city,,modal raiw-worker qwen-zimage mode=invisible seed=0 strength=0.03,,1920x1280,3f42632319248ad1a91ef2457c7e0b13ed17e1d2569decbbaab67c2072e9a305,no_stripped,detected,Muse Image 1 - Meta,,,2026-08-27T02:28Z,night_city holds seal at 0.03
+mug_str0.03750,,derived:gen_studio_mug,,modal raiw-worker qwen-zimage mode=invisible seed=0 strength=0.0375,,1600x1600,3b6109ae7e86b8ea74ce33315e3f2a7eda1cadb724d429f0951f13c3ead34b0f,no_stripped,not_detected,,,,2026-08-27T02:28Z,upper rung for the mug bracket
+mug_str0.03000,,derived:gen_studio_mug,,modal raiw-worker qwen-zimage mode=invisible seed=0 strength=0.03,,1600x1600,1c24c984677e1528da83003ac40594f6e5ef1fa9351f1368b6d31a0101308583,no_stripped,not_detected,,,,2026-08-27T02:28Z,mug clean at 0.03: boundary <= 0.03
+lh_str0.05250,,derived:gen_lighthouse_watercolor,,modal raiw-worker qwen-zimage mode=invisible seed=0 strength=0.0525,,1600x1600,8912ba1ff4a26790f69224c49dd649e46835e277c375276ac9604f5339775b2a,no_stripped,detected,Muse Image 1 - Meta,,,2026-08-27T02:41Z,bisection: lighthouse first-clean boundary bracketed to (0.0525; 0.06]
+lh_str0.04500,,derived:gen_lighthouse_watercolor,,modal raiw-worker qwen-zimage mode=invisible seed=0 strength=0.045,,1600x1600,cfdcf7bbb27c740846a1de4edffee3b25a624c2a8e1aba2362feaa25b682e3ae,no_stripped,detected,Muse Image 1 - Meta,,,2026-08-27T02:28Z,seal survives 0.045: lighthouse is the worst source measured
+lh_str0.06000,,derived:gen_lighthouse_watercolor,,modal raiw-worker qwen-zimage mode=invisible seed=0 strength=0.06,,1600x1600,4e214be00a89dc9f1f32ec39483c5e9668a1ec7f38b15e5794942479c839fcca,no_stripped,not_detected,,,,2026-08-27T02:28Z,lighthouse first-clean boundary bracketed to (0.045 0.06]

data/evaluations/engine-selection/README.md

@@ -0,0 +1,61 @@
+# Engine-selection fixture set
+
+This directory is the tracked, content-balanced input set for researching a
+deterministic `auto` engine choice. It is not a training corpus and it is not a
+watermark-oracle corpus.
+
+## Content matrix
+
+`content-manifest.csv` contains 19 prompt-matched pairs. Each pair uses the
+same prompt and generation index across OpenAI `gpt-image-1-mini` and Meta
+`muse-image-1.0`, covering the content classes that materially stress image
+regeneration:
+
+- natural and urban scenes;
+- single-person portraits and people in context;
+- animals, food, products, interiors, architecture, macro detail, and action;
+- flat, isometric, watercolor, and surreal illustration styles.
+
+The files are exact copies of generation outputs collected for the
+`docs/arxiv-paper-review` research branch. The manifest records the SHA-256 of
+the committed bytes. The old OpenAI collection manifest stored the API payload
+hash under `sha256`; `source_payload_sha256` preserves that value while
+`sha256` always means the actual file bytes here. Meta's two hashes are the
+same.
+
+One generation per prompt and provider is enough for the first paired
+discovery pass. Any policy inferred from it must be challenged against unused
+generation indices from the local research archive before shipping. Generated
+outputs belong outside this directory.
+
+`carrier-manifest.csv` adds the canonical, already tracked signal carriers to
+the study without copying their bytes. Together the two manifests cover
+ordinary content, text, single faces, face grids, and mixed face/text scenes.
+
+## Signal carriers
+
+The content matrix was re-encoded by its collection pipeline and has no local
+provenance signal. It must not be used to set or certify watermark-removal
+strengths. The tracked oracle/carrier inputs remain in their canonical homes:
+
+- OpenAI and Google SynthID: `data/synthid/originals/` with
+  `data/synthid/manifest.csv`;
+- Meta Content Seal: `data/contentseal/originals/` with
+  `data/contentseal/manifest.csv`.
+
+There is no tracked, publication-cleared Microsoft InvisMark carrier yet. The
+three Paint sources used by the earlier calibration are user uploads and remain
+outside git. A Microsoft row may be added only from a newly generated or
+otherwise publication-cleared source, with a pixel-identical metadata-stripped
+control that remains positive in Microsoft's detector.
+
+## Integrity check
+
+Run:
+
+```bash
+uv run python scripts/verify_engine_selection_fixtures.py
+```
+
+The check validates paths, byte hashes, dimensions, prompt pairing, and the
+declared provider/content matrix without loading any ML model.

data/evaluations/engine-selection/carrier-manifest.csv

@@ -0,0 +1,13 @@
+provider,file,content_stratum,signal,verified_via,sha256,verified_text_geometry,verified_text_ground_truth
+openai,"../../synthid/originals/ChatGPT Image May 30, 2026, 10_31_08 AM.png",face_grid,OpenAI SynthID,openai-verify,28ff8732b037f98a4ef5bc277bbcdaa32e5eb9ccbd00b6c8c616e46ef68ae8a0,no,no
+openai,"../../synthid/originals/ChatGPT Image May 31, 2026, 02_02_23 PM.png",multilingual_typography,OpenAI SynthID,c2pa-metadata,228e54413a3ef62b313176dcdba774a56a58c36b54227d1440bc26cbe0aefd82,yes,yes
+openai,"../../synthid/originals/ChatGPT Image May 31, 2026, 02_03_55 PM.png",multilingual_typography,OpenAI SynthID,openai-verify,05b836ecfe40fd689177fda74384ae4fdcc446505bbc4281cd3cbb6523eb669e,yes,yes
+google,../../synthid/originals/Gemini_Generated_Image_633uuy633uuy633u.png,cjk_typography_scene,Google SynthID,gemini-app,4affd7f27767a445db6abf741355743ba8d95108ad922c9fff045feed8492236,yes,yes
+google,../../synthid/originals/Gemini_Generated_Image_akdbeiakdbeiakdb.png,cyrillic_typography_scene,Google SynthID,gemini-app,8c1a6fb03ef3d45a1f958fb3401e4264e409ff88c2a793061db7f29023454d0e,no,no
+google,../../synthid/originals/Gemini_Generated_Image_y48j3cy48j3cy48j.png,crowd_faces,Google SynthID,gemini-app,45d79a683134fcba1b147b2aedb669783d474e1fb8a4df329729a0904fd1b46b,no,no
+google,../../synthid/originals/Gemini_Generated_Image_3mc4t93mc4t93mc4.png,faces_and_typography,Google SynthID,gemini-app,2c33e75a2db614ce74c83cc0a6ac6c3ac735aca83ab88c9c9345843b124f7856,no,no
+meta,../../contentseal/originals/gen_fox_forest.webp,photoreal_texture,Meta Content Seal,meta-oracle,6d7cecf322a5ac4b2547e2f32c767b3cb3e8a0e49f274cfd00aa31be6697eed4,no,no
+meta,../../contentseal/originals/gen_text_poster.webp,typography,Meta Content Seal,meta-oracle,873927662d8198e9c38b4ae71a2919ba5d417dfcd714649db1b0ae231e8cbf9b,no,no
+meta,../../contentseal/originals/gen_lighthouse_watercolor.webp,watercolor,Meta Content Seal,meta-oracle,69bee7c376608568361085602c5c7406900885849bd94c5279c3924cf793b27c,no,no
+meta,../../contentseal/originals/gen_night_city.webp,urban_night,Meta Content Seal,meta-oracle,345adf6b9f777b15ef7ce7bbdfb3b355a1d9e882740809e966e9f6caafd94d48,no,no
+meta,../../contentseal/originals/gen_studio_mug.webp,product_still_life,Meta Content Seal,meta-oracle,2b7bc7fd56fa2250c66ef74f8b3e49d9666fe147d894d5baf9461b5e36077a07,no,no

data/evaluations/engine-selection/content-manifest.csv

@@ -0,0 +1,39 @@
+pair_id,provider,model,file,width,height,content_stratum,sha256,source_payload_sha256,prompt
+00,openai,gpt-image-1-mini,originals/openai/00.png,1024,1024,natural_landscape,698896455e0f1de57a227339227bf068143e690873b9c8c9672b31578de93ba0,1345f59fc7b51a1edf837745245bb90811feefd9ba7f9ba6f12dc89846aeba18,"a stunning photograph of a mountain lake at sunrise, highly detailed, professional photography"
+00,meta,muse-image-1.0,originals/meta/00.png,1600,1600,natural_landscape,83362c189b79cd0e700296b975e9ef8e7f2b2fe89813e407bc795299400ca5e0,83362c189b79cd0e700296b975e9ef8e7f2b2fe89813e407bc795299400ca5e0,"a stunning photograph of a mountain lake at sunrise, highly detailed, professional photography"
+01,openai,gpt-image-1-mini,originals/openai/01.png,1024,1024,street_scene,b885d8cb1490e4fbbe580b87750008780671390097d28e71ff18b50cf320ec85,772518e4686940d2c68df114298fb007a97a5c42548245092e989b6ca9bd5b90,"a vibrant street market in Bangkok with colorful fruits and spices, candid photo"
+01,meta,muse-image-1.0,originals/meta/01.png,1600,1600,street_scene,5ba08cf9ab07bf00f64f39fe93f1766a64f737817b00086783476566c5f3317f,5ba08cf9ab07bf00f64f39fe93f1766a64f737817b00086783476566c5f3317f,"a vibrant street market in Bangkok with colorful fruits and spices, candid photo"
+02,openai,gpt-image-1-mini,originals/openai/02.png,1024,1024,single_portrait,97618d1a5c39ddeba708df3a9448b27d1d26583ee68b490ba79f7f3e1eb2248d,6bace9d2adae4d630e1830449f0945a30d7ddb3635e3005bc7aad80206a57176,"a close-up portrait of a woman with freckles and green eyes, studio lighting, 85mm lens"
+02,meta,muse-image-1.0,originals/meta/02.png,1600,1600,single_portrait,4daf07fc8bdfe007b96a70b00ec0cfde87f180eb8c2d5501723e218ed29e7589,4daf07fc8bdfe007b96a70b00ec0cfde87f180eb8c2d5501723e218ed29e7589,"a close-up portrait of a woman with freckles and green eyes, studio lighting, 85mm lens"
+03,openai,gpt-image-1-mini,originals/openai/03.png,1024,1024,animal_action,eb6920aab03bbe6935a01756c8f2d524d383e307369cdfaad3fe44926fbd9e48,2012abb15be639ebb3c596d2210f6d4c50cce0e11dd6cfc88aeb29de1c82de18,"a golden retriever running through a field of sunflowers, action photography"
+03,meta,muse-image-1.0,originals/meta/03.png,1600,1600,animal_action,93dce3a5049f773adb882ef22243a84e4822b9c43ad30774741c40f3844ef405,93dce3a5049f773adb882ef22243a84e4822b9c43ad30774741c40f3844ef405,"a golden retriever running through a field of sunflowers, action photography"
+04,openai,gpt-image-1-mini,originals/openai/04.png,1024,1024,reflective_architecture,275d68de881041de989261ced7570dd460028e0406346642d880d0d1664bb9ae,1808d95c69080aafced4234e4c3ad7714121bad00f3f5dc84a744288d9757245,"a modern architecture building with glass facade reflecting sunset clouds"
+04,meta,muse-image-1.0,originals/meta/04.png,1600,1600,reflective_architecture,209c71f0b737a9ef60b4d620c66f518b34dbc42af4532b2b8e0b3086183c90ec,209c71f0b737a9ef60b4d620c66f518b34dbc42af4532b2b8e0b3086183c90ec,"a modern architecture building with glass facade reflecting sunset clouds"
+05,openai,gpt-image-1-mini,originals/openai/05.png,1024,1024,food_closeup,316a743ccf29f025904d1bcd047a6996f987715e4f93e8a0d9cf85b624349b07,a8bac088c350ef849bbf78a85a1e44aa1665d1054a0cdfae29461c1cdca56e4a,"a bowl of ramen with steam rising, moody food photography, shallow depth of field"
+05,meta,muse-image-1.0,originals/meta/05.png,1600,1600,food_closeup,4a50ca3e33ddacd2897b926cdc54615a389416fcd2edf4d8803ad882b85b33af,4a50ca3e33ddacd2897b926cdc54615a389416fcd2edf4d8803ad882b85b33af,"a bowl of ramen with steam rising, moody food photography, shallow depth of field"
+06,openai,gpt-image-1-mini,originals/openai/06.png,1024,1024,sports_action,390d87d1f59eb4fa38590c0c751b2848383c77ffcf549571a0bf00db0f783763,6cc24eeb0fce95a86741b9ac0c055002793a586ba37f0cf4d64201a5c5e73513,"a surfer riding a barrel wave at golden hour, backlit spray"
+06,meta,muse-image-1.0,originals/meta/06.png,1600,1600,sports_action,1d9fcbf0f471f733ae96ca94dff892afd9f5852767000e379d3486dc94e30b78,1d9fcbf0f471f733ae96ca94dff892afd9f5852767000e379d3486dc94e30b78,"a surfer riding a barrel wave at golden hour, backlit spray"
+07,openai,gpt-image-1-mini,originals/openai/07.png,1024,1024,interior_low_light,4c77c2814216bdcde3417d2d228c5b6f275e33777f13cbea7911241bc9bc376b,9e858b95a4f842c917cbf47afeb4b7e0e24e04c4df0b19da4afe00b7316a13a9,"a cozy reading nook with warm lamp light and rain on the window"
+07,meta,muse-image-1.0,originals/meta/07.png,1600,1600,interior_low_light,ecec76c086a7b33beec1b3cb787f62cad68c09cb362a8888a8af734e9d4f3425,ecec76c086a7b33beec1b3cb787f62cad68c09cb362a8888a8af734e9d4f3425,"a cozy reading nook with warm lamp light and rain on the window"
+08,openai,gpt-image-1-mini,originals/openai/08.png,1024,1024,isometric_illustration,d688f6da74d4a7b2bd29ef59ba64864d0915134433febd8c90eb5ce1dc80781f,37a801f66b7c1bf63e613a7a5717dbc00397120a7a32ec45414661e03137a180,"an isometric illustration of a cozy coffee shop interior, warm colors, detailed"
+08,meta,muse-image-1.0,originals/meta/08.png,1600,1600,isometric_illustration,d4683d16a55c5f358f5b3b876b89fbc810ae1e3332e74399395ae20c9f646ef5,d4683d16a55c5f358f5b3b876b89fbc810ae1e3332e74399395ae20c9f646ef5,"an isometric illustration of a cozy coffee shop interior, warm colors, detailed"
+09,openai,gpt-image-1-mini,originals/openai/09.png,1024,1024,watercolor,d0beefb80ee00a0937a851932a2ed6dab2c670f10104ffe94c5ff22869a9595d,b52401235efc16641d3cb8f9c7c6d20a75c36751ada9409b65ceefa0e57901da,"a watercolor painting of Venice canals at sunset, loose brushstrokes"
+09,meta,muse-image-1.0,originals/meta/09.png,1600,1600,watercolor,c76ffbca59fbcb2dba9b66c94598f0c0062b0ac4679e348cdf1e18a06d3eb64d,c76ffbca59fbcb2dba9b66c94598f0c0062b0ac4679e348cdf1e18a06d3eb64d,"a watercolor painting of Venice canals at sunset, loose brushstrokes"
+10,openai,gpt-image-1-mini,originals/openai/10.png,1024,1024,macro_detail,59d9c6dce5ce4c2b77427144ccbafc8a4b7ab87564673677119859c31598b0d4,3740f9de304f050fc7306447c6668dcaa8156a888709f759f05715e7987a321c,"a macro photograph of a dewdrop on a spider web at dawn, bokeh background"
+10,meta,muse-image-1.0,originals/meta/10.png,1600,1600,macro_detail,c86fd9c3a59aa0bec709c5bce7c2ef1be4ecb1d780f3a3f35460b73cd97d1a12,c86fd9c3a59aa0bec709c5bce7c2ef1be4ecb1d780f3a3f35460b73cd97d1a12,"a macro photograph of a dewdrop on a spider web at dawn, bokeh background"
+11,openai,gpt-image-1-mini,originals/openai/11.png,1024,1024,urban_night,e4f6f806ed8559973374eae1e4d379807e45046749b7d491edbbc8ad9647728e,06bfc68289ece1b85b169df4cedd5e1cf12d0efa30631bdecd0e3edce4d8c82e,"a cinematic wide shot of Tokyo at night with neon reflections on wet streets"
+11,meta,muse-image-1.0,originals/meta/11.png,1600,1600,urban_night,7877cf0c13b07fbc6651178d838db4ab253369896292af1cf3f85a957a559db8,7877cf0c13b07fbc6651178d838db4ab253369896292af1cf3f85a957a559db8,"a cinematic wide shot of Tokyo at night with neon reflections on wet streets"
+12,openai,gpt-image-1-mini,originals/openai/12.png,1024,1024,flat_illustration,6bf230aa0b6f40d7ff0d23b22b8aac2e9b66288eb85c02eebdf43b71a1597f5b,65567d5cecb34241ac755ac4db5eb5a7b271d9a00fa27d826c961d2a2ef6ac3d,"a flat-design poster of Santorini with bold shapes, screen print style"
+12,meta,muse-image-1.0,originals/meta/12.png,1600,1600,flat_illustration,1b71bd94aa18d737c8a1c319a33dd0f0e9e15c2e93210c9c3aa98242b9a67955,1b71bd94aa18d737c8a1c319a33dd0f0e9e15c2e93210c9c3aa98242b9a67955,"a flat-design poster of Santorini with bold shapes, screen print style"
+13,openai,gpt-image-1-mini,originals/openai/13.png,1024,1024,storm_landscape,d07b05eef633fcb5b6b54268cc2cdd787dc19f8050198872e462f69e383a054d,a692a8a0daebad375cd57d7c671be6e16ad3ef700f0b9214daacbe80b6148c90,"a dramatic storm cloud over a lonely lighthouse, moody, high contrast photography"
+13,meta,muse-image-1.0,originals/meta/13.png,1600,1600,storm_landscape,e669128fe2d3b59dc83ae0b216c5378fe5930e77fa3a692219da238dbf55d5f6,e669128fe2d3b59dc83ae0b216c5378fe5930e77fa3a692219da238dbf55d5f6,"a dramatic storm cloud over a lonely lighthouse, moody, high contrast photography"
+14,openai,gpt-image-1-mini,originals/openai/14.png,1024,1024,monochrome_portrait,9fb1153f4d0041932b35bcd1408d774b642c68f81d7bb403d22f50f8c891ede7,826acf13df78378499e57c7fe1a8309947ab26810f46482be3a64d3328de1ff6,"a black and white portrait of an elderly craftsman in his workshop"
+14,meta,muse-image-1.0,originals/meta/14.png,1600,1600,monochrome_portrait,8339475f0585491ea08992d29890f3c759f24db2184212c6bf4f7efc0932e177,8339475f0585491ea08992d29890f3c759f24db2184212c6bf4f7efc0932e177,"a black and white portrait of an elderly craftsman in his workshop"
+15,openai,gpt-image-1-mini,originals/openai/15.png,1024,1024,surreal_composite,8bf02f9028fd049ebfafd3410d2eb9d618819be1c14b4e05d53a490e22ba109c,e71de5a9a2f6579857d2e24b8e7a1516031f19ee824906cece158101d13fe001,"a surreal double exposure of a forest and a human profile, conceptual art"
+15,meta,muse-image-1.0,originals/meta/15.png,1600,1600,surreal_composite,20628541cc924e623984604337807c7afd453aa8a7652f087add742a13828f6a,20628541cc924e623984604337807c7afd453aa8a7652f087add742a13828f6a,"a surreal double exposure of a forest and a human profile, conceptual art"
+16,openai,gpt-image-1-mini,originals/openai/16.png,1024,1024,brutalist_architecture,e91ca5128ce8644510c5c4def6bba085e45e1716105b3b6a2761cc18d42018b3,0aa8a1819f160ce26dfc9e59b996f969698fdf4eba3402fe999af598fcad80d4,"a low-angle shot of a brutalist building against dramatic clouds"
+16,meta,muse-image-1.0,originals/meta/16.png,1600,1600,brutalist_architecture,d22702d26343b6575e89751c95d865696c6085bed053f6008f989434a96bac02,d22702d26343b6575e89751c95d865696c6085bed053f6008f989434a96bac02,"a low-angle shot of a brutalist building against dramatic clouds"
+17,openai,gpt-image-1-mini,originals/openai/17.png,1024,1024,product_still_life,4f41f4a46b80c0ded61a9a3ce1273412b1728476a0734519d1af34a1797013b0,1f60c25c59138c14bacb0dd485475037e7d6222bb45daa66ed85f9dd91c83e4e,"a minimalist product photo of a ceramic mug on a marble surface, clean commercial look"
+17,meta,muse-image-1.0,originals/meta/17.png,1600,1600,product_still_life,67bde86edfd3db08b88c0dbc5572958408875e188dac6fa8ed64f821b7e7e994,67bde86edfd3db08b88c0dbc5572958408875e188dac6fa8ed64f821b7e7e994,"a minimalist product photo of a ceramic mug on a marble surface, clean commercial look"
+18,openai,gpt-image-1-mini,originals/openai/18.png,1024,1024,person_in_context,9b049d3112a654a87022d591b93a01087693c0664be5af560d3c0ec490291963,ba873bc7989720245821f5298f12e36bd7b6051909694b72569645c29cdd6bd0,"a lifestyle photo of a person working on a laptop in a bright cafe"
+18,meta,muse-image-1.0,originals/meta/18.png,1600,1600,person_in_context,cc4b2bcfc4e80d7dfe6646beb12529168137aef04d2b6765c6382b830ce19ed7,cc4b2bcfc4e80d7dfe6646beb12529168137aef04d2b6765c6382b830ce19ed7,"a lifestyle photo of a person working on a laptop in a bright cafe"

data/evaluations/fidelity/anytext2-restoration-2026-08-13.csv

@@ -1,4 +1,4 @@
 date,source_commit,fixture,variant,model,model_revision,model_sha256,ocr_route,text_cer,img_lpips,ssim,psnr_db,output_sha256,provider_oracle,notes
-2026-08-13,2d03a00,Gemini_Generated_Image_633uuy633uuy633u.png,qwen-zimage,,,,"Paddle ch",0.074,0.289,0.696,23.3,4b05489c7a79f993d35d32528de792baad5a3e33ee950afa147caf5d3e0621,not_run,Exact Qwen baseline reused from text-restoration benchmark
+2026-08-13,2d03a00,Gemini_Generated_Image_633uuy633uuy633u.png,qwen-zimage,,,,"Paddle ch",0.074,0.289,0.696,23.3,4b05489c7a79f993d35d32528de792baad5a3e33ee950afa147caf5d3e0621a6,not_run,Exact Qwen baseline reused from text-restoration benchmark
 2026-08-13,2d03a00,Gemini_Generated_Image_633uuy633uuy633u.png,qwen-zimage-anytext2-default,AnyText2-SD1.5,b06c583a583818f3679665ef67b51363f107853c,7d5d593928d842500e0da101ab6a1ae28a8d21403441ca62c813c4f92529ace8,"Paddle ch",0.185,0.338,0.642,18.2,87729fe7e0482d2cead6d3b7c7dd386ecc75ab3d8658131c54e67528b8f9feeb,not_run,Fidelity gate failed; padded crop recognition CER 0.074 still shows two substituted characters; locally composited three-line edit; 20 DDIM steps; seed 0
 2026-08-13,2d03a00,Gemini_Generated_Image_633uuy633uuy633u.png,qwen-zimage-anytext2-mimic,AnyText2-SD1.5,b06c583a583818f3679665ef67b51363f107853c,7d5d593928d842500e0da101ab6a1ae28a8d21403441ca62c813c4f92529ace8,"Paddle ch",0.222,0.345,0.644,17.9,f5198d8f2365b79880aba8ea6b0c3885142b9de21c9f7f4f6712ac4a0db8dd85,not_run,Fidelity gate failed; source glyph masks supplied as font hints; 20 DDIM steps; seed 0

data/evaluations/video-synthid-oracle.csv

@@ -1,3 +1,3 @@
 date,source_url,source_sha256,source_width,source_height,source_fps,duration_seconds,source_verdict,vae,noise_std,long_side,fps,seed,output_sha256,output_verdict,output_verdict_text,output_detected_range,track,session_id,stratum,psnr_db,temporal_residual_ratio
-2026-07-31,https://storage.googleapis.com/gdm-deepmind-com-prod-public/media/media/veo__veo-3__off-road.mp4,79a552b9406a079682440c31f14d33a10ba8e1b8b2e96425f5de70f63350299d,1920,1080,24,8,detected_all_frames,,0.10,512,12,0,079165105d4c56e1612091987c08c2627049423025f74c0d4e245fb47c2ff0e3,detected,,,,,,26.2932,1.0072
-2026-07-31,https://storage.googleapis.com/gdm-deepmind-com-prod-public/media/media/veo__veo-3__off-road.mp4,79a552b9406a079682440c31f14d33a10ba8e1b8b2e96425f5de70f63350299d,1920,1080,24,8,detected_all_frames,,0.15,512,12,0,1c4046bcfdead138353b4e2a73339ba227bb5e544878d80c5bc6cd8427c7b00e,not_detected,,,,,,25.3911,1.0578
+2026-07-31,https://storage.googleapis.com/gdm-deepmind-com-prod-public/media/media/veo__veo-3__off-road.mp4,79a552b9406a079682440c31f14d33a10ba8e1b8b2e96425f5de70f63350299d,1920,1080,24,8,detected_all_frames,unrecorded,0.10,512,12,0,079165105d4c56e1612091987c08c2627049423025f74c0d4e245fb47c2ff0e3,detected,,,,,,26.2932,1.0072
+2026-07-31,https://storage.googleapis.com/gdm-deepmind-com-prod-public/media/media/veo__veo-3__off-road.mp4,79a552b9406a079682440c31f14d33a10ba8e1b8b2e96425f5de70f63350299d,1920,1080,24,8,detected_all_frames,unrecorded,0.15,512,12,0,1c4046bcfdead138353b4e2a73339ba227bb5e544878d80c5bc6cd8427c7b00e,not_detected,,,,,,25.3911,1.0578

data/fixtures/README.md

@@ -13,3 +13,23 @@ example from [`adobe/trustmark`](https://github.com/adobe/trustmark) at commit
 - SHA-256: `e58c5825ed7e5d9fb04710ea541b61bd55879cad65554c0d46260aa24b3d0755`
 - Expected signal: TrustMark Variant P, schema 1
 - License: MIT, reproduced in `../licenses/adobe-trustmark-MIT.txt`
+
+
+## Ideogram C2PA attribution
+
+`ideogram-c2pa.png` is a SYNTHETIC signed manifest, not a vendor download: a
+64x64 flat PNG carrying a C2PA claim (`trainedAlgorithmicMedia`,
+`claim_generator "Ideogram/3.0"`) signed by a throwaway test CA whose leaf
+certificate subject is `O=Ideogram, Inc, CN=Ideogram, Inc`. It exercises the
+issuer-to-platform ATTRIBUTION path end to end through the real reader; the
+signer is deliberately untrusted (no trust anchors ship), which is also the
+fixture's second assertion: attribution and signer trust are separate
+dimensions.
+
+- Expected signal: C2PA, platform `Ideogram`, `ai_from_metadata` True
+- Expected signer: `untrusted` (test CA; attribution must not imply trust)
+- Recipe (no keys are committed): create a CA and an ES256 leaf with
+  `digitalSignature` key usage and subject `CN=Ideogram, Inc`, then
+  `c2pa.Builder.from_json(...).sign_file(png, out, Signer.from_info(
+  C2paSignerInfo(b"es256", leaf_pem + ca_pem, pkcs8_key, None)))`.
+- No user upload and no Ideogram artifact contributes pixels or bytes.

data/fixtures/visible/README.md

@@ -0,0 +1,41 @@
+# Visible-mark example gallery
+
+One committed example per registered visible mark, so the repository carries a
+working sample of everything it supports. `tests/test_visible_examples.py` holds
+both sides to it: a mark registered without an example fails the suite, and so
+does an engine that stops detecting its own example.
+
+## What these files are
+
+Every example is SYNTHETIC: `scripts/render_visible_examples.py` composites the
+mark's committed silhouette (the same font-rendered asset the detector matches)
+onto a deterministic generated base photo at the engine's measured geometry.
+The silhouettes are repository-owned font renders generated by
+`scripts/render_vendor_silhouettes.py`; the gallery does not copy vendor raster
+assets.
+
+The examples demonstrate DETECTION geometry and house style, not vendor raster
+fidelity; real-world variants (fonts, opacities, sizes) are covered by the
+engines' recorded calibration evidence.
+
+## Regeneration
+
+    uv run python scripts/render_visible_examples.py
+
+The generator self-verifies: it fails (exit 1) if any registered mark does not
+detect on its own example, so regeneration is the fix point for drift.
+
+## Layout
+
+    <mark-key>/example.png   1536x2048..2048x2048 PNG, one per image mark
+    <mark-key>/example.mp4   960x540 90-frame clip, one per video mark
+                            (kling carries both: it is registered in both registries)
+
+Special cases: `gemini` composites the sparkle alpha map at the provider's
+configured position; `jimeng_pill` is the capture-less pill at the measured
+3:4 portrait geometry; `microsoft` is the opaque white pill with dark text
+holes (the discriminator its detector keys on). Video examples composite the
+detector's own synthetic template on every frame; where two marks share a
+shape family the example carries the discriminative variant (`veo` the legacy
+text form, `kling` the logo-plus-wordmark pair flush to the edge), because the
+temporal selection resolves cross-template ties by table order.

data/synthid/README.md

@@ -54,7 +54,10 @@ versions, or runtime settings.
 Ground-truth quality, strongest first:
 
 - `gemini-app` — checked via the Gemini app "Verify with SynthID" feature. Gold standard for the pixel watermark (Google models).
-- `openai-verify` — checked via openai.com/verify (gold standard for OpenAI ChatGPT/Codex/API images).
+- `openai-verify` — checked through the OpenAI web verifier. This is the
+  historical manifest label for existing rows. OpenAI now also documents a
+  Content Provenance API with a separate SynthID result; add a distinct manifest
+  value before recording API-derived labels rather than silently reusing this one.
 - `synthid-portal` — checked via Google's SynthID Detector portal.
 - `c2pa-metadata` — supported provenance evidence (Google AI C2PA, or OpenAI
   C2PA with an explicit `c2pa.watermarked.*` action). Weaker than a provider
@@ -160,7 +163,7 @@ sparkle; the SynthID *pixel* itself has no local detector (oracle only).
 
 Key takeaways:
 - The same model differs by *surface*: Gemini app wraps C2PA, AI Studio (API/playground) emits none -- only the pixel + sparkle survive.
-- Microsoft Designer's DALL-E backend inherits OpenAI's C2PA+SynthID (issuer "OpenAI, Microsoft"); Bing now runs Microsoft's own **MAI-Image** and signs C2PA as "Microsoft" (not OpenAI/DALL-E).
+- Microsoft Designer's DALL·E backend inherits OpenAI's C2PA+SynthID (issuer "OpenAI, Microsoft"); Bing now runs Microsoft's own **MAI-Image** and signs C2PA as "Microsoft" (not OpenAI/DALL·E).
 - Meta uses the IPTC `digitalSourceType` marker, not C2PA or SynthID.
 - The open imwatermark fires only on *pristine* output from a pipeline that runs the encoder (diffusers default, official BFL) -- not from re-hosts (Krea, Stability hosted SDXL) or re-encoded design exports (Recraft, Canva). Ideogram's only signal is the EXIF `Make` tag.
 - Bing and Grok web UIs are uncooperative for autonomous capture (no document_idle for screenshots; blob downloads intermittently no-op; low-res in-chat previews). Use their native download button manually if a full-res sample is needed.

data/synthid/research-manifest.md

@@ -0,0 +1,91 @@
+# Private SynthID research manifest
+
+The research manifest is a local CSV for detector and pixel-only removal
+experiments. It is intentionally separate from `manifest.csv`, which describes
+the small public regression corpus.
+
+Store the CSV and its media below `.local-eval/synthid/`. Keep one manifest per
+detector target, for example `google-manifest.csv` and `openai-manifest.csv`.
+Separate manifests may reference the same external negative bytes without
+duplicating an artifact inside either provider's split graph. Do not commit
+private media, corpus sizes, oracle sessions, or provider-access details.
+
+Before assigning labels, build a label-free inventory. It records byte and
+decoded-pixel hashes, exact duplicates, geometry, and format, but deliberately
+has no provider, oracle, outcome, or split columns:
+
+```bash
+uv run python scripts/synthid_research_inventory.py \
+  --root .local-eval/synthid negatives google openai \
+  --inventory-out .local-eval/synthid/inventory.csv
+```
+
+An inventory row becomes a manifest row only after its source, detector target,
+label evidence, group lineage, and split are established independently. A
+directory name is not evidence and must not be promoted mechanically.
+
+Audit each local manifest with:
+
+```bash
+uv run python scripts/synthid_research_manifest.py \
+  .local-eval/synthid/google-manifest.csv --verify-files
+```
+
+Once a provider manifest has ordinary positives and negatives in train,
+validation, and locked-test splits, run the D1 confound challenge:
+
+```bash
+uv run --extra pixels python scripts/synthid_confound_probe.py \
+  .local-eval/synthid/google-manifest.csv \
+  --target-provider google \
+  --report-out .local-eval/synthid/google-d1-confounds.json
+```
+
+D1 excludes candidate, sham, and source-control rows. Its `container`,
+`thumbnail`, and `canonical` baselines intentionally measure how well export
+fields, geometry, and coarse generator/content style can imitate detection. A
+report is evidence-ready only when the locked test includes a same-provider hard
+negative and the temporal split contains both labels. Evidence readiness does
+not mean the D1 gate passed; a candidate signal still has to beat the frozen
+canonical baseline on those controls.
+
+## Columns
+
+| Column | Meaning |
+| --- | --- |
+| `artifact_sha256` | SHA-256 of the exact file submitted or measured. |
+| `pixel_sha256` | SHA-256 of decoded RGB bytes, used to catch lossless duplicates. |
+| `artifact_path` | Safe path relative to the manifest. |
+| `parent_sha256` | Exact parent artifact for a derivative, empty for an original. |
+| `group_id` | Leakage boundary shared by an original and all semantic or transformed siblings. |
+| `target_provider` | Detector target, `openai` or `google`. |
+| `source_provider` | Actual source family: `openai`, `google`, `camera`, `other_ai`, `synthetic`, or `editor`. |
+| `surface` | Product or export surface. |
+| `model_epoch` | Model family plus a dated epoch when the exact version is unavailable. |
+| `generation_session` | Groups outputs created in one provider session. |
+| `content_stratum` | Predeclared content class. |
+| `width`, `height`, `format` | Decoded geometry and file format. |
+| `transform` | `original` or the reproducible transform applied to `parent_sha256`. |
+| `split` | `discovery`, `train`, `validation`, `test`, or `temporal`. |
+| `c2pa_outcome` | C2PA result, recorded independently from the pixel signal. |
+| `synthid_outcome` | `detected`, `not_detected`, `indeterminate`, `refused`, or `not_checked`. |
+| `verified_via` | Matching provider oracle, external source evidence, or `none`. |
+| `evidence_reference` | Stable URL or local evidence-record reference required for `source-evidence`; never infer it from a directory name. |
+| `oracle_session` | Groups allowed checks made in one session. |
+| `oracle_role` | `ordinary`, `source_control`, `candidate`, or `sham`. |
+| `captured_at`, `oracle_checked_at` | Timezone-aware ISO-8601 timestamps. |
+| `notes` | Verbatim context that does not fit a structured column. |
+
+`source-evidence` may establish an ordinary external negative, but never a
+positive or a same-provider negative. Provider positives and same-provider hard
+negatives require the matching provider verifier. An `indeterminate`, `refused`,
+or unchecked row may remain in `discovery`; it cannot enter a train, validation,
+test, or temporal split. Every `source-evidence` row must retain the source URL
+or evidence-record reference that establishes the claim.
+
+The auditor also rejects duplicate artifact hashes, identical decoded pixels in
+different groups, derivatives without parents, cross-provider parentage,
+lineage cycles, and any group crossing split boundaries. A `not_detected`
+candidate or sham is valid only when the same provider, group, and oracle
+session contains a detected `source_control`. A session that misses its control
+cannot establish removal, even when its candidate response is negative.

docs/chroma1-engine-research.md

@@ -0,0 +1,550 @@
+# Chroma1 engine research (2026-08-29/30)
+
+> Research archive. This page records experiments and decisions from the dates
+> above. Current package behavior is defined by the
+> [supported signals](supported-signals.md), [known limitations](known-limitations.md),
+> and [module internals](module-internals.md). Nothing here is shipped.
+
+Cited experiment behind issue #88 ("Please integrate Flux 2"): FLUX.2 has no
+native strength img2img anywhere (BFL reference code or diffusers; its image
+inputs are reference conditioning and outputs start from pure noise), so the
+requestable scrub lane in the FLUX family is **Chroma1** -- the FLUX.1
+architecture re-trained on open data, Apache-2.0 on weights, with a native
+`ChromaImg2ImgPipeline` strength parameter. This page records what was measured
+before any integration decision.
+
+## Setup
+
+All Chroma1 runs: `lodestones/Chroma1-HD` bf16 on Modal H100, seed 0, the
+neutral scrub prompt (`high quality, sharp, detailed, faithful to the original`
+/ `blurry, lowres, distorted text, garbled text, artifacts`), guidance 5.0, and
+**step compensation**: Diffusers truncates the step COUNT (`int(steps *
+strength)`), so the requested count is scaled to always spend 4 effective
+denoising steps, the same semantics as `sdxl_zimage_pipeline.requested_steps`.
+Without it, strength 0.05 runs a single step and the floor reads artificially
+high (the first, uncompensated sweep put the OpenAI boundary at (0.05, 0.10];
+compensated it is (0.05, 0.06]).
+
+Two Flux-family traps found while wiring the prototype:
+
+- without explicit `width`/`height`, the img2img pipeline silently generates
+  1024x1024 regardless of input aspect;
+- dimensions floor to the /16 latent-patch grid, so the result must be resized
+  back to the input size for pixel-exact comparison.
+
+Scripts: `scripts/chroma_scrub_prototype.py` (first sweep),
+`scripts/engine_quality_price_probe.py` (head-to-head with the production
+qwen-zimage path), `scripts/engine_cohort_calibration.py` (the cohort ladders
+below), `scripts/chroma_meta_high_rungs.py` (the Meta rungs above 0.08),
+`scripts/chroma_muse_expansion.py` (harvest-2 Meta API fixtures),
+`scripts/chroma_openai_expansion.py` (extra OpenAI SynthID carriers),
+`scripts/chroma_seed_probes.py` (seed-1/2 at measured first-cleans).
+Generated outputs stay outside the repository (`out/`, gitignored); the durable
+verdicts are the tables on this page.
+
+## Measured floors
+
+Oracle per cohort: OpenAI via openai.com/verify (SynthID read separately from
+C2PA); Meta via the anonymous meta.ai/identification oracle. Each fixture's
+rungs were checked ascending and stopped at the first clean verdict.
+
+| cohort | fixture | detected at | clean from |
+|---|---|---|---|
+| OpenAI | typography card 1122x1402 | 0.05 | 0.06 |
+| OpenAI | 9-face grid 1448x1086 | 0.06 | 0.075 |
+| OpenAI | full-pipeline quality fixture 1122x1402 | 0.05 | 0.06 |
+| Meta | gen_lighthouse_watercolor 1600x1600 | 0.08 | 0.10 |
+| Meta | gen_fox_forest 1600x1600 | 0.06 | 0.08 |
+| Meta | gen_night_city 1920x1280 | 0.045 | 0.06 |
+| Meta | gen_studio_mug 1600x1600 | 0.03 | 0.045 |
+| Meta | gen_text_poster 1600x1600 | -- | <=0.03 |
+
+Derived operating points by the shipped rule (worst first-clean boundary plus
+one observed cross-source spread):
+
+- **OpenAI: 0.09** (0.075 + (0.075 - 0.06)). Against qwen-zimage 0.07675 and
+  sdxl-zimage 0.15. The typography boundary (0.05, 0.06] is seed-stable across
+  seeds 0, 1, 2.
+- **Meta: 0.17** (0.10 + (0.10 - 0.03)), oracle-verified clean on the worst
+  fixture at 0.17. Against qwen-zimage 0.1. Chroma needs ~1.7x qwen's strength
+  on Content Seal.
+- **Google: 0.40, measured 2026-08-30 across all four fixtures.** A
+  metadata-stripped original verified as pixel-DETECTED through the @synthid
+  Verify AI agent (the C2PA-carrying original answers about C2PA instead,
+  which is not a pixel verdict).
+
+  | fixture | detected at | clean from |
+  |---|---|---|
+  | Gemini_Generated_Image_633uuy | 0.20 | 0.25 |
+  | Gemini_Generated_Image_akdbei | 0.20 | 0.25 |
+  | Gemini_Generated_Image_y48j3c | 0.08 | 0.12 |
+  | Gemini_Generated_Image_3mc4t9 | 0.08 | 0.12 |
+
+  Derived by the shipped rule: worst first-clean 0.25 + spread (0.25 - 0.12
+  = 0.13) = 0.38, rounded up to the measured rung **0.40**, then
+  oracle-verified clean on the worst fixture. Against qwen-zimage 0.27:
+  Chroma needs ~1.5x the strength on Google SynthID. At 0.15-0.20 the tool
+  still reads positive while its wording degrades from "most or all" to
+  "part of", so the boundary band is real signal decay, not noise.
+
+  Oracle mechanics learned while bracketing: the quota is per ACCOUNT and
+  additionally dedupes SIMILAR images ("quota for checking images similar to
+  this one"), roughly three checks per account window; switching accounts
+  inside one browser works. A fresh Playwright context with the same Google
+  session cookies (exported browser-wide via CDP `Storage.getCookies`, never
+  through the transcript) carries working sign-in and its own check budget.
+  The agent's own instructions leak into the answer on some renders and
+  include an abstention rule for text-dominated images - always read the TOOL
+  outcome, never the prose.
+- **Microsoft: 0.125**, measured 2026-08-30 on the SAME three valid Paint
+  carriers behind the qwen floor (staged under
+  `out/cohort-calibration/microsoft/` with pixel-identical metadata-stripped
+  controls; they are real raiw-corpus user uploads and are never committed).
+  Controls re-verified `Microsoft AI detected` on the day of the run. Against
+  qwen-zimage 0.15: Chroma needs LESS strength on InvisMark.
+
+  | source (Paint) | detected at | clean from | qwen first-clean |
+  |---|---|---|---|
+  | paint-1 (47d87e99, 1536x1024) | 0.06 | 0.08 | 0.055 |
+  | paint-2 (a579fb70, 1536x1024) | -- | <=0.04 | 0.04125 |
+  | paint-3 (883191b5, worst qwen source) | 0.06 | 0.08 | 0.095 |
+
+  Derived by the shipped rule: 0.08 + (0.08 - 0.04) = 0.12, rounded to the
+  measured rung **0.125**, which was then oracle-verified clean on both worst
+  sources. Oracle: the public `ai.azure.com/nextgen/validate` page; its
+  `Inconclusive` verdict is the site's watermark-negative, weaker than an
+  API-level `Watermark: false`, the same caveat the qwen cohort carries.
+
+## Fidelity at the floors (scripts/fidelity_metrics.py)
+
+qwen-zimage rows ran through the package's own `QwenZImagePipeline` on the same
+H100 (production path, both stacks resident, prompt cache warm).
+
+OpenAI typography (chroma 0.06 vs qwen 0.07675):
+
+| | CER | img LPIPS | SSIM | PSNR |
+|---|---|---|---|---|
+| qwen-zimage | 0.241 | 0.083 | 0.834 | 27.7 |
+| chroma1 | **0.138** | **0.049** | **0.881** | **31.2** |
+
+OpenAI full-pipeline fixture (chroma 0.09 vs qwen 0.07675): chroma wins every
+metric (CER 0.155 vs 0.259, LPIPS 0.056 vs 0.094, PSNR 29.6 vs 26.1).
+
+OpenAI 9-face grid (chroma 0.075 global-only vs qwen 0.07675 with its Z-Image
+face stage):
+
+| | ID cos | face LPIPS | img LPIPS | SSIM | PSNR |
+|---|---|---|---|---|---|
+| qwen-zimage | **0.857** | **0.051** | 0.065 | 0.865 | 31.1 |
+| chroma1 (no face stage) | 0.788 | 0.067 | **0.060** | **0.890** | **32.4** |
+
+The face stage regenerates from the ORIGINAL crops and is engine-independent,
+so an integrated `chroma-zimage` would composite the same faces over the
+chroma global; whether that closes the identity gap is an integration-time
+measurement, not a given.
+
+Meta at the respective floors (chroma 0.17 vs qwen 0.1): qwen wins perceptual
+fidelity on textured content (LPIPS: fox 0.163 vs 0.211, lighthouse 0.173 vs
+0.248, night city 0.187 vs 0.277), chroma wins the text poster decisively
+(LPIPS 0.008 vs 0.012, CER 0.000 vs 0.021) and the studio mug is a split. The
+extra 0.07 of strength costs real fidelity on photoreal content.
+
+Google at the respective floors (chroma 0.40 vs qwen 0.27, qwen row includes
+its Z-Image face stage):
+
+| fixture | qwen LPIPS/SSIM/ID cos | chroma LPIPS/SSIM/ID cos |
+|---|---|---|
+| 633uuy | **0.405 / 0.577** / - | 0.499 / 0.576 / - (CER 1.000 vs 0.333) |
+| akdbei | **0.440 / 0.552** / - | 0.540 / 0.557 / - (CER 0.796 vs 0.367) |
+| y48j3c (18 faces) | **0.436 / 0.608 / 0.801** | 0.560 / 0.548 / 0.279 |
+| 3mc4t9 (5 faces) | **0.422 / 0.529 / 0.921** | 0.562 / 0.461 / 0.143 |
+
+qwen wins every axis that matters on every fixture; at 0.40 the Chroma global
+regeneration itself collapses face identity (0.14-0.28 cosine) and destroys
+dense text (CER up to 1.0). The extra 0.13 of strength is simply too much
+regeneration. This is the Meta pattern amplified.
+
+Microsoft at the respective floors (chroma 0.125 vs qwen 0.15): chroma wins
+EVERY metric on EVERY source while scrubbing at lower strength --
+
+| source | CER q/ch | img LPIPS q/ch | SSIM q/ch | PSNR q/ch |
+|---|---|---|---|---|
+| paint-1 | 0.741 / 0.241 | 0.164 / 0.106 | 0.742 / 0.847 | 24.8 / 29.3 |
+| paint-2 | 0.826 / 0.391 | 0.253 / 0.108 | 0.536 / 0.633 | 22.5 / 25.5 |
+| paint-3 | 0.000 / 0.000 | 0.038 / 0.020 | 0.762 / 0.953 | 36.3 / 42.2 |
+
+The Microsoft cohort therefore behaves like the OpenAI cohort, not like Meta:
+for InvisMark carriers Chroma1 is the better engine at a lower operating point.
+
+## Price (warm H100 container)
+
+| | qwen-zimage | chroma1 |
+|---|---|---|
+| seconds per image | 2.44 | 3.62 |
+| VRAM peak | 31.9 GiB | 29.2 GiB |
+| USD per 1000 images ($3.95/h) | $2.68 | $3.97 |
+| weights in cache | ~70 GB | ~28 GB |
+
+The chroma number includes a T5 encode per call; the shipped qwen path caches
+prompt embeddings, and the same treatment would put chroma near 1.5-2 s/image.
+Both stacks fit an 80 GB card; chroma's smaller footprint likely fits smaller
+cards untested.
+
+## Matched-strength comparison: the floors hide the engine (2026-08-30 addendum)
+
+The floor-based tables above compare chroma at its DERIVED floor (worst case
++ spread) against qwen at its shipped floor - different perturbation levels.
+At the strength where each fixture ACTUALLY turns clean (chroma first-clean
+rungs, all oracle-verified above), the picture reverses:
+
+Google (chroma@first-clean vs qwen@0.27):
+
+| fixture | chroma rung | LPIPS q/ch | SSIM q/ch | PSNR q/ch | CER q/ch | ID q/ch |
+|---|---|---|---|---|---|---|
+| 633uuy | 0.25 | 0.405/**0.375** | 0.577/**0.673** | 18.8/**22.3** | **0.333**/0.667 | - |
+| akdbei | 0.25 | 0.440/**0.409** | 0.552/**0.650** | 18.6/**22.5** | 0.367/**0.163** | - |
+| y48j3c | 0.12 | 0.436/**0.329** | 0.608/**0.700** | 21.0/**25.8** | 1.0/1.0 | **0.801**/0.611 |
+| 3mc4t9 | 0.12 | 0.422/**0.318** | 0.529/**0.644** | 17.7/**21.3** | 0.443/**0.229** | **0.921**/0.410 |
+
+Meta (chroma@first-clean vs qwen@0.1):
+
+| fixture | chroma rung | LPIPS q/ch | SSIM q/ch | PSNR q/ch | CER q/ch |
+|---|---|---|---|---|---|
+| lighthouse | 0.10 (equal) | 0.173/**0.097** | 0.783/**0.886** | 25.6/**30.8** | - |
+| fox | 0.08 | 0.163/**0.083** | 0.778/**0.907** | 25.6/**31.4** | - |
+| night_city | 0.06 | 0.187/**0.092** | 0.748/**0.893** | 23.9/**29.6** | 0.850/**0.250** |
+| studio_mug | 0.045 | 0.024/**0.009** | 0.984/**0.992** | **39.0**/37.8 | - |
+| text_poster | 0.03 | 0.012/**0.002** | 0.984/**0.994** | 34.0/**41.2** | 0.021/**0.007** |
+
+At effective-clean strength Chroma1 wins whole-image fidelity on essentially
+every fixture (often by 4-6 dB) and text on five of six; qwen's remaining
+edge is face identity, which its Z-Image face stage buys (0.80-0.92 vs
+0.41-0.61 cosine) and a chroma-zimage profile would inherit on top of its own
+global pass.
+
+**Why the floors still matter:** a shipped strength must clear the worst
+unseen content, and Chroma1's per-fixture boundaries scatter much wider
+(Google 0.12-0.25, Meta 0.03-0.10) than the spread the flat floors were built
+to absorb - so its derived floors (0.40 / 0.17) pay a large margin penalty
+and at those floors the extra strength genuinely destroys quality. The
+engines differ less in "quality per strength" than in how predictable their
+boundary is. The integration lever this exposes: a content-adaptive strength
+policy for chroma-zimage (the project already ships resolution-adaptive
+denoise for qwen) could capture chroma's low per-content boundaries; the two
+hard Google fixtures are both dense-text cards and the easy ones are
+photoreal, so a content-class signal may predict the rung.
+
+## Pre-ship validation (2026-08-30)
+
+With the `chroma-zimage` profile implemented
+(`_internal/chroma_zimage_pipeline.py` on `TwoStageZImagePipeline`, floors in
+`watermark_profiles`), two ship-gate checks were run:
+
+1. **Seed stability at the worst Meta boundary.** lighthouse @ 0.10 with
+   seeds 1 and 2: both CLEAN on the meta.ai oracle. The Meta boundary is not a
+   seed-0 fluke. The Google seed probes (633uuy @ 0.25) delivered a critical
+   finding: **seed 0 was CLEAN but seed 1 was DETECTED** -- the 633uuy
+   boundary is seed-dependent, which validates the flat 0.40 floor's 0.15
+   margin exactly the way the qwen SDXL precedent did (the same image at the
+   same strength passing or failing run-to-run near the threshold). Seed 2
+   of `seedprobe_google_633uuy_s0.25_seed2.png` was checked twice on
+   2026-08-31 after a human drag-drop. Work Gemini (u/2, Pro,
+   `https://gemini.google.com/u/2/app/ebc7c19d22f85bb9`) with the
+   ordinary question "Is there a SynthID watermark in this image?"
+   auto-titled "SynthID Watermark Detection Results" and returned "No
+   reliable signals were detected indicating how the content was created,
+   and you should look for other supporting evidence from trusted
+   sources." Plus `@synthid` (u/0,
+   `https://gemini.google.com/u/0/app/658b1470307811b7`) with the built-in
+   verification question auto-titled "SynthID Image Verification Results"
+   and returned "No digital watermark from Google AI was detected in this
+   image, indicating that it was not created or edited using Google's AI
+   models." Both are CLEAN. An earlier Plus `@synthid` attempt on the
+   same file hung on "Connecting to Verify AI" with auto-title "SynthID
+   Image Verification Failed"; Flash prose abstained because "the tool
+   response does not confirm" Google AI, which is not a tool verdict.
+   Workspace Gemini's More-uploads menu does not list Photos, but a
+   human drag-drop of a local PNG does attach; one Workspace account in
+   the same Chrome has no Gemini app. Seed 0 CLEAN / seed 1 DETECTED /
+   seed 2 CLEAN at 0.25
+   leaves the 633uuy boundary seed-dependent on the Plus `@synthid`
+   path; the 0.40 floor is already established by the seed-1 flip.
+2. **Full-path face-stage interaction.** The complete profile run (Chroma1
+   global at the shipped Google floor 0.40, then the inherited
+   YuNet/SAM/Z-Image face stage) on the 5-face fixture 3mc4t9: CLEAN on the
+   @synthid oracle. The composited face regions do not re-introduce a
+   detectable signal on top of the floor.
+
+Generation script: `scripts/chroma_preship_validation.py`; outputs under
+`out/preship-chroma/` (gitignored).
+
+## Verdict
+
+Engine quality is cohort-dependent, and after measuring all four cohorts the
+split is even and sharp:
+
+- On OpenAI-provenance content Chroma1 is better at every measured fidelity
+  axis at its floor (0.09 vs 0.07675), for comparable money.
+- On Microsoft InvisMark content Chroma1 is better at every measured fidelity
+  axis at a LOWER floor than qwen (0.125 vs 0.15).
+- On Meta Content Seal Chroma1 needs 1.7x the strength (0.17 vs 0.1) and loses
+  LPIPS on textured content at its floor.
+- On Google SynthID Chroma1 needs ~1.5x the strength (0.40 vs 0.27) and loses
+  every fidelity axis on every fixture, with face identity collapsing at 0.40
+  (0.14-0.28 cosine vs qwen's 0.80-0.92).
+
+A single-engine `chroma-zimage` default at a flat per-vendor floor is NOT
+supported: Google and Meta floors land too high and the quality at those
+floors is worse than qwen's. But the matched-strength addendum changes what
+IS supported: at the strength each image actually needs, Chroma1 regenerates
+better than qwen almost everywhere except face identity (which the shared
+face stage would supply). The two honest integration options:
+
+1. Per-cohort engine router at flat floors: chroma for OpenAI/Microsoft,
+   qwen for Google/Meta - conservative, ships on the measurements as they
+   stand.
+2. `chroma-zimage` with a content-adaptive strength policy that predicts the
+   per-image rung - potentially better everywhere, but the predictor is new
+   research (the measured signal so far: dense-text content needs the high
+   rungs, photoreal the low ones) and needs its own oracle validation before
+   any ship.
+
+Both need the seed-sensitivity and face-stage composition checks called out
+above before shipping. Both checks have now been run (Pre-ship validation
+above): the Meta boundary is seed-stable across seeds 0-2 and the full
+profile path stays clean through the face stage on the shipped Google floor.
+The profile ships with option 1's floors plus a content-adaptive Google arm
+(face content resolves to 0.125 instead of 0.40, keyed on YuNet detection).
+Option 2's full adaptive policy for the remaining cohorts remains the
+documented follow-up. The Meta arm was measured on 2026-08-30/31 and
+does not have a shippable split; see the expansion section below.
+
+## Meta content-adaptive expansion (2026-08-30/31)
+
+Goal: test whether `flat_ratio` (fraction of 16x16 blocks with luma std < 8)
+predicts Chroma1's first-clean Content Seal boundary well enough to ship a
+Meta arm analogous to Google's face-count split.
+
+**Harvest 1, from a 495-file spaces dump, was not a diverse expansion.**
+Seven "unique" files were staged under `out/cohort-calibration/meta/muse-*`
+(gitignored). After control checks on `meta.ai/identification`:
+
+| fixture | control | first-clean | note |
+|---|---|---|---|
+| muse-1 | CLEAN | -- | seal did not survive the metadata-stripped control |
+| muse-2 | DETECTED | (0.08, 0.10] | photoreal portrait; 0.06 and 0.08 DETECTED, 0.10 CLEAN |
+| muse-3 | DETECTED | (0.015, 0.03] | photoreal portrait, different subject |
+| muse-4 | DETECTED | (0.08, 0.10] | same subject as muse-2/6/7; 0.06 and 0.08 DETECTED, 0.10 CLEAN |
+| muse-5 | -- | -- | byte-identical to committed `gen_lighthouse_watercolor.webp` |
+| muse-6 | DETECTED | (0.06, 0.08] | same subject as muse-4; 0.06 DETECTED, 0.08 CLEAN |
+| muse-7 | DETECTED | (0.045, 0.06] | same subject as muse-2/4/6; 0.045 DETECTED, 0.06 CLEAN |
+
+Five valid new points, four of them near-duplicate portraits of one
+subject, with first-clean already spanning 0.06-0.10 **inside that
+subject**. Google's shipped split had zero overlap between classes and
+identical boundaries inside a class. This harvest cannot support a
+predictor.
+
+`flat_ratio` on the original five plus the new portraits is not monotonic
+with first-clean either (studio_mug 0.973 / 0.045 easy; lighthouse 0.602 /
+0.10 hard; muse-4 0.789 / 0.10 hard). OpenAI stays unshippable for the
+same reason as before: one text fixture vs one face fixture, and the face
+fixture was the harder one, the opposite of Google's split.
+
+**Harvest 2** takes six files from the 2026-08-26 Muse Image API corpus
+(61 independent `muse-image-1.0` generations, no hash overlap with the
+committed five), chosen to span class and `flat_ratio`:
+
+| fixture | class | flat_ratio | edge_density |
+|---|---|---|---|
+| architecture_mosque | dense architecture | 0.037 | 0.367 |
+| product_sneaker | product / high-flat | 0.874 | 0.018 |
+| text_poster_bakery | text | 0.368 | 0.191 |
+| portrait_weathered_fisherman | photoreal portrait | 0.470 | 0.108 |
+| illustration_watercolor_botanical | illustration | 0.442 | 0.089 |
+| scene_tokyo_alley | busy scene | 0.258 | 0.175 |
+
+Script: `scripts/chroma_muse_expansion.py`. Outputs under
+`out/cohort-calibration/meta-api/` (gitignored). Chroma1 ladders (seven
+rungs, seed 0, four effective steps) ran for all six. Oracle
+2026-08-31, anonymous `playwright-isolated` against
+`meta.ai/identification`. All six controls DETECTED (valid carriers).
+
+| fixture | flat_ratio | detected at | clean from |
+|---|---|---|---|
+| architecture_mosque | 0.037 | 0.08 | 0.10 |
+| illustration_watercolor_botanical | 0.442 | 0.08 | 0.10 |
+| scene_tokyo_alley | 0.258 | 0.06 | 0.08 |
+| text_poster_bakery | 0.368 | 0.045 | 0.06 |
+| portrait_weathered_fisherman | 0.470 | 0.045 | 0.06 |
+| product_sneaker | 0.874 | 0.03 | 0.045 |
+
+The worst first-clean is still 0.10, the same as the committed
+lighthouse, so the shipped Meta floor 0.17 does not move.
+
+**No Meta adaptive arm.** Google's shipped split had zero overlap
+between classes and identical first-cleans inside a class. Combined
+with the original five, Meta first-cleans are a continuum from 0.03 to
+0.10, and `flat_ratio` does not separate them:
+
+- the 0.10 cluster is mosque 0.037, botanical 0.442, and lighthouse
+  0.602;
+- the 0.045 cluster is sneaker 0.874 and studio_mug 0.973;
+- harvest-1 photoreal portraits were high-flat (0.75-0.85) AND hard
+  (0.08-0.10), so a high-flat easy-arm would misroute them.
+
+A content-class rule fails the same way: two text posters first-clean
+at 0.03 and 0.06, and two watercolor-like images (lighthouse, botanical)
+share 0.10 with dense architecture.
+
+The leftover rungs were finished in a 2026-08-31 evening UTC
+anonymous isolated session (fresh-navigation, wait for "Upload
+another file"; all ten `POST /api/ai-detector` calls returned 200):
+
+| check | verdict |
+|---|---|
+| muse-2 @ 0.08 | DETECTED |
+| muse-3 @ 0.015 / 0.03 / 0.045 | DETECTED / CLEAN / CLEAN |
+| muse-7 @ 0.045 / 0.06 | DETECTED / CLEAN |
+| mosque @ 0.10 seeds 1, 2 | CLEAN / CLEAN |
+| botanical @ 0.10 seeds 1, 2 | DETECTED / DETECTED |
+
+botanical's seed-0 first-clean of 0.10 is not seed-stable;
+lighthouse @ 0.10 seeds 1 and 2 were CLEAN. That is the same class
+of run-to-run flip the 0.17 floor's margin exists for. No
+Google-style binary split: harvest-1 first-cleans now span 0.03
+(muse-3) through 0.10 (muse-2/4), and 0.06-0.10 inside one subject
+(muse-7 / muse-6 / muse-2).
+
+## OpenAI content-adaptive expansion (2026-08-31)
+
+Goal: test whether face_count or `flat_ratio` predicts Chroma1's OpenAI
+SynthID first-clean the way YuNet does for Google.
+
+Committed three (YuNet + `flat_ratio` on the files, first-cleans from the
+2026-08-29/30 web oracle):
+
+| fixture | faces | flat_ratio | first-clean |
+|---|---|---|---|
+| typography 02_03_55 | 0 | 0.642 | 0.06 |
+| quality 02_02_23 | 0 | 0.695 | 0.06 |
+| 9-face grid 05_30 | 9 | 0.473 | 0.075 |
+
+Face content is the harder of the two classes, the opposite of Google.
+Two zero-face cards share a boundary, which is a hint, not a split.
+
+**Images API is not a carrier source.** `gpt-image-1` and `gpt-image-1.5`
+generations (medium, 1024) carry C2PA (`detected`) but SynthID
+`not_detected` on `POST /v1/content_provenance_checks`. Contrastive-pair
+"openai" recreations are also SynthID-negative. New ChatGPT-UI downloads
+are not in the tree beyond the three committed files.
+
+**Spaces harvest (one day of `_full_scan`, 2026-07-24):** 41 files with
+OpenAI C2PA, of which 7 checked by the provenance API were SynthID
+`DETECTED` (one `NOT_DETECTED`). Four diverse DETECTED files were staged
+under `out/cohort-calibration/openai-expand/` (gitignored; user uploads,
+not committed) and given a Chroma1 ladder (0.04-0.12, seed 0) by
+`scripts/chroma_openai_expansion.py`:
+
+| id | faces | flat_ratio |
+|---|---|---|
+| dense_ed68 | 0 | 0.118 |
+| midflat_038c | 0 | 0.323 |
+| textlike_3b17 | 0 | 0.649 |
+| faces2_4dab | 2 | 0.279 |
+
+The provenance API then 429'd. The same checks were finished on
+`https://openai.com/research/verify/` (the page reports SynthID and C2PA
+separately under View details). Chroma PNG outputs have no C2PA, so a
+"No OpenAI signals detected" heading is a pixel-SynthID negative.
+
+| id | faces | @0.04 | @0.05 | @0.06 |
+|---|---|---|---|---|
+| dense_ed68 | 0 | CLEAN | CLEAN | CLEAN |
+| midflat_038c | 0 | -- | -- | CLEAN |
+| textlike_3b17 | 0 | -- | -- | CLEAN |
+| faces2_4dab | 2 | -- | -- | CLEAN |
+
+9-face grid @ 0.075, seeds 1 and 2: both CLEAN (SynthID not detected).
+The committed seed-0 first-clean is not a fluke.
+
+**No OpenAI adaptive arm.** Zero-face extras clear at or below 0.06, the
+2-face extra also clears at 0.06, and only the 9-face grid needs 0.075.
+That is not a YuNet split: `face_count > 0` would over-strengthen the
+2-face file, and a high face-count cutoff would be one fixture. The
+spread (0.075 - 0.06) is already absorbed by the shipped 0.09 floor.
+Images API generations remain non-carriers (C2PA only).
+
+## Content-balanced engine selection check (2026-08-31)
+
+The earlier tables were intentionally carrier-focused and therefore small. A
+separate discovery pass tested whether ordinary image content contradicts the
+cohort choice at the shipped floors. The tracked matrix contains 19 prompts,
+matched across OpenAI `gpt-image-1-mini` and Meta `muse-image-1.0`, spanning
+photoreal scenes, faces, action, text-like flat art, products, architecture,
+watercolor, and surreal illustration. These files were re-encoded by collection
+and are not signal carriers, so this pass measures fidelity only; removal remains
+established by the provider-oracle calibration above.
+
+Qwen and Chroma ran in separate sequential H100 invocations, once per source,
+with the production provider floor and fixed seed. The comparison isolated the
+global stage because both profiles inherit the same source-based Z-Image face
+repair. Per-image differences, rather than differences between aggregate means,
+were evaluated with exact two-sided sign tests:
+
+| provider | metric | Chroma wins | Qwen wins | two-sided p |
+|---|---|---:|---:|---:|
+| OpenAI | SSIM | 19 | 0 | 0.0000038 |
+| OpenAI | PSNR | 19 | 0 | 0.0000038 |
+| OpenAI | MAE | 18 | 1 | 0.000076 |
+| OpenAI | edge F1 | 15 | 4 | 0.019 |
+| OpenAI | LPIPS | 12 | 7 | 0.359 |
+| Meta | LPIPS | 1 | 18 | 0.000076 |
+| Meta | edge F1 | 1 | 18 | 0.000076 |
+| Meta | SSIM | 5 | 14 | 0.064 |
+
+Meta's remaining pixel metrics disagree: Chroma wins PSNR on 16/19 and MAE on
+14/19, while losing both perceptual distance and edge preservation on 18/19 at
+its higher removal floor. This is not evidence for a genre classifier. The
+direction instead follows the already measured provenance cohort: Chroma for
+OpenAI, Qwen for Meta. On OpenAI, the seven LPIPS exceptions include unrelated
+classes (landscape, sport, low-light interior, watercolor, monochrome portrait,
+surreal art, and brutalism), while Chroma still wins SSIM and PSNR on every one;
+there is no coherent input feature that justifies overriding the cohort choice.
+
+Inputs and integrity manifests are under
+`data/evaluations/engine-selection/`. Raw generated outputs remain gitignored
+under `out/engine-selection-study/`; `scripts/engine_selection_study.py`
+reproduces the run and `scripts/analyze_engine_selection_study.py` reproduces
+the paired statistics. One generation per prompt is a discovery set, not a
+license to fit thresholds. Any future content override must first predict a
+rule here and then survive unused generation indices without changing it.
+
+## Oracle session notes
+
+- openai.com/verify throttles anonymous sessions through Cloudflare Turnstile
+  after ~15 rapid checks; a fresh browser context clears it. The programmatic
+  `POST /v1/content_provenance_checks` API is the better oracle (separate
+  SynthID/C2PA outcomes). The `OPENAI_API_KEY` in the main-checkout `.env`
+  returned 401 org-wide, including `/v1/models`, through the 2026-08-30
+  calibration; it was replaced on 2026-08-31 and both `/v1/models` and
+  a provenance check on a committed ChatGPT original then succeeded
+  (DETECTED).
+- meta.ai/identification enforces a sliding per-IP window: a burst of ~15
+  checks exhausted it twice; it reopens minutes later, and the page sometimes
+  overstates this as a daily limit. Pacing of roughly 2-3 checks per window
+  worked. On 2026-08-31 an anonymous isolated session got a real 429 from
+  `POST /api/ai-detector` with page text "You’ve reached the daily limit
+  for identifications. Try again tomorrow" after about six checks in the
+  UTC morning and again after about fifteen in the UTC afternoon, so the
+  daily-limit wording is not always overstated; the afternoon window was
+  large enough to finish harvest 2. An evening isolated session the same
+  day got ten 200s and finished the leftover harvest-1 rungs plus the
+  mosque/botanical seed probes.
+- The Gemini app oracle requires the user's logged-in session. A human
+  drag-drop of a local PNG works on Work Gemini (u/2, 2026-08-31) and on
+  Plus (u/0 the same day); Playwright cannot drive the OS picker, and
+  the first `input[type=file].accept` is documents/code only. Plus
+  `@synthid` hung once after attach, then returned a tool CLEAN on a
+  second human-drag chat. Do not drive the live Chrome while it is in
+  active use (wrong-tab risk).

docs/cli.md

@@ -14,6 +14,8 @@ defaults. This page focuses on choosing the right command.
 | Command or signal | Required installation |
 | --- | --- |
 | `metadata` and metadata-only `identify` | Default package |
+| `classify` | `remove-ai-watermarks[classify]` |
+| `verify-openai-synthid` | `remove-ai-watermarks[verify]`, API access, and `OPENAI_API_KEY` |
 | Visible signals in `identify` | `remove-ai-watermarks[visible]` (`pixels` is the minimal runtime) |
 | Open DWT-DCT signals in `identify` | `remove-ai-watermarks[detect]` |
 | Adobe TrustMark signals in `identify` on Python 3.11-3.12 | `remove-ai-watermarks[trustmark]` |
@@ -41,9 +43,14 @@ remove-ai-watermarks identify image.png
 it also evaluates supported visible and invisible pixel signals. When no signal
 is found, it reports the origin as unknown. It does not claim the image is
 clean. For C2PA files, the text report shows asset integrity, claim-signature,
-signer-trust, and signer-validity results separately. An intact claim from an
-untrusted or expired signer is reported at medium confidence; a failed asset
-binding or signature does not confirm the claimed origin.
+signer-trust, and signer-validity results separately. Confidence follows the
+binding: an intact asset binding and claim signature is high confidence, and an
+unanchored or expired signer is reported as a caveat rather than a lower score,
+because no trust anchor list ships with the reader. A failed asset binding or
+signature, or a revoked signing credential, does not confirm the claimed origin. When a structured
+C2PA soft binding is present, the report also names its exact algorithm and
+signed value; removing the manifest does not remove the referenced pixel
+watermark or content fingerprint.
 
 Machine readable output:
 
@@ -57,8 +64,76 @@ Metadata only inspection:
 remove-ai-watermarks identify image.png --no-visible
 ```
 
-Despite the historical option name, `--no-visible` skips both visible and open
-invisible pixel detectors. Metadata inspection still runs.
+Despite the historical option name, `--no-visible` skips all pixel detectors,
+including visible marks, open DWT-DCT, and TrustMark. Metadata inspection still
+runs.
+
+## Verify OpenAI SynthID from pixels
+
+```bash
+uv tool install --force "remove-ai-watermarks[verify]"
+remove-ai-watermarks verify-openai-synthid image.png --acknowledge-upload
+remove-ai-watermarks verify-openai-synthid image.png --acknowledge-upload --json
+```
+
+This is an explicit remote check against OpenAI's official Content Provenance
+API, not the incomplete local OpenAI carrier research model. Before upload, the
+command writes a temporary copy with AI provenance metadata removed and aborts
+unless the decoded RGBA pixels are identical to the source. It then reads only
+the API's independent `synthid` entry; a C2PA-only response cannot become a
+SynthID detection. The source is never modified.
+
+The API supports PNG, JPEG, and WebP files up to 50 MiB. The command requires
+`OPENAI_API_KEY` and an organization with endpoint access. Because the sanitized
+raster is uploaded to OpenAI and the endpoint is not eligible for Zero Data
+Retention, `--acknowledge-upload` is mandatory. This command is never called by
+`identify`. `not_detected` means only that OpenAI's verifier did not recognize a
+supported watermark in this file; it is not proof of human authorship.
+
+The built-in client bounds the request at 120 seconds and disables automatic
+SDK retries, so one acknowledgement cannot silently upload the media multiple
+times. A timeout, disconnect, malformed response, access failure, or rate limit
+is an error, never a negative watermark verdict. API failures expose status,
+error code, request id, `Retry-After`, and whether an explicit caller-controlled
+retry is appropriate through `OpenAIProvenanceError`; the verifier itself never
+retries an upload.
+The JSON result uses the same provider-scope, backend, pixel-preservation, and
+metadata-use audit fields as `verify_openai_synthid`.
+
+The Python API enforces the same boundary with the required explicit intent
+flag `verify_openai_synthid(path, acknowledge_upload=True)`.
+
+## Classify a photograph from pixels
+
+This is not provenance. `identify` never starts it, including after a
+no-signal metadata scan. Install the extra first:
+
+```bash
+uv tool install --force "remove-ai-watermarks[classify]"
+```
+
+Then:
+
+```bash
+remove-ai-watermarks classify image.png
+remove-ai-watermarks classify image.png --json
+```
+
+The command runs the frozen photo detector (CLIP-L-ft ridge AND freeze MLP).
+Only a DEFINITELY result is reported as `ai`. On that result only, the 124-d
+provider head may return `openai`, `google`, `muse-image`, or `tc260`. POSSIBLY is
+`unknown`. Camera-like photographs are `human`. The call does not run cleanup
+and does not set `is_ai_generated`.
+
+The contract is AI versus camera. Receipts, UI, and digital art are out of
+scope. Microsoft is not a pixel class: a DALL-E Bing image scores as `openai`,
+an Imagen Designer image as `google`. `tc260` is the China AIGC label
+standard, not one producer. Weights download on first use from
+[`wiltodelta/raiw-photo-classify`](https://huggingface.co/wiltodelta/raiw-photo-classify),
+or from `RAIW_CLASSIFY_WEIGHTS` if that directory already holds the freeze
+files.
+Guide: [photo pixel classification](photo-classify.md). Hub card:
+[photo-classify-hf/README.md](photo-classify-hf/README.md).
 
 ## Remove known visible marks
 
@@ -100,6 +175,18 @@ Use the strict visual gate without metadata or sibling corroboration:
 remove-ai-watermarks visible image.png --sensitivity strict -o clean.png
 ```
 
+Act on a mark you can see but the detector will not confirm, by naming it and
+skipping the gate:
+
+```bash
+remove-ai-watermarks visible image.png --mark gemini --no-detect -o clean.png
+```
+
+`--detect` is the default. `--no-detect` removes the named mark's footprint
+unconditionally, so it only makes sense together with an explicit `--mark`; on
+an image that never carried that mark it inpaints a region for nothing. Prefer
+`erase --region` when you know the geometry.
+
 When no known mark is detected, the command does not write a new output. Use
 `erase` if you can identify the affected region yourself.
 
@@ -312,7 +399,7 @@ remove-ai-watermarks video visible kling.mp4 --mark kling -o kling_clean.mp4
 
 The command supports the moving Sora mascot and wordmark, two Veo
 corner variants, the Seedance boxed `AI` label, the `Dola AI` text label, the
-composite `MINIMAX | hailuo AI` label, and the bottom-right Kling label. Sora
+composite `MINIMAX | hailuo AI` label, and the bottom-right Kling AI label. Sora
 searches the whole frame at multiple scales. The other detectors search bounded
 lower-frame regions with separate synthetic silhouettes. Kling additionally
 requires its bright low-saturation label near the frame edge. Every mark
@@ -322,8 +409,8 @@ provider provenance may relax the visual score only for registered
 provenance-aware marks; metadata alone never creates a detection.
 
 `--mark auto` is the default. It evaluates all providers in one decode pass and
-selects the first stable match in specificity order: Sora, Veo, Seedance, Dola,
-Hailuo, then Kling. Their confidence scores are independently calibrated and
+selects the first stable match in specificity order: Sora, Veo, Seedance,
+Doubao, Dola, Hailuo AI, then Kling AI. Their confidence scores are independently calibrated and
 are not compared across providers. Pass an explicit `--mark` to scan only that
 provider.
 
@@ -362,7 +449,7 @@ failed encode does not overwrite an existing result.
 
 ## Remove invisible watermarks
 
-Install the removal dependencies first. Both profiles are CUDA-only and both
+Install the removal dependencies first. All profiles are CUDA-only and all
 run the DiffSynth Z-Image face stage, so this is the extra either one needs:
 
 ```bash
@@ -382,14 +469,33 @@ detected. Use `--force` when you know the image should be processed:
 remove-ai-watermarks invisible image.png -o clean.png --force
 ```
 
+### Choose a strength cohort
+
+`--vendor` selects the cohort the default strength resolves from. `auto`
+(the default) derives it from provenance: the C2PA issuer for
+OpenAI/Google/Microsoft, and the standalone AI IPTC tag for Meta Content Seal
+(Muse output carries no C2PA; the tag is a standard code, so C2PA evidence
+always wins first). An explicit value both names the cohort for stripped files
+and implies the scrub runs -- naming the cohort asserts the pixel watermark is
+present -- exactly like `--force` plus a measured floor:
+
+```bash
+remove-ai-watermarks invisible muse_output.webp -o clean.png --vendor meta
+```
+
+The same option exists on `all` and `batch`, and as
+`InvisibleOptions(vendor="meta")` in the Python API.
+
 ### Choose a pipeline
 
 | Pipeline | When to use it |
 | --- | --- |
 | `qwen-zimage` | Default. Qwen-Image-2512 global pass plus a SAM-masked Z-Image face stage |
 | `sdxl-zimage` | The same recipe and face stage on an SDXL global pass, at a higher denoise |
+| `chroma-zimage` | The same face stage on an Apache-2.0 Chroma1 global pass, with lower OpenAI and Microsoft floors and higher Google and Meta floors |
+| `auto` | Pick the engine from provenance: chroma-zimage for OpenAI and Microsoft, qwen-zimage for Google, Meta, and unknown |
 
-**Both are CUDA-only.** There is no CPU or MPS profile for invisible-watermark
+**All four are CUDA-only.** There is no CPU or MPS profile for invisible-watermark
 removal. The former `controlnet`, `sdxl`, `qwen` and `default` profiles were removed
 rather than kept as a CPU path: none of them matched this recipe's face preservation,
 so offering them implied a quality the library no longer delivers. Passing a retired
@@ -412,17 +518,18 @@ user can act on rather than after a model load.
 ### Restore operator-verified text
 
 `--text-manifest` enables the experimental `vae-glyphs` post-pass. It reconstructs
-the source with the Qwen VAE, blends 15% of that reconstruction into the normal
-`qwen-zimage` result, erases the annotated candidate glyphs with LaMa, and composites
-only the reconstructed glyph cores through source-derived silhouettes. It does not
-run OCR or choose which strings are correct.
+the source with the selected profile's VAE, erases the annotated candidate glyphs
+with LaMa, and composites only the reconstructed glyph cores through source-derived
+silhouettes. It does not run OCR or choose which strings are correct. The optional
+Qwen-only `--fidelity-anchor` described below additionally blends 15% of the
+reconstruction across the full frame.
 
 Install the combined extra and run only with an operator-verified manifest:
 
 ```bash
 uv tool install --force "remove-ai-watermarks[text-restoration]"
 remove-ai-watermarks invisible image.png -o clean.png \
-  --pipeline qwen-zimage --text-manifest verified-lines.json --force
+  --pipeline auto --text-manifest verified-lines.json --force
 ```
 
 ``verified: true`` may also be set by an automated operator that attests
@@ -430,7 +537,8 @@ machine-verified geometry: stability-gated detector boxes inside sane caps. Such
 operators should use the geometry-only schema 2, which carries no transcription
 or script metadata.
 
-Since 0.27.1 the global 15% Qwen-VAE fidelity-anchor blend is off by default: it
+Since 0.27.1 the global 15% Qwen-VAE fidelity-anchor blend is off by default and
+remains available only with `qwen-zimage`: it
 was measured to return detector-visible OpenAI SynthID on poster-scale manifests
 (official Content Provenance API, 2026-08-19). `--fidelity-anchor` restores the
 0.27.0 research behavior; text-box fidelity lost by the default is well under one
@@ -447,8 +555,9 @@ container changes remain valid while a resized or edited source fails closed. Th
 experimental helper
 `remove_ai_watermarks._internal.text_restoration.source_pixel_sha256` computes it.
 
-This mode is supported only by `qwen-zimage` at native geometry with
-`humanize=0`, `unsharp=0`, and adaptive polish disabled. `all` also accepts the flag,
+This mode is supported by `qwen-zimage`, `chroma-zimage`, and `auto` at native
+geometry with `humanize=0`, `unsharp=0`, and adaptive polish disabled. The legacy
+`sdxl-zimage` profile does not expose a verified-text VAE donor. `all` also accepts the flag,
 but its manifest must match the pixels entering the invisible stage; if visible-mark
 removal changes those pixels, the hash check rejects the run. One oracle verdict does
 not certify another manifest, seed, model/runtime version, or output hash.
@@ -478,7 +587,33 @@ remove-ai-watermarks invisible image.png -o clean.png \
 ```
 
 Tiling avoids the explicit downscale but each tile is regenerated separately.
-It is a memory strategy, not a guarantee of better quality.
+It is a memory strategy, not a guarantee of better quality. `--tile-size` and
+`--tile-overlap` set the tile geometry (defaults 1024 and 128 px); a larger
+overlap costs time and hides seams.
+
+### Every tuning option
+
+These apply to `invisible`, `all`, and `batch`. Each has a measured default, so
+reach for one only when you know why the default is wrong for your file.
+
+| Option | Effect |
+| --- | --- |
+| `--strength` | Denoising strength, 0.0-1.0. Default is profile- and vendor-adaptive; see [choose a strength cohort](#choose-a-strength-cohort). Raising it removes more and drifts further from the original. |
+| `--vendor` | Strength cohort, and an assertion that the watermark is present. |
+| `--pipeline` | Profile: `qwen-zimage` (default), `sdxl-zimage`, `chroma-zimage`, `auto`. |
+| `--seed` | Fixed at 0 by default: every profile is certified at that seed, and removal near the floor is seed-dependent. |
+| `--controlnet-scale` | Canny ControlNet conditioning on the global stage. Higher keeps the original structure and text closer. |
+| `--humanize` | Analog film grain, 0 = off, typical 2.0-6.0. |
+| `--unsharp` | Unsharp-mask sharpening, 0 = off. |
+| `--adaptive-polish` / `--no-adaptive-polish` | Overrides the profile's own choice. Unset lets the profile decide: off for `qwen-zimage`, whose output already matches the input's detail level, on for `sdxl-zimage`. |
+| `--max-resolution` | Cap the long side before diffusion; 0 = native. |
+| `--tile`, `--tile-size`, `--tile-overlap` | Tiled regeneration for large inputs, as above. |
+| `--cpu-offload` | Stream model components between CPU and GPU to lower CUDA memory pressure, at the cost of speed. |
+| `--hf-token` | Hugging Face token for the model download; also read from the environment and a local `.env`. |
+
+There is no `--model`, `--steps`, `--guidance-scale` or `--device` option; the
+profile pins all four. See [exit behavior](#exit-behavior) for what each command
+returns.
 
 ## Run the full pipeline
 

docs/controlnet-removal-pipeline-research.md

@@ -79,8 +79,9 @@ enough yet barely touches flat fills. So the survivors FLIP by content type —
 choice alone does not guarantee removal.
 
 **2. Seed non-determinism near threshold.** img2img uses a random seed unless `--seed`
-is passed, and there is no local SynthID detector to self-verify. The bracelet survived
-controlnet @0.15 in one run and CLEARED @0.15 in another (same pipeline+strength+res).
+is passed, and these geometries are outside the current local detector's scope.
+The bracelet survived controlnet @0.15 in one run and CLEARED @0.15 in another
+(same pipeline+strength+res).
 So a single clean run does NOT establish a strength as safe — characterizing a reliable
 floor needs a seed-repeatability sweep (N runs, varied seed), not one pass.
 
@@ -144,8 +145,8 @@ Gemini app; the two payloads are vendor-specific and never cross-checked):
   but never recovered original identity precisely — every setting traded one problem
   for another. See `docs/synthid-robust-identity-research-2026-06-08.md`
   "Empirical follow-up" for the full sweep.
-- **No local SynthID detector exists** → the service can't self-verify; bake in strength
-  margin and periodic oracle spot-checks.
+- **No applicable local detector exists for these geometries** → the service
+  can't self-verify; bake in strength margin and periodic oracle spot-checks.
 - **Lesson:** visual-quality / face-identity recovery does NOT prove removal — only the
   oracle does, across MULTIPLE content types; never conclude from a partial result (the
   photoreal-only data first read as "controlnet shields, default removes"; the flat-graphic
@@ -298,8 +299,9 @@ attention-slicing; ~1-2 min/image, so a coarse sweep is a sub-hour background ru
 is needed ONLY for the separate
 native-large-Gemini (2816 px) case, which OOMs even without a ControlNet (that requires a
 GPU task). The genuine external dependency is NOT compute but the **manual SynthID oracle**:
-there is no local SynthID detector, so removal is verified by hand in the Gemini app
-("Verify with SynthID") per image, regardless of where the diffusion runs.
+these geometries are outside the current local detector's scope, so removal is
+verified by hand in the Gemini app ("Verify with SynthID") per image, regardless
+of where the diffusion runs.
 
 Runner: **`scripts/controlnet_sweep.py`** (built 2026-06-02) implements exactly this sweep —
 SDXL base 1.0 + an SDXL-native ControlNet img2img, one output per (control x strength x scale)
@@ -441,8 +443,9 @@ shielding risk; defer to a v2 after the single-canny path is dialed in.
 
 **Hard caveat:** every change that increases preservation (higher scale, denser canny, fuller window,
 softer edges) marginally REDUCES effective regeneration and so raises the chance the watermark
-survives -- exactly the shielding failure mode. There is no local SynthID detector, so each tuning
-change must be re-confirmed on the oracle. These are img2img-context recommendations derived from
+survives -- exactly the shielding failure mode. These geometries are outside the
+current local detector's scope, so each tuning change must be re-confirmed on
+the oracle. These are img2img-context recommendations derived from
 generation-context sources plus our own measurements; treat the playbook as hypotheses to verify, not
 settled defaults.
 
@@ -521,7 +524,7 @@ held by its masked ArcFace vector -- no original pixel copied.
   drift, NOT a perfect face swap. Set expectations; PuLID/InstantID are the higher-fidelity (heavier)
   paths if needed.
 - **Value scales with strength:** at low strength (OpenAI 0.10) faces barely drift, so FaceID is
-  marginal; at the higher strength a hard vendor (Google 0.30) needs, FaceID earns its keep.
+  marginal; at the higher strength then used for a hard vendor (Google 0.30), FaceID earned its keep.
 
 ### Build plan (staged)
 
@@ -641,7 +644,7 @@ photo only).
 
 **Sources.** https://arxiv.org/abs/2206.11253 (CodeFormer) · https://github.com/sczhou/CodeFormer ·
 https://arxiv.org/pdf/2401.07519 (InstantID) ·
-https://openaccess.thecvf.com/content/WACV2024/papers/Suin_Diffuse_and_Restore... (region-adaptive) ·
+https://openaccess.thecvf.com/content/WACV2024/html/Suin_Diffuse_and_Restore_A_Region-Adaptive_Diffusion_Model_for_Identity-Preserving_Blind_WACV_2024_paper.html (region-adaptive) ·
 https://arxiv.org/pdf/2504.12809 (saliency-aware watermark removal)
 
 ## Provenance

docs/development.md

@@ -1,5 +1,9 @@
 # Development
 
+Standalone evaluation, calibration, and release utilities are catalogued in
+[`scripts/README.md`](../scripts/README.md). They are maintainer tools rather than
+installed commands, and their local data inputs remain outside the repository.
+
 Read this reference for environment setup, dependency recovery, CI behavior, and fixture policy. The always-loaded invariants remain in [`.claude/rules/development.md`](../.claude/rules/development.md).
 
 ## Local environment

docs/index.md

@@ -12,6 +12,8 @@ to run the tool. Use the maintainer references only when changing the code.
 | [Python API](python-api.md) | You want to call the package from Python. |
 | [Supported signals](supported-signals.md) | You need to know which visible marks, metadata formats, and invisible signals are covered. |
 | [Known limitations](known-limitations.md) | You need the quality, device, format, or verification boundaries. |
+| [Photo pixel classification](photo-classify.md) | You want `classify` / `classify_pixels`: AI versus camera, optional provider. |
+| [Photo classifier training](photo-classify-training.md) | You need the retrain pack, public sources, and what is not published. |
 | [Scope, safety, and legal notes](legal-and-safety.md) | You need the intended use and legal context. |
 
 ## Maintainer references
@@ -22,9 +24,9 @@ to run the tool. Use the maintainer references only when changing the code.
 | [Development](development.md) | Environment setup, dependency recovery, CI behavior, and fixture policy. |
 | [Code provenance](code-provenance.md) | Required notices for licensed derivative work. |
 | [Verification plan](verification-plan.md) | Verification methods, completed measurements, and remaining validation gaps. |
-| [Release and distribution](release-and-distribution.md) | PyPI, Homebrew, Hugging Face Space, ComfyUI Registry, and the release workflow. |
+| [Release and distribution](release-and-distribution.md) | PyPI, Homebrew, Hugging Face Space, photo-classify Hub model, ComfyUI Registry, and the release workflow. |
 | [Watermarking landscape](watermarking-landscape.md) | Vendor signals and detection approaches. |
-| [SynthID technical reference](synthid.md) | Mechanism, detector access, robustness, and implications for this project. |
+| [SynthID technical reference](synthid.md) | Mechanism, provenance, robustness, regeneration. |
 
 ## Research archive
 
@@ -35,7 +37,15 @@ The current behavior is defined by the code, tests, README, and user guides.
 - [ControlNet removal research](controlnet-removal-pipeline-research.md)
 - [Qwen improvement research](qwen-improvement-research.md)
 - [Doubao reverse-alpha research](research-doubao-distillation.md)
+- [AI-generated image classifiers](ai-generated-image-classifiers.md) (photo AI-versus-camera freeze consumed by `classify_pixels`, not `identify`)
+- [Photo classifier Hugging Face card](photo-classify-hf/README.md) (Hub publication text of the 2026-08-31 freeze)
+- [SynthID source classifiers](synthid-classifiers.md) (metadata-free OpenAI/Gemini source finding and provider-lineage experiments)
+- [SynthID local detector research](synthid-detector-research.md)
+- [SynthID mark removal research](synthid-removal-research.md)
 - [SynthID identity research](synthid-robust-identity-research.md)
 - [SynthID identity follow-up](synthid-robust-identity-research-2026-06-08.md)
 - [Video SynthID quality research](video-synthid-quality-research.md)
+- [OpenAI SynthID oracle ladders](synthid-oracle-ladders.md) (routing hub)
+- [SynthID detector and removal plan](synthid-detector-removal-plan.md) (chronological mixed archive)
 - [Text protection research](text-protection-research.md)
+- [Chroma1 engine research](chroma1-engine-research.md)

docs/installation.md

@@ -75,11 +75,16 @@ uv tool install --force "remove-ai-watermarks[qwen-zimage]"
 ```
 
 Both remaining profiles run a Z-Image face stage on the DiffSynth runtime, so
-both need this extra. It includes the `diffusion` dependencies; `diffusion` on its
-own covers the torch and diffusers imports but not the face stage, so it is not
-enough to run a removal.
+both need this extra. The third profile, `chroma-zimage`, uses diffusers'
+ChromaImg2ImgPipeline instead of DiffSynth for its global stage but inherits
+the same face stage, so it needs this extra too. The extra also installs
+SentencePiece for Chroma1-HD's binary `spiece.model`; without that backend,
+Transformers cannot construct the Chroma tokenizer. It includes the `diffusion`
+dependencies; `diffusion` on its own covers the torch and diffusers imports but
+not the face stage or Chroma tokenizer, so it is not enough to run a removal.
 
-**An NVIDIA GPU is required.** `qwen-zimage` and `sdxl-zimage` are CUDA-only, and
+**An NVIDIA GPU is required.** `qwen-zimage`, `sdxl-zimage` and `chroma-zimage`
+are CUDA-only, and
 construction refuses any other device rather than falling back to a slow or broken
 one. There is no CPU, MPS or XPU path for invisible-watermark removal. Visible-mark
 removal, metadata stripping and every `identify` command still run anywhere.
@@ -103,17 +108,20 @@ application actually uses:
 
 | Extra | Capability | Automatically includes | Torch or model download |
 | --- | --- | --- | --- |
-| `pixels` | Shared BGR array and image-processing runtime | NumPy, headless OpenCV | No |
+| `pixels` | Shared BGR runtime and calibrated-size SynthID carrier detection | NumPy, headless OpenCV | No |
 | `heif` | HEIC, HEIF, and AVIF pixel decoding | pillow-heif | No |
 | `visible` | Visible mark detection, OpenCV inpainting, and manual erasing | `pixels` | No |
 | `video` | Visible video identification/removal and timestamp preservation | `visible`, PyAV | No |
 | `detect` | Open DWT-DCT detection for Stable Diffusion, SDXL, and FLUX | `pixels`, PyWavelets | No |
 | `trustmark` | Adobe TrustMark detection on Python 3.11-3.12 | trustmark | Yes |
+| `classify` | Metadata-free photo AI-versus-camera classifier plus gated provider | `pixels`, Torch, Transformers | Yes |
+| `verify` | Official remote OpenAI SynthID verification | OpenAI SDK | No |
 | `diffusion` | Torch and Diffusers runtime; video SynthID regeneration | `pixels`, Torch, Diffusers | Yes |
 | `migan` | MI-GAN ONNX fill backend | `visible`, ONNX Runtime | Model download, no Torch |
 | `lama` | big-LaMa ONNX fill backend | `visible`, ONNX Runtime | Model download, no Torch |
-| `qwen-zimage` | Invisible image-watermark removal, both CUDA-only profiles | `diffusion`, DiffSynth | Yes |
-| `text-restoration` | Opt-in verified Qwen-VAE glyph restoration | `qwen-zimage`, `lama` | Yes |
+| `qwen-zimage` | Invisible image-watermark removal, all CUDA-only profiles | `diffusion`, DiffSynth, SentencePiece | Yes |
+| `text-restoration` | Opt-in verified profile-VAE glyph restoration | `qwen-zimage`, `lama` | Yes |
+| `text-draft` | Draft OCR proposals for operator verification | PaddleOCR, PaddlePaddle | Model download, no Torch |
 | `all` | Every production feature available on the active Python | All compatible rows above | Yes |
 | `dev` | Tests, linting, typing, and upstream parity checks | `video`, `detect`, upstream invisible-watermark | Yes, for parity tests |
 
@@ -130,12 +138,17 @@ flowchart LR
     qwen["qwen-zimage"] --> diffusion
     text["text-restoration"] --> qwen
     text --> lama
+    draft["text-draft"]
     heif
     trustmark
+    classify --> pixels
+    verify
 ```
 
-`heif` and `trustmark` are independent branches. Combine them explicitly with
-another feature when required. TrustMark requires NumPy 1.x, which has no
+`heif`, `trustmark`, `verify`, and `text-draft` are independent branches. Combine them
+explicitly with another feature when required. `text-draft` is excluded from
+`all` because it proposes unverified OCR annotations and is not a production
+removal path. TrustMark requires NumPy 1.x, which has no
 CPython 3.13 or 3.14 wheels, so that branch is available only on Python
 3.11-3.12. The `all` bundle contains every production branch compatible with
 the active Python and never includes `dev`.
@@ -155,6 +168,9 @@ uv tool install --force "remove-ai-watermarks[video]"
 # DWT-DCT and TrustMark detection without diffusion removal
 uv tool install --force "remove-ai-watermarks[detect,trustmark]"
 
+# Official OpenAI SynthID verification
+uv tool install --force "remove-ai-watermarks[verify]"
+
 # Every production capability compatible with this Python
 uv tool install --force "remove-ai-watermarks[all]"
 
@@ -167,6 +183,13 @@ do not install libheif. `detect` uses the in-tree torch-free decoder and does
 not install the upstream `invisible-watermark` package. Optional models download
 their weights on first use.
 
+The `verify` extra makes an explicit remote request. The
+`verify-openai-synthid` command first removes AI provenance metadata from a
+temporary copy, checks that its decoded pixels are unchanged, and then uploads
+that copy to OpenAI. It needs `OPENAI_API_KEY`; the command never runs from
+`identify` and refuses to upload without `--acknowledge-upload`. The Python API
+requires the equivalent explicit `acknowledge_upload=True` argument.
+
 The old `gpu` and `remove` aliases are intentionally not provided. Use
 `diffusion` and `visible` respectively.
 
@@ -237,5 +260,5 @@ image came from a relevant generator, use `--force`.
 
 If the CLI reports that the removal dependencies are unavailable, install the
 `qwen-zimage` extra. `diffusion` alone covers Torch and Diffusers but not the
-DiffSynth face stage that both profiles run. Video SynthID removal is a separate
+DiffSynth face stage that all profiles run. Video SynthID removal is a separate
 path and needs `video` and `diffusion`.

docs/known-limitations.md

@@ -4,6 +4,18 @@ This page describes current product limits. Historical measurements and
 superseded experiments live in the research archive listed in
 [the documentation index](index.md).
 
+## Pixel classification
+
+`classify` / `classify_pixels` is AI versus camera, not a universal AI detector.
+Receipts, UI screenshots, and digital art are out of contract: a thermal receipt
+can score as AI, a photorealistic AI receipt as human. POSSIBLY is reported as
+`unknown`. Provider attribution runs only after DEFINITELY and can abstain when
+124-d extraction refuses the file. Microsoft is not a pixel class.
+
+The command is never started by `identify`. A no-signal provenance result stays
+unknown. This is not a clean verdict and it does not run cleanup. Full guide:
+[photo pixel classification](photo-classify.md).
+
 ## Visible removal
 
 ### Fill quality depends on the background
@@ -31,11 +43,14 @@ an unsupported locale, a different position, or a crop may be missed.
 
 Known examples:
 
+- The Microsoft detector covers one calibrated top-right white pill. Microsoft's
+  [documented feature](https://support.microsoft.com/en-us/topic/include-a-watermark-when-content-from-microsoft-365-is-ai-generated-b00a656e-ae61-4692-8086-67d004421030)
+  can instead use a Copilot icon, `AI-Generated` text, or another position.
 - Samsung detection is calibrated for the Italian
   `Contenuti generati dall'AI` text variant.
 - The Jimeng top-left pill has a weak visual detector and is intentionally
   subject to additional product and background checks.
-- Kling support covers the calibrated variants rather than every Kling label.
+- Kling AI support covers the calibrated variants rather than every Kling AI label.
 
 Use `erase --region` when you can see and select an unsupported or missed mark.
 
@@ -70,10 +85,12 @@ as SynthID lives in the pixels everywhere, including inside the glyphs, so
 frozen text regions would keep the watermark
 ([text protection research](text-protection-research.md)).
 
-`qwen-zimage` is the default profile and `sdxl-zimage` the only alternative.
-Both are CUDA only and differ only in the global regeneration model: each
-conditions that stage on a canny edge map, which preserves structure but not
-identity or exact texture, and each then runs the same face stage.
+`qwen-zimage` is the default profile. `sdxl-zimage` and `chroma-zimage` keep
+the same face stage and swap the global model. `auto` picks chroma-zimage for
+OpenAI and Microsoft provenance and qwen-zimage otherwise. All are CUDA only.
+Qwen and SDXL condition the global stage on a canny edge map, which preserves
+structure but not identity or exact texture. Chroma1 is a plain strength pass
+without Canny.
 Existing face evaluations favor `qwen-zimage`, but there is no blanket fidelity
 ordering across content types. A fixed-seed, three-scene text comparison at the
 profile defaults found no stable winner: SDXL won one poster, Qwen won one, and
@@ -94,12 +111,14 @@ rates are kept in
 [`text-protection-research.md`](text-protection-research.md) and the
 [`fidelity` evaluation record](../data/evaluations/fidelity/README.md).
 
-### Removal cannot be verified locally for proprietary SynthID
+### There is no local SynthID pixel detector in the package
 
-The project has no public local SynthID pixel decoder. It recognizes presence
-from supported provenance metadata: Google AI C2PA under Google's all-media
-policy, or current OpenAI C2PA with an explicit watermark action. A missing
-provenance signal is not a negative pixel verdict.
+Google does not publish the proprietary SynthID payload decoder, and the
+package does not ship one. Signed provenance is the supported route:
+Google AI C2PA or current OpenAI C2PA with an explicit watermark action.
+`verify-openai-synthid` is the official remote pixel check for OpenAI.
+Research on a periodic lattice expert is in
+[synthid-detector-research.md](synthid-detector-research.md).
 
 For important outputs:
 
@@ -111,6 +130,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
@@ -174,16 +201,17 @@ path has not yet answered.
 
 ### Strength is content and seed dependent
 
-The two profiles resolve an unset strength differently, because different things
+The profiles resolve an unset strength differently, because different things
 were measured for each.
 
-`qwen-zimage` reads it from image area, through the resolution-adaptive denoise
-curve. The vendor is deliberately ignored for openai/unknown content: the curve,
-not the issuer, is what was calibrated. One measured exception (0.27.2):
-Google-provenance content takes the flat `QWEN_ZIMAGE_GOOGLE_STRENGTH` 0.30 floor
-- the curve's 0.154 top left a 4.33 MP fixture oracle-detected on the full
-production path (2026-08-18), while 0.30 anchors measured clean on two fixtures
-in two accounts.
+`qwen-zimage` reads unknown content from the resolution-adaptive denoise curve.
+Measured provider cohorts instead take flat operating points: OpenAI `0.07675`,
+Google `0.27`, and Microsoft InvisMark `0.15`. OpenAI and Microsoft add one full
+observed cross-source boundary spread to the worst clean source; Microsoft's three
+first-clean boundaries were `0.04125`, `0.055`, and `0.095`, giving `0.14875` before
+rounding up. Google's candidate was separately repeated across three valid sources
+and three accounts. The small corpora make these operating points, not universal
+thresholds.
 
 `sdxl-zimage` reads it from the C2PA issuer, on a flat ladder:
 
@@ -196,10 +224,25 @@ values are flat rather than a curve because flat values are what was measured: e
 verdict came from a fixed strength at one size, and no size dependence has been
 established for that stage.
 
-An explicit `--strength` overrides both. The defaults are operating points, not
-universal guarantees. Near a removal threshold, different content or a different
-random seed may change the verifier result, which is why both profiles are
-certified at a fixed seed. The live resolver is
+`chroma-zimage` also reads a flat ladder from the provenance cohort, measured
+2026-08-29/30 across the four vendor oracles (full record:
+[`chroma1-engine-research.md`](chroma1-engine-research.md)):
+
+- OpenAI: `0.09` (below qwen's `0.07675` is false economy neither way -- the
+  matched-strength fidelity favors Chroma1 on this cohort);
+- Microsoft InvisMark: `0.125` (below qwen's `0.15`);
+- Google: `0.40` for zero-face content (above qwen's `0.27`; at this floor the
+  regeneration destroys dense text and collapses face identity -- the tradeoff
+  that motivates the adaptive arm below), or `0.125` when YuNet detects at
+  least one face (both measured face fixtures clear at 0.12 with zero
+  cross-source spread; oracle-verified 2026-08-30);
+- Meta Content Seal: `0.17` (above qwen's `0.1`);
+- unknown: `0.40`, following the strictest measured cohort.
+
+An explicit `--strength` overrides all three. The defaults are operating points,
+not universal guarantees. Near a removal threshold, different content or a
+different random seed may change the verifier result, which is why the profiles
+are certified at a fixed seed. The live resolver is
 [`watermark_profiles.py`](../src/remove_ai_watermarks/_internal/watermark_profiles.py).
 
 ### Pipelines have different quality tradeoffs
@@ -208,6 +251,8 @@ certified at a fixed seed. The live resolver is
 | --- | --- |
 | `qwen-zimage` | CUDA only, large model stack, and limited broad certification across seeds and content. |
 | `sdxl-zimage` | CUDA only. Its strength ladder is flat per vendor, not a resolution curve, because flat values are what was measured. |
+| `chroma-zimage` | CUDA only. Higher Google and Meta floors than qwen; Google face content uses 0.125 instead of 0.40. |
+| `auto` | CUDA only. Routes OpenAI and Microsoft to chroma-zimage and everything else to qwen-zimage. |
 
 Only manually verified `vae-glyphs` is an optional production stage, and it is
 experimental rather than a default.
@@ -229,8 +274,9 @@ per-stage schedule, CFG 1.0 and CUDA.
 ### Small images are processed at their native size
 
 There is no minimum-resolution floor. It existed to enlarge small inputs toward
-SDXL's ~1024 training resolution and was removed with the SDXL profiles, which
-never applied it anyway. Both surviving profiles run at native geometry, so a
+SDXL's ~1024 training resolution and was removed with the standalone SDXL and
+ControlNet profiles, which never applied it anyway. The surviving `sdxl-zimage`
+is a different profile and is unaffected. All three surviving profiles run at native geometry, so a
 small input is neither enlarged before diffusion nor restored afterward.
 
 `--max-resolution` still caps very large inputs, and only ever scales down.
@@ -260,7 +306,7 @@ device and re-reads every parameter from disk on each stage transition.
 
 Invisible-watermark removal refuses any device but CUDA at construction. There is
 no MPS out-of-memory fallback that continues on CPU, and no lighter profile to
-drop to: both remaining profiles need an NVIDIA GPU.
+drop to: all three profiles need an NVIDIA GPU.
 
 When a run does not fit, the levers are `--tile` (native geometry, tiled
 diffusion), `--max-resolution` (an explicit downscale), and `--cpu-offload`.
@@ -301,11 +347,11 @@ supported AI provenance metadata without transcoding streams.
 
 `video visible` and `remove_video_visible` additionally support the moving
 Sora 2 mascot and wordmark, the current Veo four-point diamond, the legacy
-`Veo` text, the Seedance boxed `AI` label, the fixed `Dola AI` text, the Hailuo
-MINIMAX/Hailuo composite label, and the bottom-right Kling label with its
+`Veo` text, the Seedance boxed `AI` label, the fixed `Dola AI` text, the Hailuo AI
+MINIMAX/Hailuo AI composite label, and the bottom-right Kling AI label with its
 version suffix. Detection requires a recurring visual candidate across
 adjacent frames. Fixed-mark candidates must remain anchored rather than
-drifting with a scene object. Kling also requires a bright low-saturation
+drifting with a scene object. Kling AI also requires a bright low-saturation
 candidate near the expected frame edge. Provider provenance can recover
 low-contrast runs only after visual evidence exists for the marks that define a
 provenance prior, so metadata alone does not erase a clean API export.
@@ -316,7 +362,7 @@ policies and selects the first stable result in specificity order. Use an
 explicit mark when the provider is already known.
 Historical Sora Turbo exports use a small OpenAI swirl in the corner rather
 than the moving mascot-and-wordmark design; that earlier variant is not
-detected by the `sora` video mark. Hailuo and Kling coverage is specific to the
+detected by the `sora` video mark. Hailuo AI and Kling AI coverage is specific to the
 verified lower-edge layouts; a new provider layout needs a separate calibrated
 silhouette. Other provider video labels are not supported yet. Google video
 SynthID has an oracle-certified VAE removal path, while other proprietary
@@ -407,12 +453,53 @@ remain identical because isolated decoder hits can otherwise be content noise.
 It accepts Variant P schemas 0-2. Variant Q requires a different model, and
 schema 3 is rejected at the measured precision threshold. Its NumPy 1.x runtime
 limits the extra to Python 3.11-3.12; the rest of the package remains supported
-through Python 3.14. The calibration history is in
+through Python 3.14. The current TrustMark dependency line also resolves lightning 2.6.5
+(PYSEC-2026-3624, no fixed release yet); the vulnerable `load_from_checkpoint`
+path is unreachable here because TrustMark loads its checksummed checkpoints
+with plain `torch.load`. Bump lightning and cut a patch release when a fix
+ships. The calibration history is in
 [module internals](module-internals.md#metadata-and-provenance).
 
-External AI versus real image classifiers are out of scope. The project
-identifies concrete local provenance signals instead of shipping a generic
-statistical classifier.
+A generic metadata-free AI-generated-image classifier is not shipped. It is a
+separate open research task from provenance detection: the current Model 1
+result is AI-versus-camera and still confuses some conventional graphics, CGI,
+product cutouts, and scans with generation. The OpenAI/Gemini source finder is
+narrower again and cannot substitute for the general classifier. The shipped
+product identifies concrete local provenance signals instead of presenting
+either research classifier as a supported verdict.
+
+Frozen transfers of Community Forensics, SPAI, SAFE, RINE, Nonescape Mini,
+Dual Data Alignment, PGC, and DGS-Net did not close this gap at the required low
+false-positive rate. DDA supplies a complementary representation but its
+independent errors make simple hybrids worse. PGC SD1.4 is strong on OpenAI,
+but its published output and the useful global/residual ablations misclassify
+most or all of the Kodak scan set; removing that branch removes the OpenAI
+gain. DGS-Net is weak at the same operating point and also adds independent
+photo errors. A source-disjoint public-domain museum audit confirmed a separate
+human-art failure: Model 1 called 355/1,050 drawings, prints, manuscripts,
+paintings, textiles, and studio-object or historical-photo rows AI-generated.
+Its error was 0/150 on the historical-photo control, so ordinary camera accuracy
+does not bound accuracy on other human-created visual media. A domain veto
+removed the museum errors in development but failed the existing AI-test and
+fresh-photo core. A second source-disjoint modern-negative audit measured the
+commercial cells: across 421 date-clean Unsplash and CC-licensed Flickr images,
+Model 1 accepted 16.4% as AI, concentrated in logo/graphic design (38.3%),
+retouched fashion photography (34.1% on the Unsplash cell; 2/40 on the Flickr
+replication), and product cutouts (16.0%), while composites
+stayed clean at 0/50 and long exposure near clean at 11/146 after a
+two-part contamination control (a 0/450 provenance-metadata scan and a
+pre-2022-08 date bound that dropped 29 rows, correcting one contaminated
+Flickr fashion cell). The failure pattern therefore spans both historical art
+and modern stylized graphics, not photographic exposure technique. A
+source-disjoint linear veto fit on the date-clean modern cells was then
+rejected one gate earlier: no searched operating point repaired even one
+modern dev error without dropping below the frozen EvalGEN and FLUX floors,
+because modern human graphics and AI generations overlap almost one-to-one in
+the frozen CLIP embedding, at roughly 1.3 to 1.5 AI positives lost per negative
+repaired. Model 1 also lacks a time/device-disjoint negative contract
+for modern computational photography. The measured public protocol, GitHub
+survey, and rejected fusions are recorded in
+[AI-generated image classifier research](ai-generated-image-classifiers.md#general-ai-classifier-github-sweep-2026-08-25).
 
 ## Output and traceability
 

docs/module-internals.md

@@ -11,7 +11,8 @@ updated in the same change.
 
 ## Architecture
 
-The package has four main paths:
+The package has four main paths, plus an opt-in pixel classifier that is not
+on the provenance or removal graph:
 
 ```mermaid
 flowchart LR
@@ -19,13 +20,18 @@ flowchart LR
     Input --> Visible[Visible mark removal]
     Input --> Invisible[Diffusion regeneration]
     Input --> Metadata[Metadata stripping]
+    Input --> Classify[classify_pixels]
 
     Identify --> Report[ProvenanceReport]
     Visible --> VisibleOutput[Localized and filled image]
     Invisible --> InvisibleOutput[Regenerated image]
     Metadata --> MetadataOutput[Container with AI metadata removed]
+    Classify --> PixelClassification
 ```
 
+`identify` does not call `classify_pixels`. `has_invisible_target` and `all`
+do not read it.
+
 The `all` command runs visible removal, optional invisible regeneration, and
 metadata stripping in that order.
 
@@ -296,13 +302,13 @@ from the gate. The full-clip oracle floor is
 detected while `0.15` did not.
 
 [`video_visible.py`](../src/remove_ai_watermarks/video_visible.py) implements
-the first pixel stages for Sora, Veo, Seedance, Dola, Hailuo, and Kling. The
+the first pixel stages for Sora, Veo, Seedance, Doubao, Dola, Hailuo AI, and Kling AI. The
 Sora detector searches a normalized frame with a fully synthetic
 mascot-and-text silhouette at several scales. The Veo detector uses separate
 synthetic silhouettes for the current four-point diamond and legacy `Veo`
 text. Seedance uses a synthetic rounded boxed-`AI` silhouette, while Dola uses
-an OpenCV-font `Dola AI` silhouette. Hailuo uses a synthetic waveform,
-MINIMAX/Hailuo text, separator, and ring. Kling combines synthetic font
+an OpenCV-font `Dola AI` silhouette. Hailuo AI uses a synthetic waveform,
+MINIMAX/Hailuo AI text, separator, and ring. Kling AI combines synthetic font
 variants with a ring approximation of its swirl; the logo path rescues
 wordmarks whose version or font differs, while the edge and white-label gates
 reject recurring scene texture. All fixed-mark searches are bounded to the
@@ -323,23 +329,23 @@ Every per-frame result is untrusted. Each provider's floors, minimum-run policy,
 fill padding and mask style are one row in `VISIBLE_MARK_POLICIES`, and every mark
 enters the same `stabilize_localizations` entry point; the recurrence
 implementation underneath knows nothing about providers. That policy row also
-carries `accepts_provenance`, which forces `provenance=False` for Hailuo and Kling
+carries `accepts_provenance`, which forces `provenance=False` for Hailuo AI and Kling AI
 — they have no metadata that could confirm them, and the guarantee used to be
 structural (their wrappers took no `provenance` parameter at all). Provenance can relax a low-contrast run only
 after recurring visual evidence exists. Sora transition frames follow the
-nearest confirmed moving position only with Sora provenance. Seedance, Dola,
-Hailuo, and Kling additionally require candidates to remain anchored to the
+nearest confirmed moving position only with Sora provenance. Seedance, Doubao,
+Dola, Hailuo AI, and Kling AI additionally require candidates to remain anchored to the
 start of a run. This rejects slowly drifting scene details that still have
-high frame-to-frame overlap. Hailuo and Kling do not infer provenance from
+high frame-to-frame overlap. Hailuo AI and Kling AI do not infer provenance from
 technical encoder tags; their confirmed public samples carried no provider
 metadata.
 
 Removal runs in a second decode pass. Sora, legacy Veo text, Dola text,
-Seedance, Hailuo, and Kling use box masks. Seedance deliberately fills the
+Seedance, Hailuo AI, and Kling AI use box masks. Seedance deliberately fills the
 complete localized box: a synthetic outline mask passed repeat detection but
 left part of the real translucent border visible during visual end-to-end
-review. Hailuo expands beyond the matched core to cover both provider icons.
-Kling expands around the wordmark or swirl to include the version and optional
+review. Hailuo AI expands beyond the matched core to cover both provider icons.
+Kling AI expands around the wordmark or swirl to include the version and optional
 `PRO` suffix. The square Veo diamond uses a synthetic shape mask so transparent
 corners do not erase unrelated pixels. Every mask goes through the shared
 `watermark_registry.fill` backends. ffmpeg encodes the changed video stream and
@@ -379,23 +385,68 @@ Structured extraction is limited to the active manifest and the ingredient
 manifests reachable from it. Validation is preserved as separate dimensions:
 asset binding integrity, claim signature, signer trust, and signer certificate
 validity. A matching asset hash and valid claim signature do not make an
-untrusted or expired signer trusted. `identify` therefore assigns high confidence
-only when all four dimensions validate, medium confidence to an intact but
-untrusted or unvalidated claim, and no origin verdict to a hash/signature failure.
-The failed claim remains in the marker inventory and keeps the removal gate
-fail-safe because a post-signing container edit can invalidate C2PA without
+untrusted or expired signer trusted, so those stay separate fields and separate
+caveats -- but they do not lower confidence. `identify` assigns high confidence
+when the asset binding and the claim signature both validate, medium confidence
+to a claim that validated nothing (fallback parsing, unknown dimensions), and no
+origin verdict to a binding failure, a signature failure, or a revoked signing
+credential. The failed claim remains in the marker inventory and keeps the removal
+gate fail-safe because a post-signing container edit can invalidate C2PA without
 removing a declared pixel watermark.
 
+Revocation reaches the disqualifying branch through `signer_validity`, not through
+binding or signature. A check that read only the latter two returned a confident AI
+verdict off a credential the issuer had disowned, with an empty `integrity_clashes`
+-- quieter than a hash mismatch on the same file. Certificate expiry is deliberately
+not disqualifying: an expired certificate does not imply the signed bytes changed,
+and a signature actually made outside validity already arrives as
+`claimSignature.outsideValidity`.
+
+One rule, one place. `_validation_fields` maps status codes to the four dimensions
+and also emits `c2pa_failed_codes`, the subset of failures that actually drove a
+dimension to invalid; `c2pa_info_has_invalid_credential` maps those dimensions to
+disqualified, and both the ingredient-reachability walk and the report consume that
+single path. The displayed reason comes from `c2pa_failed_codes` rather than a
+substring rescan of the full code list, so what a caller is shown as the cause
+cannot become a looser rule than the verdict it explains.
+
 The structured walk also treats an exact known AI product in a reachable
 `claim_generator` as an AI assertion. This covers update chains where the active
 manifest names only `c2pa-tool` while a validated ingredient names Dreamina, and
 Firefly chains that identify `Adobe_Firefly` without repeating a digital source
 type. Unreachable manifests remain excluded.
 
+Reachable `c2pa.soft-binding*` assertions retain their exact `alg` and bounded,
+printable block `value` in addition to the normalized vendor label. A block value
+without its algorithm is not surfaced because it cannot be attributed to a
+decoder or registry entry. `com.microsoft.invismark.1` uses that value as the
+pixel-watermark identifier in Microsoft Paint output. An InvisMark soft binding
+keeps the invisible-removal gate fail-safe even when the C2PA asset binding has
+since become invalid, because metadata damage does not prove the pixel carrier
+disappeared. `identify` retains the generic `soft_binding` signal for schema-1
+compatibility and adds `invismark` as the stable pixel-removal signal.
+Content-fingerprint soft bindings do not trigger pixel regeneration.
+
 The SDK default enables trust verification but supplies no production trust
 anchors. Consequently, an installation without an explicitly maintained C2PA
-trust bundle reports otherwise valid signer chains as untrusted and keeps their
-attribution at medium confidence. Shipping or fetching an official trust bundle
+trust bundle reports every otherwise valid signer chain as untrusted --
+`signingCredential.trusted` appears in no default installation, from any vendor.
+Confidence therefore must not depend on it. It did from 0.27.0 through 0.30.0, which made
+the high-confidence branch unreachable in production while a hand-built fixture
+stamping `signingCredential.trusted` kept it green in the suite; measured on the
+committed provenance fixtures, every C2PA file from OpenAI, Adobe and Black Forest
+Labs came back untrusted, and an intact manifest scored the same medium as a
+fallback parse that validated nothing. That collapsed the one distinction the
+official reader exists to draw.
+`tests/test_identify.py::TestIdentifyRealSamples::test_no_committed_fixture_reports_a_trusted_signer`
+is the reachability guard: it asserts the fixtures really are untrusted and still
+reach high confidence.
+
+Read `untrusted` here as a missing input, not a finding: nothing was checked,
+because there was nothing to check against. If a maintained trust bundle is ever
+configured, that stops being true and the confidence mapping in
+`_c2pa_credential_level` must be re-read, because only then does a failed trust
+check mean the signer was rejected. Shipping or fetching an official trust bundle
 requires a separate update, provenance, and availability policy; do not silently
 convert `signingCredential.untrusted` into trusted based on a vendor-name match.
 
@@ -406,7 +457,9 @@ 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.
+attribution. An unmapped issuer org reads as unknown-signer C2PA with no platform;
+that is how Ideogram was surfaced (4 corpus uploads signed "Ideogram, Inc",
+2026-08-08) before its vendor row was added on 2026-08-27.
 
 ### Metadata scanning and stripping
 
@@ -486,7 +539,382 @@ metadata extraction from verdict logic:
   both extractors reach the same answer. It did not, and the record path silently
   reported no SynthID for images the file path flagged.
 - `identify` preserves the path-based API and adds the optional registered
-  visible-mark and open invisible-watermark decoders after extraction.
+  visible-mark and open invisible-watermark detectors after extraction.
+
+### SynthID periodic carrier detector (research only)
+
+The local lattice expert is not part of the public package. Runtime code lives
+in [`scripts/synthid_runtime/`](../scripts/synthid_runtime/) and the campaign
+log is [`synthid-detector-research.md`](synthid-detector-research.md). The
+notes below are the calibration history of that research expert.
+
+[`synthid_detector.py`](../scripts/synthid_runtime/synthid_detector.py) is the
+runtime form of the frozen 2048x2048 periodic-tile experiment. It folds a
+Gaussian high-pass residual modulo 16x16 within a calibrated pixel-count range
+and compares the normalized RGB tile with the bundled float64 template
+`scripts/synthid_runtime/synthid_periodic_tile_2048_v1.npz`. Exact multiples use the original
+reshape-and-mean path; other sizes use count-correct modulo folding,
+without resize. Channels are filtered and folded sequentially, and partial edge
+blocks are accumulated without a full-frame padding buffer so the 18-megapixel
+ceiling does not require multiple three-channel float workspaces. The model hash
+is pinned by a test, and the unchanged operating threshold is
+`0.17357069773071196` through 10 megapixels.
+
+That fixed threshold is not production-qualified. A later source-fresh
+Open Images test-split challenge produced 5 crossings among the 211 images in
+its supported geometry. A precision-first `0.28` replacement is frozen as a
+research candidate after retaining all 12 available source-diverse native
+positives and rejecting those five crossings. It then failed the second
+untouched holdout at 1/213, with score `0.322542963`. The replacement is
+rejected and fixed-v2 remains an explicit diagnostic only.
+
+The direct API returns `detected`, `indeterminate`, or `unsupported`. Passing
+`register_scale=False` selects fixed-v2 from 1,000,000 through 10,000,000
+decoded pixels as an explicit diagnostic. Its frozen threshold accepted
+none of 5,000 public COCO views balanced across every observed target geometry,
+and none of a separate 5,000-view challenge over 256 generated geometries
+covering every pair of modulo-16 edge remainders. The original 2048x2048
+verdicts and exact scores remain unchanged. Runtime matches do not attribute a
+provider. `identify` adds only positive matches as high-confidence
+evidence and never turns a local negative into a clean verdict.
+The result envelope also names the signal family, provider scope, backend,
+whether metadata contributed to the verdict, whether pixels were preserved,
+and an explicit reason for unsupported or indeterminate results. These fields
+are shared with the official OpenAI verifier's JSON boundary.
+
+The production router selects `synthid-periodic-tile-large-v1` above 10 through 18
+megapixels when both dimensions are at least 2,048 pixels. It evaluates all
+phase-aligned 2,048-square windows and combines the minimum fixed-template,
+Red-minus-Green, and Blue-minus-Yellow spatial correlations with the most
+negative Blue-minus-Yellow mid-band correlation. The 3072x5504 portrait
+geometry also applies a Green mid-band alias veto. Each component is normalized
+to its frozen gate and the public threshold is `1.0`.
+
+All 37 inferred large candidates cross the rule, and all seven metadata-free,
+pixel-identical candidates checked by the official Gemini verifier were
+detected. The constants rejected all 17,417 exposed external controls. A
+post-freeze production-path challenge then rejected all 2,637 decoded-pixel-
+unique controls drawn from 2,000 COCO images excluded from the earlier large
+color-phase challenge and 637 deduplicated Picsum controls. Four large
+geometries and four resampling kernels were balanced; the maximum score was
+`0.0592777965`. The source collections were not freshly acquired, so this is a
+feature-unseen holdout rather than a fresh-source estimate.
+
+A separate post-freeze Open Images download yielded 41 completed,
+decoded-pixel-unique controls after excluding incomplete `.aria2` files and all
+prior Open Images hashes. The frozen production path accepted 0/41 and reached
+a maximum score of `0.4083013324`. This source-fresh audit is too small to
+replace the main holdout interval but checks the acquisition boundary.
+
+The same seven official positives were then re-encoded at unchanged dimensions.
+JPEG-95 and JPEG-90 each reduced detection from 7/7 native files to 0/7. The
+large operating point is therefore native-pixel and lossless-copy support, not
+a codec-robust claim.
+
+Arbitrary geometry is not the same as arbitrary spatial resampling. On a
+stratified 80-image fixed-positive sample, one-step resizes at seven nonidentity
+scales from 0.5 through 1.5 reduced the unchanged 16x16 detector from 80 accepted
+sources to zero at every scale. Restoring the original geometry recovered 58-80
+sources, showing that the carrier period scaled with the pixels. A discovery
+bank that scaled the template to integer periods 8, 10, 12, 14, 18, 20, and 24
+was promising: a threshold frozen above 3,000 resized COCO controls accepted no
+view in a 2,000-control final partition and accepted 672 of 800 source-disjoint
+provider positives. It also stayed below threshold on the tracked OpenAI and
+Adobe controls. The branch remains research-only because noninteger periods at
+scales 0.8, 0.9, 1.1, 1.2, and 1.333 collapsed, while separate per-period
+thresholds accepted five final controls. The runtime therefore keeps only the
+fixed 16-pixel lattice.
+
+A follow-up fractional-period probe sampled the 30 strongest template harmonics
+over a continuous 7.5-24.5 period range. The correct period appeared within
+0.05 pixels among the top three candidates for 58 of 60 transformed positives.
+Testing nine neighboring reconstructed geometries then recovered 44 of 60 at
+the native threshold, compared with an upper bound of 48 when the true source
+geometry was supplied. The complete search still failed its small frozen
+control split: a threshold above 250 development controls accepted two of 150
+final controls. Multiplying the canonical score by spectral-period confidence
+also accepted two. That baseline was rejected rather than shipped at its
+discovery threshold.
+
+The research-only
+[`synthid_affine_lattice_probe.py`](../scripts/synthid_affine_lattice_probe.py)
+adds split-confirm synchronization. It estimates complex harmonic coherence on
+one checkerboard of patches, confirms the selected period on the other, and
+reports amplitude-aware confirmation, a locally content-whitened multichannel
+code match, and phase-preserving and cyclically registered template scores. A
+0.1-pixel grid recovered the expected
+12.8, 14.4, 17.6, and 19.2 periods in 20/20 transformed views from five official
+positive parents. A provisional conjunction accepted none of 800 corresponding
+views from 200 oracle-negative parents, none of 469 OpenAI-labeled rows, and
+three of 276 broad non-Google rows whose TC260 or Samsung provenance prevents
+treating them as clean oracle negatives. This probe is not runtime routing:
+positive diversity is still inadequate, period 8 remains rejected, and the
+amplitude stage currently handles isotropic scale at zero rotation only. Full
+protocol and caveats are in the detector research plan.
+
+The whitened match uses neighboring noncarrier bins to estimate complex
+Green/opponent-color covariance around every selected harmonic. It corrected a
+period-24 alias on one native official positive, giving the broad native search
+the correct period 16 on all five ordinary-size positives. It was retained only
+as a candidate reranker: its positive-to-negative margin was smaller than the
+existing spatial-template margin in both the native pilot and a locked 0.8
+resize challenge. Two of the three TC260/Samsung-provenance challenge crossings
+also matched the full whitened code more strongly than the weakest official
+large positive, so the pixel result identifies a compatible signal family, not
+a provider.
+
+The same probe also exposes a payload-agnostic H5 confirmation. It estimates a
+complex harmonic vector independently on the two checkerboards and measures
+their fixed relative-phase inner product; the codeword need not match the known
+template. Free cyclic-shift selection was rejected because natural phase aliases
+overlapped the controls. The fixed all-harmonic statistic separated five native
+official positives from 130 controls with margin `0.1619`, and five 0.8-resized
+views from 200 fresh-parent controls with margin `0.1541`; all seven large
+official positives also passed the observed gap. It remains research-only
+because these tests supplied the period, reuse one negative source family, and
+contain only 12 independent positive parents.
+
+The separate research-only
+[`synthid_cyclostationary_probe.py`](../scripts/synthid_cyclostationary_probe.py)
+measures full complex cross-channel spectral correlation at carrier shifts
+against neighboring-shift same-image nulls. It recognizes synthetic amplitude
+modulation and rejects both independent noise and a purely additive carrier.
+The real native pilot overlapped completely: five official-positive joint
+contrasts ranged from `-0.0027` to `0.0337`, while 130 controls reached `0.0593`.
+The cyclostationary branch is rejected rather than tuned on new frequency bands.
+
+The affine-lattice research CLI also supports symmetric in-memory JPEG and
+top-left crop challenges. At fixed native period 16, codec-specific
+phase-preserving template thresholds retained all five repeated positive views
+and accepted none of 80 locked controls at JPEG qualities 95, 90, and 80. The
+locked margins declined from `0.1054` to `0.0257`; whitened and unknown-codeword
+scores were rejected for lossy JPEG. A separate registered crop conjunction
+retained all five views and accepted none of 80 controls after both 5% and 10%
+top-left crops, with registered-template margins above `0.22`. These are
+research pilots, not runtime experts: the period was supplied, positive parents
+were reused, and only one codec implementation and one negative family were
+tested.
+
+The `register_scale=True` path is the calibrated ordinary-size production
+expert. It
+keeps the harmonic search, adds three-level scale-space consistency and quadrant
+agreement. Its calibrated decision requires the canonical winner to be the
+strongest spectral-period candidate, its three-way amplitude to cross the
+threshold for that period bin, and both independent high-frequency template
+bands to correlate by at least `0.075`. The public registered score is the
+minimum normalized margin across those gates, so its decision threshold is
+`1.0`.
+
+The earlier single-threshold version produced 68 false positives among 11,273
+symmetrically downscaled Spaces controls. A top-candidate plus period-bin version
+removed those but still produced 6 false positives among 1,000 source-independent
+Open Images controls. The high-band gate removed them and then accepted none of
+499 previously untouched Open Images reserve controls. The resulting rule
+retained 229 of 355 source-disjoint transformed positives: 0/65 at scale 0.5 and
+229/290 from scale 0.65 through 1.5. The explicit period-8 rescue is rejected
+because resize lattices fully overlap its positive distribution.
+
+A subsequently frozen 1,000-image Open Images reserve accepted zero in
+registered mode. The fixed expert supported only 81 of those geometries and
+accepted seven, so fixed and registered results cannot safely be unioned. In
+overlapping geometry the registered decision remains the validated path;
+fixed-only evidence is a diagnostic rather than a universal-cascade positive.
+
+A later source-fresh 3,000-image Open Images test-split challenge superseded the
+registered-v2 precision claim: it accepted 4 of 2,997 supported controls. The
+registered-v3 confirmation uses disjoint patch groups for phase, cyclic
+amplitude, and held-out-codeword evidence. It rejected all four crossings,
+retained 147 of 148 base-accepted source-diverse positives, and retained all 359
+base-accepted views in a dense 0.65-1.50 transform matrix over 12 independent
+parents. Frozen unchanged, it then accepted 0/2,996 controls from a second
+nonoverlapping Open Images cohort and 0/2,366 supported controls from a
+3,000-image COCO second-family challenge. Registered-v3 is now the default
+ordinary-size positive route. The exact gates, acquisition hashes, and rejected
+weak-signal rescue are recorded in the detector research plan.
+
+Every one of those control rates is photographic. Against 223 corpus images
+whose C2PA names a non-Google generator, the unchanged entry point accepted 29
+(`0.130`, Adobe Firefly `0.241`, highest foreign score `3.01`), all from
+registered-v3. The branch reads a lattice shared across generation pipelines,
+which is why it must not be reported as a watermark. The public `identify`
+path no longer calls this expert.
+
+The branch is also phase-locked to the image origin, exactly like the large
+expert. A two-pixel diagonal crop killed all 28 in-geometry foreign detections
+and all 8 detected Google provenance positives (maximum remaining scores
+`0.779` and `0.311` against the `1.0` threshold); the signal recovers only at
+offsets that are multiples of four. Registered-v3 therefore detects the same
+crop-destroyed generation-pipeline lattice as `large-v1`, on ordinary sizes.
+
+When registered-v3 abstains, opponent-registered-v1 searches the same frozen
+template in Red-minus-Green and Blue-minus-Yellow space. It reranks three
+separated scale candidates with fixed RGB and two spatial opponent-color gates,
+then accepts only periods 7.9-12.0 on 1-10 megapixel rasters whose sides are at
+least 768 pixels. Period-8 candidates additionally require Red-Green and
+Blue-Yellow 8-pixel edge ratios no greater than `1.05`; this vetoes the
+deterministic JPEG block lattice without using container metadata. The final
+rule recovered 49/49 lossless 0.5x-0.75x views from seven official-positive
+parents. It rejected all 1,790 measured period-8 codec crossings, while 350
+identically resized controls had no base crossing and the earlier period-band
+rule accepted 0/1,000 post-freeze Picsum controls. Period 12.8 remains excluded,
+and lossy JPEG/WebP views remain inconclusive.
+
+The runtime precedence is registered-v3, the bounded opponent fallback, then
+large-v1 above 10 megapixels. Passing `register_scale=False` selects the legacy
+fixed diagnostic explicitly. The research bank in
+`scripts/synthid_routed_expert_bank.py` keeps all three observations for audits.
+Neither runtime nor research routing returns a clean-image verdict.
+
+An unchanged registered challenge from 10 to 18 megapixels retained only 1 of
+37 Google candidates and zero of 89 non-Google controls. Twenty-eight positives
+cleared amplitude, 21 had matching spatial and spectral periods, but only three
+cleared high-band agreement. The 10-megapixel ceiling therefore remains.
+Phase-aligned 2,048-square fixed windows did not provide a fallback: median
+consensus retained 36 positives and accepted 10 controls, while all-window
+consensus retained 36 and accepted eight.
+One frozen full-frame pre-resize to eight megapixels also retained only the same
+1 of 37 positives and zero controls; just three positives cleared high-band
+agreement. Large images therefore cannot be routed through a canonical-size
+registered fallback; the later native opponent-color branch is separate.
+The remaining phase-aligned window variants closed this branch: a single center
+2,048-square registered window retained 1 of 37 positives and zero of 89
+controls, while accepting any phase-aligned 2,048-square window retained 2 of
+37 and zero controls. The latter control maximum was already 0.968 against the
+1.0 decision threshold. Neither the coverage nor the exposed specificity
+margin supports a registered-window expert; these results do not apply to the
+later native opponent-color branch.
+
+A separate half-scale patch-consensus branch initially looked promising. Its
+64-pixel, 90th-percentile patch statistic retained 33 of 49 validation positives
+and zero of 166 controls, then 27 of 52 locked-test positives and zero of 140
+controls. The frozen broad challenge rejected it: 61 of 10,906 symmetrically
+half-scaled Spaces controls and 22 of 1,000 independent Open Images controls
+crossed the unchanged threshold. A post-challenge Green negative-phase spread
+gate removed those errors but retained only 2 of 234 later Google rows and zero
+of 689 later controls. Half-scale support therefore remains explicitly absent.
+
+An independent reproduction of the public `aloshdenny/reverse-SynthID` V4
+cross-color codebook did not provide another expert. Its best-of-two-model phase
+rule retained 141 of 355 positives but accepted 191 of 499 controls and 386 of
+a fresh 1,000-control reserve; AUC was 0.517. The repository's stricter
+aspect-ratio routing reduced coverage but preserved the same approximately 38%
+positive and control acceptance within supported rows. Its older V3 phase score
+had AUC 0.473, and two prespecified amplitude-aware V4 rerankings reached only
+0.521 and 0.524 AUC. These external rules are research baselines only. Their useful
+contribution is the solid-reference phase-consensus construction, not either
+published single-image threshold. Full methodology and the DALL-E reference-set
+confound are recorded in the detector research plan.
+A later exact repeat on the hash-disjoint v7 challenge confirmed the same
+failure: the published cut accepted 77/200 Google and 76/200 OpenAI, so it did
+not separate the two target providers.
+A direct exact-1024 reproduction of the same V4 artifact confirmed rather than
+rescued that verdict: the union of its two published profiles accepted 177 of
+443 Google rows and 60 of 162 controls. The artifact's floor left only about two
+active bins in the inspected profile/channel, explaining why its score acts
+as a weak generic phase-coherence test rather than a specific codebook match.
+
+An exact-1086x1448 OpenAI follow-up also rejected the solid-reference transfer.
+A low-texture 256-bin phase codebook achieved native and JPEG-95 test AUCs of
+0.512, and independent train halves shared only two exact bins. The paper's
+content-dependent alternative was tested with 60 OKLab masking-alignment
+features. Its native/JPEG minimum reached test AUC 0.593 and 15/562 positives
+versus 1/228 controls at the frozen boundary, but deterministic half-fits shared
+no positive decision and had coefficient cosine 0.148. Neither branch is a
+runtime OpenAI expert.
+
+An exact-1254 assertion-contrast search selected an sRGB period-8 Blue-channel
+direction at 45 of 259 validation asserted rows and zero of 16 same- or
+other-provider validation rows. It failed its locked specificity check at 39 of
+233 asserted rows and one of 18 controls. Across the complete exact-geometry
+audit it accepted 185 of 992 asserted rows, one of 55 same-provider rows without
+an assertion, and one of 13 other-provider rows. Raising the threshold above
+the wider controls reduced recall to a small minority, so this branch remains
+research-only.
+
+Three attempted veto or missing-codeword rescues also failed. The official
+InvisMark decoder checkpoint passed its own embedded-watermark self-test at
+0.997 confidence and 0.97 bit accuracy, but all OpenAI and provider-control
+cohorts clustered around 0.18 confidence with no useful separation. DTCWT
+modulus before periodic folding retained 5 of 158 locked-test OpenAI rows and
+zero of 135 controls, then zero of 40 fresh OpenAI rows. A 16-codeword whitened
+period-8 model retained 5 of 158 and zero controls, then 1 of 40 fresh OpenAI
+rows and 1 of 50 fresh controls. They neither explain the known oracle-positive
+miss nor justify runtime routing.
+
+An image-level patch-bag model over nine normalized high-pass patches was the
+strongest later local OpenAI classifier. It accepted 324/1,364 development-test
+OpenAI rows with 4/3,373 heterogeneous controls, then transferred to 120/486
+OpenAI rows, 8/504 general controls, and 5/33 same-provider non-assertion rows
+in the later temporal challenge. Assertion enrichment over the same-provider
+stratum was not independently significant (`p = 0.151`, one-sided exact test).
+JPEG-95 reduced the unchanged conjunction to
+1/486 positives and zero controls. The native temporal hits were complementary
+to the signed period-8 hits, but the same-provider rate and codec collapse
+identify another export noiseprint rather than a runtime SynthID expert.
+
+The separate OpenAI period-8 DTCWT component is persistent rather than tied to
+one short rollout: exact-generator asserted hits were 3/16, 46/365, and 26/200
+from May through July, with 75/581 overall versus 1/52 same-generator rows
+without an assertion. Its native/JPEG minimum score reached 0.721 AUC between
+those indeterminate strata. Sorting all 64 cyclic correlation scores removed
+absolute phase but also removed locked-test discrimination at 0/158 positives
+and 0/135 controls. This remains research evidence for a weak signed carrier,
+not a runtime OpenAI detector.
+
+A four-family open-proxy challenge also failed to justify a generic neural
+watermark expert. A fixed residual frontend and cross-family residual mixing
+were trained on three of TrustMark P, VideoSeal, DWT-DCT, and WAM while the
+fourth encoder and its test sources remained unseen. Held-out AUCs ranged from
+0.437 to 0.562. Equal-power phase-scrambled hard negatives prevented simple
+spectral-energy shortcuts, but did not produce architecture transfer. A
+separate translation-invariant Gemini bicoherence search selected none of 20
+development positives and finished at 0/50 positives, 0/199 controls, and AUC
+0.374. Neither branch is part of runtime routing; full split and oracle details
+are in the detector research plan.
+
+The separately measured registered geometry range remains 250,000 through
+10,000,000 decoded pixels with both sides at least 256 pixels. The default path
+and `identify` use registered-v3, then the narrower opponent-registered-v1
+fallback in its 1-10 megapixel domain, and large-v1 above 10 megapixels. A
+20-image real-corpus drift check was byte-identical after the earlier v2 integration.
+The calibration history and caveats are in the linked detector research plan.
+
+### Official OpenAI SynthID verifier
+
+[`openai_provenance.py`](../src/remove_ai_watermarks/openai_provenance.py)
+provides the explicit remote production backend exposed as
+`verify-openai-synthid`. It is intentionally separate from `identify`, because
+one invocation uploads a sanitized raster to OpenAI. The CLI requires
+`--acknowledge-upload`, and the optional OpenAI SDK lives in the independent
+`verify` extra.
+
+The backend accepts only PNG, JPEG, and WebP. It computes a decoded RGBA pixel
+fingerprint, removes AI provenance metadata into a temporary file through
+`metadata.strip_and_verify`, recomputes the fingerprint, and aborts before any
+request if metadata survived, the format changed, the pixels changed, or the
+sanitized file exceeds the endpoint's 50 MiB limit. It then sends exactly one
+multipart file to `content_provenance_checks.create` and parses exactly one
+`type == "synthid"` result. The independent C2PA entry is never returned or
+used as fallback evidence. Missing, duplicate, or unknown SynthID outcomes are
+errors rather than negative detections.
+
+The default SDK client has a 120-second request timeout and zero automatic
+retries. One upload acknowledgement therefore authorizes at most one media
+transmission rather than inheriting the SDK's retry default. Request logs keep
+the endpoint, temporary basename, media type, byte count, timeout, retry policy,
+duration, HTTP status, error code, and request id when available, but omit the
+source path, image bytes, credentials, and decoded-pixel fingerprint.
+
+`OpenAIProvenanceError` preserves the status, API error code, request id,
+`Retry-After` value, and a transient-only `retryable` flag. The library does not
+automatically act on that flag: an explicit caller invocation is required for
+every additional upload. Transport and schema failures remain errors rather
+than becoming `not_detected` or a local detector result.
+
+The result remains provider-scoped and positive-evidence-only. `not_detected`
+does not mean human-created, and the official endpoint's published prohibition
+on repeated reverse-engineering or evasion queries prevents using this backend
+as an adaptive training or removal oracle.
 
 ### Portable metadata record
 
@@ -529,6 +957,22 @@ provenance normalizer. Integration code publishes the strict
 `ProvenanceReport.to_dict()` alongside it rather than letting operational fields or
 derived results influence detection.
 
+### Photo pixel classifier
+
+[`classify.py`](../src/remove_ai_watermarks/classify.py) is the 2026-08-31
+photo freeze: CLIP-L-ft ridge AND freeze MLP, then 124-d focal heads only on
+DEFINITELY. The public label is `ai` / `human` / `unknown`. POSSIBLY is
+`unknown`. The named class is `openai` / `google` / `muse-image` / `tc260` /
+`None`. `tc260` is the China AIGC label standard, not one producer. The freeze
+file keys the Muse Image head `meta_muse_image`. Tests in
+`tests/test_classify.py` pin the gate without downloads and pin that
+`identify` does not import this module.
+
+Weights stay out of git. The Hub snapshot is `wiltodelta/raiw-photo-classify`.
+`RAIW_CLASSIFY_WEIGHTS` overrides it. The extra is `classify`. User guide:
+[photo-classify.md](photo-classify.md). Hub card:
+[photo-classify-hf/README.md](photo-classify-hf/README.md).
+
 ### Pixel forensics
 
 [`pixel_evidence.py`](../src/remove_ai_watermarks/pixel_evidence.py) measures six
@@ -701,9 +1145,9 @@ capture-less pill is too weak to attribute.
 
 The set of marks that veto the pill is DERIVED from the registry rows: every mark
 under the same label regime (`tc260`) belonging to a different product. It used to
-be a hand-written list of keys, and that list drifted -- LibLibAI was registered
-alongside RunningHub and Baidu, both of which were added to it, and LibLibAI was
-not, so a confident LibLibAI detection did not suppress the pill the way its two
+be a hand-written list of keys, and that list drifted -- LiblibAI was registered
+alongside RunningHub and Baidu, both of which were added to it, and LiblibAI was
+not, so a confident LiblibAI detection did not suppress the pill the way its two
 siblings did. Marks outside the TC260 regime (Gemini, Samsung) are deliberately
 not vetoers: neither can put `jimeng` into `provenance`, so neither can enable the
 arm it would be vetoing.
@@ -755,6 +1199,33 @@ be represented by the shared base:
 - [`runninghub_engine.py`](../src/remove_ai_watermarks/runninghub_engine.py)
 - [`baidu_engine.py`](../src/remove_ai_watermarks/baidu_engine.py)
 - [`liblib_engine.py`](../src/remove_ai_watermarks/liblib_engine.py)
+- [`microsoft_engine.py`](../src/remove_ai_watermarks/microsoft_engine.py)
+
+The measured Microsoft badge variant (2026-08-27 registration) is the first
+`tr`-corner mark and the first `long`-side scale basis: the pill tracks the
+render dimension, so a
+1024x1536 portrait carries the same pill as 1536x1024, and a width basis
+undersized the template by the aspect ratio (portrait carriers fell to
+0.15-0.32 NCC until the basis was measured). The silhouette is a white pill with
+its synthetic internal shapes knocked out - the holes are what separate it from
+any other bright rounded corner element (a plain white pill scores below the gate
+in the tests). It does not claim coverage of Microsoft's other documented icon,
+wording, or position variants.
+
+The 2026-08-27 rerun used the registered engine through
+`scripts/registered_mark_calibrate.py`, rather than a copied detector
+configuration. The manifest kept three evidence classes separate: 17 visually
+confirmed carriers, 343 Microsoft-provenance files without a visual adjudication,
+and 1200 non-overlapping no-signal controls. At the strict 0.38 gate, 15/17
+confirmed carriers fired (min 0.249, p50 0.519, p90 0.578, max 0.579), while
+0/1200 controls fired (p99 0.200, max 0.293). The provenance cohort produced
+78/343 fires, but that is not a recall measurement because provenance identifies
+the provider, not the presence of this visible layout. That cohort was later
+labeled by an OCR badge census (2026-08-28: 86 badge carriers, 257 badge-less,
+badge-less max 0.251 / p99 0.213), which is what enabled the shipped provenance
+relaxation 0.7: the relaxed band [0.251, 0.38) holds three faint badges and
+zero false fills, re-verified as 3 band detections with 0/257 badge-less fires
+on the provenance path.
 
 The detector and removal mask must use compatible geometry. A detector that
 fires while producing an empty or misplaced mask is a removal failure even if
@@ -773,14 +1244,41 @@ were briefly skipped there for exactly that reason.
 A mark whose removable footprint differs from what the detector localizes
 overrides `_footprint_rect` (which policy) and `_extend_match_box` (how far the
 box grows), not the whole `footprint_mask`. Baidu extends right to the corner tag
-and LibLibAI extends left to the triangle logo; both inherit every guard around
+and LiblibAI extends left to the triangle logo; both inherit every guard around
 that arithmetic.
 
+Doubao is the deliberate exception because its captured alpha supplies more
+information than a rectangle. Its continuous top-hat response locates the mark,
+then `DoubaoEngine.footprint_mask` resizes the alpha to that same winning
+`match_box` and masks only the glyphs. The canonical 2048-pixel fixture has bright
+branch texture behind the bottom-edge wordmark; bounding the thresholded response,
+padding it, and dilating it produced a solid 404-by-134 mask clamped to the bottom
+and right edges. OpenCV then had no context beyond either edge and filled the hole
+with large triangular wedges. The aligned sparse mask keeps both frame edges
+untouched and still clears the detector. `force` cannot align a missing detection,
+so it retains the shared geometry-box fallback.
+
 Yuanbao uses the polarity-independent `contrast` front end because its standard
 two-line mark can be light on dark scenes or dark on light scenes. Its detector
 and footprint both use the same best-match box. The separate one-line overlay
 variant is not covered.
 
+#### Bare-upload pill arm: measured impossible with the current detector (2026-08-28)
+
+`_keep_pill` never removes a metadata-bare pill, and the question "can a bare arm
+(score + footprint-flatness) be opened" was measured to a closed NO over the local
+spaces corpus: 68 OCR-confirmed bare pills (an independent pixel-level label: the
+band sweep read a flush-left `AI生成`) score p50 0.181 / max 0.317, while 799 clean
+no-signal negatives reach 0.353 and 18 of them already pass the shipped 0.22 raw
+gate. The true-pill and clean distributions overlap completely -- there is no
+threshold -- and the engine's own high scores (0.34-0.48 on the flagged cohort)
+correlate with textured corners, not with pills: the edge-NCC keys on "text-like
+structure top-left". As with the Jimeng wordmark's silhouette, no threshold repairs
+this; a bare arm needs a detector that keys on the pill's rounded-rectangle
+geometry, and until one exists the bare-arm question is settled by this
+measurement, not by gate tuning. Harness: `data/spaces/_pill_bare_measure.py`
+(cohorts A/B/C over the no-signal pool).
+
 The capture-less Jimeng pill lives in
 [`pill_engine.py`](../src/remove_ai_watermarks/pill_engine.py). It uses a
 synthetic silhouette for detection and a fixed top-left footprint.
@@ -792,6 +1290,32 @@ Shared behavior is covered by:
 - [`test_text_mark_faint_mask.py`](../tests/test_text_mark_faint_mask.py)
 - [`test_text_mark_memory.py`](../tests/test_text_mark_memory.py)
 
+#### Doubao video mark (2026-08-28 registration)
+
+`detect_doubao_frame` reuses the image engine's synthetic `doubao_alpha.png` as
+its video template (same `豆包AI生成` run, bottom-right) through
+`_asset_template`, so image and video cannot drift apart on the glyph. Search
+profile: heights 3.2-6.0 percent of the short side from origin (0.60, 0.76),
+measured on the corpus. Policy is seedance-style single-floor: weak 0.35 /
+strong 0.55 / anchor IoU 0.80, calibrated by sequential decode over 39
+TC260-confirmed Doubao videos and 25 negatives -- a 12-frame stable run at 0.35
+accepts 33/39 positives and 0/25 negatives, while 0.30 already accepted one
+negative, so the bar stays at 0.35. Through the shipped arbiter
+(`identify_video`): 32/39 selected as doubao, 0/25 false; the remainder split
+between no stable run (5) and cross-template ties handed to earlier table
+entries (sora 1, kling 1) -- the registry's known order-decides behavior, not a
+doubao-specific defect. Harness: `data/spaces/_doubao_seq_measure.py`.
+
+Two further video candidates were measured and PARKED the same day (2026-08-28,
+`data/spaces/_rh_jm_video_calibrate.py`): the Jimeng CN wordmark does not
+separate on video (1/5 positives vs 2/25 negatives hold a 12-frame 0.35 run --
+the same silhouette-generality the image jimeng engine documents), and
+RunningHub video separates (1/2 positives, 0/25 negatives) but a two-positive
+cohort is below the registration bar; both await corpus growth. The top-left
+"AI生成" pill on video is parked by analysis, not measurement: its image-engine
+false-fire mode is a STATIC textured corner, which is temporally stable, so the
+recurrence arbiter cannot screen it.
+
 ### Fill backends and region erasing
 
 [`region_eraser.py`](../src/remove_ai_watermarks/region_eraser.py) implements the
@@ -824,12 +1348,20 @@ is the source of truth for:
 - profile names and their underscore spellings;
 - the fixed seed;
 - the SDXL global-stage checkpoint id (`SDXL_MODEL_ID`) and the Canny ControlNet id;
-- strength resolution for both profiles.
+- strength resolution for every profile.
 
-The current profiles are `qwen-zimage` (the default) and `sdxl-zimage`, and both
-are CUDA-only. `controlnet`, `sdxl`, `qwen` and `default` were removed rather than
-kept as a CPU path, and are rejected rather than aliased onward. There is no
-content-dependent automatic router.
+The current profiles are `qwen-zimage` (the default), `sdxl-zimage`,
+`chroma-zimage`, and `auto`, and all four are CUDA-only. `controlnet`, `sdxl`,
+`qwen` and `default` were removed rather than kept as a CPU path, and are
+rejected rather than aliased onward. `auto` is a deterministic per-cohort
+selection policy:
+chroma-zimage for OpenAI and Microsoft, qwen-zimage for Google, Meta, and
+unknown. It does not run a learned router or classify the image's genre.
+
+`qwen-zimage` normally resolves global denoise from image area for unknown content.
+Measured provider cohorts bypass that curve with flat operating points. The values,
+measurement derivations, and corpus limits are canonical in
+[`known-limitations.md`](known-limitations.md#strength-is-content-and-seed-dependent).
 
 For serverless cold starts, `InvisibleEngine.preload(global_only=True)` loads the
 mandatory global stage and YuNet while leaving the optional Z-Image and SAM face
@@ -842,8 +1374,10 @@ by the profile, so none of them appears in `WatermarkRemover.__init__`,
 then rejected several frames down; a signature that refuses the argument outright
 fails where the caller can act on it, and stops a wrapper from threading a value
 that would silently do nothing. The step count and CFG live with the stage that
-runs them (`GLOBAL_STEPS`, `FACE_STEPS`, `GLOBAL_CFG`, `FACE_CFG` in
-`qwen_zimage_pipeline.py`). The dtype is likewise profile-owned: see "Face-stage
+runs them: `GLOBAL_STEPS`/`GLOBAL_CFG` with the Qwen global stage
+(`qwen_zimage_pipeline.py`), `SDXL_STEPS` with the SDXL one
+(`sdxl_zimage_pipeline.py`), and `FACE_STEPS`/`FACE_CFG` with the shared face
+stage (`two_stage_pipeline.py`). The dtype is likewise profile-owned: see "Face-stage
 dtype" for what an override cost the last time one existed.
 
 `device` is the exception and remains a library parameter: `None` or `"auto"`
@@ -870,7 +1404,7 @@ same pixels. They diverged before, in opposite directions, for exactly this knob
 
 The global and face prompts are calibrated model inputs, and the Canny edge map
 uses fixed thresholds of `_CANNY_LOW = 13` / `_CANNY_HIGH = 64`
-(`qwen_zimage_pipeline.py`). Treat those values as behavioral compatibility
+(`two_stage_pipeline.py`). Treat those values as behavioral compatibility
 contracts: a refactor must preserve them, and any deliberate change requires
 image-quality evaluation rather than only a unit-test pass. The prompt and
 edge-map regression guards are
@@ -918,8 +1452,19 @@ Regression coverage:
 
 ### Qwen plus Z-Image
 
+The profiles are siblings of one shared recipe rather than a chain:
+[`_internal/two_stage_pipeline.py`](../src/remove_ai_watermarks/_internal/two_stage_pipeline.py)
+holds `TwoStageZImagePipeline`, the base that owns everything profile-independent
+(the Z-Image face stage with YuNet detection and SAM masks, sizing, compositing,
+the prompt cache, and the `run`/`preload` orchestration). A profile subclass
+implements `_load_global` and `_run_global` for its regeneration model and may
+implement `_vae_roundtrip` to expose that stack's VAE as a verified-text donor;
+nothing else differs, and a test asserts the shared methods are the same objects
+on every subclass. Adding a third global stage means implementing those hooks,
+not inheriting from another profile's pipeline.
+
 [`_internal/qwen_zimage_pipeline.py`](../src/remove_ai_watermarks/_internal/qwen_zimage_pipeline.py)
-implements the fixed CUDA-only two-stage profile:
+implements the fixed CUDA-only two-stage profile on that base:
 
 1. Qwen Image with Canny conditioning regenerates the frame.
 2. YuNet locates faces, SAM builds masks, and Z-Image regenerates the selected
@@ -969,12 +1514,15 @@ geometry alone in schema 2, plus a SHA-256 over decoded RGB width, height, and p
 Validation happens before model loading. The library never treats OCR confidence as
 verification, and geometry-only operators do not need to invent text or script fields.
 
-When enabled, `QwenZImagePipeline` reconstructs the source once through its already
-loaded Qwen VAE, runs the ordinary global and face stages, blends 15% of the VAE
-reconstruction into that clean result, and calls the shared restoration compositor.
-The compositor derives binary source and candidate silhouettes, groups nearby lines,
-uses LaMa for the initial and residual-glyph erase passes, paints fresh silhouette
-edges, then copies the Qwen-VAE core with a 0.5-pixel feather. The evaluation script
+When enabled, the one profile selected before model loading reconstructs the source
+once through its already loaded VAE, runs the ordinary global and face stages, and
+calls the shared restoration compositor. Qwen and Chroma implement this donor hook;
+SDXL does not. The optional Qwen-only fidelity anchor first blends 15% of the VAE
+reconstruction into the clean result; it is off by default because the blend returned
+detector-visible OpenAI SynthID in the measured poster fixtures. The compositor derives
+binary source and candidate silhouettes, groups nearby lines, uses LaMa for the initial
+and residual-glyph erase passes, paints fresh silhouette edges, then copies the profile-VAE
+core with a 0.5-pixel feather. The evaluation script
 imports these same mask and compositing helpers so the two implementations cannot
 silently drift. Silhouette crops start 12% of line height beyond each horizontal
 side, then expand each side independently while a foreground component anchored
@@ -989,6 +1537,21 @@ geometry or final pixels after the verified layer and have no measured oracle re
 It remains opt-in because annotations are manual and provider verdicts apply only to
 the exact tested output hashes, not to the mechanism in general.
 
+The first full-path H100 check on 2026-08-31 ran each generative engine exactly
+once per source and used that SAME engine's VAE donor; it did not compose Qwen and
+Chroma in one production result. On the two verified multilingual OpenAI posters,
+restoration reduced PaddleOCR CER from 0.303 to 0.160 and 0.279 to 0.136 for Qwen,
+and from 0.213 to 0.130 and 0.204 to 0.108 for Chroma. PSNR improved on all four
+arms (Qwen 26.1 to 29.9 dB and 27.7 to 31.6 dB; Chroma 29.6 to 33.1 dB and 29.7
+to 32.9 dB). The verified CJK Google fixture is the counterexample that prevents
+an unconditional quality claim: Qwen CER stayed 0.074, while Chroma moved from
+0.037 to 0.074 despite better LPIPS, SSIM, PSNR, and text-box pixel error. The
+stage is therefore implemented and fidelity-positive on both OpenAI sources, but
+not assumed to improve every OCR reading. This is a fidelity check, not a provider
+oracle certification; exact output hashes and per-box metrics are produced by
+`scripts/chroma_text_restoration_study.py` under the gitignored
+`out/text-restoration-engine-study/` directory.
+
 A matched stage-isolation check on the 18-face Gemini portrait grid confirms the
 division of responsibility. The visible-cleaned, metadata-stripped control and the
 Z-Image face-only output were both SynthID-positive; Qwen global-only and the full
@@ -1017,13 +1580,85 @@ oracle outcomes, and the DiffSynth/GGUF, scheduler, detector, and seed caveats a
 recorded in
 [`data/evaluations/fidelity/upstream-v2-reproduction-2026-08-13.csv`](../data/evaluations/fidelity/upstream-v2-reproduction-2026-08-13.csv).
 
+### Chroma1 plus Z-Image
+
+[`_internal/chroma_zimage_pipeline.py`](../src/remove_ai_watermarks/_internal/chroma_zimage_pipeline.py)
+runs the same two-stage recipe on a Chroma1-HD (`lodestones/Chroma1-HD`,
+Apache-2.0) global pass through diffusers' `ChromaImg2ImgPipeline`. It is the
+answer to issue #88's FLUX.2 request through the model that actually exposes
+strength-controlled img2img in that family; the full research record,
+including why FLUX.2 itself is not integrable this way, is
+[`chroma1-engine-research.md`](chroma1-engine-research.md).
+
+The profile also implements the shared verified-text donor hook through its already
+loaded Chroma VAE. It edge-pads native geometry to the /16 latent grid, takes the
+deterministic mode of the encoder distribution rather than sampling it, decodes with
+Diffusers' own image processor, and crops back to the exact source dimensions. Thus
+`auto` still loads and runs only the profile selected by the measured vendor table;
+the presence of a manifest does not introduce a second generative model or override
+that decision. A CPU smoke run against the official Chroma1-HD `AutoencoderKL`
+weights on 2026-08-31 verified the real encode/decode contract and exact restoration
+of a non-grid-aligned source size; model-free tests pin mode-not-sample and padding.
+Chroma-specific full-pipeline provider-oracle certification remains an output-hash
+measurement, not something either check can establish.
+
+The profile swaps only the global stage (same inheritance invariant as
+sdxl-zimage, asserted by the same test shape). Three things are bound to the
+calibration and must not drift: the NEUTRAL prompt (`high quality, sharp,
+detailed, faithful to the original` -- deliberately NOT the shared canny-stage
+prompt, which was never calibrated against Chroma1), guidance 5.0, and the
+four-EFFECTIVE-step schedule with `requested_steps` compensation (the same
+Diffusers truncation trap sdxl-zimage documents). There is no Canny
+conditioning: the floors were measured on a plain strength pass.
+
+The flat vendor floors (`CHROMA_ZIMAGE_*_STRENGTH` in watermark_profiles):
+OpenAI 0.09 and Microsoft 0.125 (both BELOW qwen's, with better
+matched-strength fidelity), Google 0.40 for zero-face content / 0.125 when
+faces are detected (a content-adaptive arm from the clean face-count split
+in the calibration: both text cards need 0.25, both face fixtures clear at
+0.12, so the YuNet detector -- already loaded for the face stage -- routes
+the operating point), and Meta 0.17 (ABOVE qwen's, because Chroma1's
+per-fixture boundaries scatter wider). The matched-strength addendum in the
+research doc is the honest read: at the strength each image actually needs,
+Chroma1 regenerates better almost everywhere except face identity (which the
+inherited Z-Image face stage supplies); at the flat worst-case floors it
+destroys dense text and face identity. The Google face-content arm is the
+first shipped piece of the content-adaptive policy. A Meta arm was measured
+on 2026-08-30/31 (docs/chroma1-engine-research.md, expansion section) and
+does not ship: first-cleans from 0.03 to 0.10 form a continuum,
+`flat_ratio` overlaps the hard and easy clusters, and a high-flat
+easy-arm would misroute the harvest-1 portraits. The worst seed-0
+first-clean is still 0.10; botanical seeds 1 and 2 stay DETECTED at
+that rung, which is the margin the 0.17 floor already holds. OpenAI stays on the flat 0.09 floor: extra SynthID-positive carriers
+clear at or below 0.06, including a 2-face file, and only the 9-face
+grid needs 0.075 (seed-stable on 0, 1, 2 via openai.com/research/verify).
+
+A separate content-balanced check on 2026-08-31 tested the exact production
+OpenAI and Meta floors over 19 prompt-matched image strata per provider. Each
+engine ran in its own sequential H100 invocation, and the comparison isolated
+the global stage because the shared face repair does not change with this choice.
+On OpenAI content, Chroma won SSIM and PSNR on 19/19 pairs, MAE on 18/19, edge
+F1 on 15/19, and LPIPS on 12/19. On Meta content, Qwen won LPIPS and edge F1 on
+18/19 pairs; Chroma's better PSNR on 16/19 did not overcome its systematically
+worse perceptual and edge preservation at the higher required floor. Exact
+two-sided sign-test p-values were 3.8e-6 for the OpenAI SSIM and PSNR directions
+and 7.6e-5 for the Meta LPIPS and edge-F1 directions. The tracked discovery
+inputs and manifests are in
+[`data/evaluations/engine-selection/`](../data/evaluations/engine-selection/),
+the run is reproduced by `scripts/engine_selection_study.py`, and paired analysis
+by `scripts/analyze_engine_selection_study.py`. These content files were locally
+re-encoded and are not watermark oracles; they validate fidelity at already
+oracle-calibrated floors, not removal by themselves. No content-stratum override
+is supported by this pass, so `auto` keeps the measured provenance-cohort table.
+
 ### SDXL plus Z-Image
 
 [`_internal/sdxl_zimage_pipeline.py`](../src/remove_ai_watermarks/_internal/sdxl_zimage_pipeline.py)
-runs the same two-stage recipe on an SDXL global pass. `SdxlZImagePipeline` subclasses
-`QwenZImagePipeline` and overrides only `_run_global` and `preload`, so the face stage
-is inherited rather than copied and cannot drift between the profiles; a test asserts
-the shared methods are the same objects.
+runs the same two-stage recipe on an SDXL global pass. `SdxlZImagePipeline`
+subclasses `TwoStageZImagePipeline` and implements only the global stage
+(`_load_global`, `_run_global`), so the face stage is inherited rather than copied
+and cannot drift between the profiles; a test asserts the shared methods are the
+same objects.
 
 Four things are architecture-bound and swap with the model: the ControlNet
 (`xinsir/controlnet-canny-sdxl-1.0`), the four-step distillation LoRA
@@ -1061,7 +1696,7 @@ avoid model downloads, so nothing exercised the loader. The lesson is narrower t
 was a dtype the subclass silently changed out from under it.
 
 Note what the seam is, because it decides where the fix belongs.
-`SdxlZImagePipeline._load_sdxl` hardcodes fp16 for its own ControlNet, VAE and
+`SdxlZImagePipeline._load_global` hardcodes fp16 for its own ControlNet, VAE and
 pipeline, so `self.torch_dtype` was never actually the global stage's dtype on this
 profile -- its only remaining readers were face-stage code. SAM was the second one:
 it never crashed, because it casts its own inputs and leaves through `.float()`, but it
@@ -1099,6 +1734,44 @@ 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**. Shipped as
+`QWEN_ZIMAGE_META_STRENGTH` with two routing paths: auto mode routes a file
+whose only provenance is the standalone AI IPTC tag onto the cohort
+(`vendor_for_strength` checks C2PA issuers first, so Google/OpenAI/Microsoft
+evidence always wins, and the tag's other users ship no invisible watermark
+this profile targets), and `--vendor meta` / `InvisibleOptions.vendor` names the
+cohort explicitly on stripped files, implying the scrub runs (naming the cohort
+asserts the watermark is present). sdxl-zimage has no measured Meta rung and an
+explicit meta vendor there falls to the conservative unknown 0.25. The default
+resolution-adaptive curve (~0.1305 at 2.56 MP) also clears every measured
+source, so default behavior needed no change. Oracle verdicts carry a
+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
@@ -1110,7 +1783,7 @@ within one pipeline.
 `_cache_static_prompt_embeddings` therefore persists what the text encoder produced
 under `_model_cache_dir()/prompt-embeddings`, keyed by cache version, model id,
 pipeline output params, and the exact prompt string. Once that file exists,
-`_load_qwen` and `_load_zimage` drop the text-encoder `ModelConfig` from the model
+`_load_global` and `_load_zimage` drop the text-encoder `ModelConfig` from the model
 stack entirely and serve the stored tensors instead. Measured on an H100 volume in
 August 2026, that removes **15.45 GiB** (Qwen2.5-VL) and **7.49 GiB** (Z-Image) of a
 **87.6 GiB** per-request read, worth a median **11.76 s** and **4.10 s** of load time
@@ -1162,7 +1835,8 @@ grain, unsharp masking, and adaptive polish helpers.
 
 `upscaler.py` held an optional Real-ESRGAN path, reachable only when enlarging a
 small image to the minimum-resolution floor. That floor existed to lift small
-inputs toward SDXL's ~1024 training size; when the SDXL profiles were removed it
+inputs toward SDXL's ~1024 training size; when the standalone SDXL and ControlNet
+profiles were removed (`sdxl-zimage` is a later, surviving profile) it
 was forced to 0 on every path, so the module, the `--min-resolution` and
 `--upscaler` options and the `esrgan` extra were all unreachable and went with
 it. Only the `max_resolution` cap can move geometry now, and it only scales down.

docs/photo-classify-hf/README.md

@@ -0,0 +1,243 @@
+---
+language:
+  - en
+license: apache-2.0
+library_name: transformers
+pipeline_tag: image-classification
+base_model: openai/clip-vit-large-patch14
+inference: false
+tags:
+  - clip
+  - image-classification
+  - ai-generated-content
+  - photo
+  - provider-attribution
+datasets:
+  - detection-datasets/coco
+---
+
+# Photo AI-versus-camera classifier
+
+Two heads, one call. Model 1 decides whether a **photograph** looks generated
+or camera-like. Model 2 names a provider only after Model 1 is DEFINITELY AI.
+
+This is not a SynthID decoder. It is not provenance. It is not a universal
+"AI or not" detector for receipts, UI, or digital art. The Python package
+[`remove-ai-watermarks`](https://github.com/wiltodelta/remove-ai-watermarks)
+loads these files through an explicit `classify` extra. `identify` never
+starts this model, including after a no-signal metadata scan.
+
+Library guide:
+[photo pixel classification](https://github.com/wiltodelta/remove-ai-watermarks/blob/main/docs/photo-classify.md).
+Research archive:
+[AI-generated image classifiers](https://github.com/wiltodelta/remove-ai-watermarks/blob/main/docs/ai-generated-image-classifiers.md).
+The demo Space
+[`wiltodelta/remove-ai-watermarks`](https://huggingface.co/spaces/wiltodelta/remove-ai-watermarks)
+is a watermark-removal UI, not this classifier.
+
+The training catalog is not in this Hub repository and is not on GitHub.
+
+## Intended use
+
+Use it when you have a photographic still and you want a pixel opinion after
+metadata is gone:
+
+- `label=ai` plus `provider=openai|google|muse-image|tc260` on a stripped ChatGPT,
+  Gemini, Muse Image, or TC260 photograph
+- `label=human` on camera photographs at a low false-positive rate
+- `label=unknown` when the detector is only POSSIBLY AI, or when 124-d
+  features cannot be extracted
+
+Do not use it to assert that a file is clean. Do not use it as a legal
+authorship test. Do not run Model 2 on every image.
+
+## Approach
+
+Content embeddings and forensic residuals answer different questions.
+
+CLIP-L, after a light vision-block fine-tune, separates **generated
+photographs** from **camera photographs**. It does not reliably separate
+generated photographs from receipts, UI, charts, or illustration. A ridge
+trained on that embedding at a 1% Open Images false-positive cut is the
+strongest Model 1 we measured. A small MLP on the same vectors, ANDed with
+the ridge, is the freeze DEFINITELY gate.
+
+The 124-d bank is a different feature: patch-local residual ratios (FFT band
+energy, comb contrast, autocovariance) on 256 px tiles. On that bank, OpenAI
+versus Gemini is easy (AUC 0.989 in the research sweep) while "AI or not" is
+the wrong job. Firefly and PixelBin sit near Google on those residuals, which
+is why a provider finder must keep foreign generators in the test and must
+abstain.
+
+The two heads therefore stay specialized:
+
+```mermaid
+flowchart TD
+  image[Photograph] --> m1[Model 1: CLIP-L-ft ridge AND MLP]
+  m1 -->|likely_human| human[label human, provider none]
+  m1 -->|possibly| unk[label unknown, provider none]
+  m1 -->|definitely| m2[Model 2: 124-d one-vs-rest focal]
+  m2 -->|openai google muse-image tc260| named[label ai plus provider]
+  m2 -->|no_ai or extract fail| aiOnly[label ai, provider none]
+```
+
+CLIP content space is the wrong place to train "receipt versus rest" or
+"UI versus rest" if the product contract is photographic. Those domains
+remain open. The shipped heads do not include a receipt specialist.
+
+Provider attribution tracks the **renderer**, not the front-end. Bing Image
+Creator rows signed Microsoft, OpenAI score as `openai`. Designer rows signed
+Microsoft, Google LLC score as `google`. Native Designer is mixed. There is
+no Microsoft pixel class. `openai` and `google` are provider classes.
+`muse-image` is Muse Image output, not a general Meta class. Instagram
+`made_with_ai` is not that class. `tc260` is the China AIGC label standard,
+not one producer: Doubao, Jimeng, Qwen, Kling, and others share that class.
+
+## Architecture
+
+### Model 1
+
+- Backbone: `openai/clip-vit-large-patch14`
+- Fine-tune: last two vision blocks, visual projection, post-layernorm
+- Preprocess: 224 letterbox, pad RGB `(123, 117, 104)`, BICUBIC, L2-normalized
+  `get_image_features` (`pooler_output` when present)
+- Ridge: linear probe on 768-d vectors, threshold `thr_oi_1pct` = 0.3056
+  from the locked `photo_dev_oi` 1% cut
+- MLP: `768-512-128-1` with dropout 0.3 / 0.1, threshold 5.9586, 1.67%
+  photo-dev quantile
+- DEFINITELY = ridge AND MLP. POSSIBLY = either. The public `label` is `ai`
+  only on DEFINITELY.
+
+### Model 2
+
+- Input: 124-d residual vector, or abstain if the image is smaller than
+  256 px or the extractor refuses
+- Heads: one-vs-rest focal MLP `124-64-1` per class
+  (`openai`, `google`, `tc260`, `meta_muse_image`, `no_ai`)
+- Decision: a class wins only if it beats `no_ai` by margin 0.30, then argmax
+  among those that passed
+- Public name `muse-image` is the Muse Image class. The freeze file still
+  keys that head `meta_muse_image`. `tc260` is the China AIGC label
+  standard (mixed producers), not a company. `no_ai` is not reported as
+  `human`; it becomes `provider=None` on an `ai` label (for example FLUX)
+
+## Training
+
+CPU. Two consecutive freeze runs from the same catalog and caches were
+byte-identical.
+
+| Item | Value |
+| --- | --- |
+| Catalog identity | sha256 of file bytes, 32,690 listed files |
+| CLIP-L embeddings keyed | 26,573 |
+| Detector seed | 20260940 |
+| Provider seed | 20260956 |
+| Sample seed for provider OpenAI/Google draws | 20260821 |
+| MLP epochs / width | 40 / 512 |
+| Provider focal gamma / epochs | 2.0 / 40 |
+| Private UI in train | 0. Replaced with 150 CC Flickr screenshots via Openverse, host `live.staticflickr.com` only |
+
+Flickr licenses in that replacement cell: CC BY 2.0 42, CC BY-NC 2.0 42,
+CC BY-SA 2.0 29, CC BY-NC-SA 2.0 28, CC BY-NC-ND 2.0 6, CC BY-ND 2.0 2,
+CC0 1.
+
+The pixel catalog is **not published on the Hub**. Head retrain uses
+sha256-keyed CLIP-L and 124-d caches plus `catalog.json` roles. The original
+files remain stored privately so embeddings and 124-d features can be rebuilt.
+Public named sources in those roles include COCO, Open Images, Kodak, Picsum,
+Hugging Face FLUX, Openverse CC Flickr, and Meta Muse API hold-out v3.
+In-house labeled OpenAI, Gemini, and TC260 photographs stay private. See
+[photo-classify-training.md](https://github.com/wiltodelta/remove-ai-watermarks/blob/main/docs/photo-classify-training.md).
+
+## Evaluation (run 1 = run 2)
+
+DEFINITELY is the shipped operating point.
+
+| Head | Cell | Result |
+| --- | --- | ---: |
+| Detector DEFINITELY | AI-test | 92.4% (n=1,847) |
+| Detector DEFINITELY | Open Images fresh | 1.3% (n=3,000) |
+| Detector DEFINITELY | Kodak | 0/24 |
+| Detector DEFINITELY | FLUX hold | 83.0% (n=300) |
+| Class | OpenAI test | 90.8% (345/380 of 381) |
+| Class | Google test | 90.9% (339/373 of 377) |
+| Class | TC260 test | 78.6% (298/379 of 384) |
+| Class | Muse Image hold-out v2 | 85.7% (66/77 listed 79) |
+| Class | Muse Image hold-out v3 | 89.4% (177/198) |
+| Class | Muse Image hold-out pooled | 88.4% (243/275 listed 277) |
+| Class | meme templates, ungated | 29.1% leak (86 of 97) |
+
+The ungated meme leak is why Model 2 must not run on every file. Gated on
+DEFINITELY, that leak is not a provider attribution.
+
+Ridge-only Model 1 at the earlier 1% Open Images cut (before the AND with
+the freeze MLP) is documented in the research page: Kodak 0/24, fresh 1.7%,
+AI-test 93.0%, FLUX 92.7%, Firefly 94.0%. Nobody in that sweep hit both
+≤1% fresh FPR and ≥90% TPR. The freeze AND is stricter on photos (1.3%
+DEF) at a small recall cost.
+
+## Limitations
+
+- **Photographs only.** Receipts, UI, scans of forms, maps, and community
+  digital art sit in the AI region of CLIP-L. A real thermal receipt can
+  score as AI. A photorealistic AI receipt can score as human.
+- **Not SynthID.** A `provider=openai` result means the pixels look like an
+  OpenAI-rendered photograph, not that a payload was decoded.
+- **Not provenance.** C2PA, IPTC, and visible marks stay on `identify`.
+- **124-d can refuse.** Some sizes and some images yield no vector. The
+  detector can still return DEFINITELY; provider is then `None`.
+- **Microsoft has no head.** Route by renderer, or use C2PA for the
+  front-end name.
+- **Open-world generators.** FLUX is a hold-out at 83% DEF, not 100%.
+  Unknown generators may land on `ai` with `provider=None`, or miss
+  DEFINITELY.
+- **`tc260` is mixed producers.** Doubao, Jimeng, Qwen, Kling, and others
+  share one label-standard head. A later retrain should split by
+  `ContentProducer`. Do not read `tc260` as a named manufacturer.
+
+## How to use
+
+Install the extra. First call downloads this repository into the Hugging
+Face cache, or reads `RAIW_CLASSIFY_WEIGHTS` if you already have the files.
+
+```bash
+uv tool install --force "remove-ai-watermarks[classify]"
+remove-ai-watermarks classify image.png
+```
+
+```python
+from pathlib import Path
+from remove_ai_watermarks.classify import classify_pixels
+
+result = classify_pixels(Path("image.png"))
+# result.label, result.detector, result.provider
+```
+
+`device` is a library parameter (`None` / `"auto"` / `"cpu"` / `"cuda"`),
+not a CLI option. Pin a Hub revision in production so a later upload cannot
+silently change the heads.
+
+## Files in this repository
+
+| File | Role |
+| --- | --- |
+| `clip-l-ft.pt` | HeadedCLIP state dict (CLIP-L plus unused linear head) |
+| `probe-weights-clip-l-ft.npz` | Ridge mean, scale, weights, `thr_oi_1pct` |
+| `detector.pt` | Freeze MLP |
+| `provider.pt` | Focal heads keyed `openai`, `google`, `tc260`, `meta_muse_image`, `no_ai` |
+| `operating-point.json` | Seeds, thresholds, margin |
+
+The image catalog is not in this repository.
+
+## License
+
+Apache-2.0 for the trained heads and this card. CLIP-L inherits its upstream
+license from [`openai/clip-vit-large-patch14`](https://huggingface.co/openai/clip-vit-large-patch14).
+Flickr replacement images are CC-licensed per file; they are not redistributed
+here.
+
+## Citation
+
+Package [`remove-ai-watermarks`](https://github.com/wiltodelta/remove-ai-watermarks).
+Protocol and rejected variants: [docs/ai-generated-image-classifiers.md](https://github.com/wiltodelta/remove-ai-watermarks/blob/main/docs/ai-generated-image-classifiers.md).
+Provider renderer study: [docs/synthid-classifiers.md](https://github.com/wiltodelta/remove-ai-watermarks/blob/main/docs/synthid-classifiers.md).

docs/photo-classify-hf/operating-point.json

@@ -0,0 +1,43 @@
+{
+  "freeze": "2026-08-31",
+  "task": "photo_ai_versus_camera",
+  "not": ["synthid_decoder", "provenance", "universal_ai_detector"],
+  "seeds": {
+    "sample": 20260821,
+    "detector": 20260940,
+    "provider": 20260956
+  },
+  "model1": {
+    "backbone": "openai/clip-vit-large-patch14",
+    "letterbox": 224,
+    "pad_rgb": [123, 117, 104],
+    "ridge_threshold_key": "thr_oi_1pct",
+    "ridge_threshold": 0.3056212276800537,
+    "mlp_threshold": 5.9586493237495395,
+    "mlp_width": 512,
+    "definitely": "ridge_and_mlp",
+    "public_ai_label": "definitely_only"
+  },
+  "model2": {
+    "feature_width": 124,
+    "margin": 0.3,
+    "classes": ["openai", "google", "tc260", "muse-image", "no_ai"],
+    "class_kind": {
+      "openai": "provider",
+      "google": "provider",
+      "tc260": "label-standard",
+      "muse-image": "model",
+      "no_ai": "negative"
+    },
+    "checkpoint_keys": {
+      "muse-image": "meta_muse_image"
+    },
+    "runs_only_after": "definitely"
+  },
+  "files": [
+    "clip-l-ft.pt",
+    "probe-weights-clip-l-ft.npz",
+    "detector.pt",
+    "provider.pt"
+  ]
+}

docs/photo-classify-training.md

@@ -0,0 +1,95 @@
+# Photo classifier training and data
+
+How the 2026-08-31 freeze was fit, what a retrain needs, and where those
+files come from. Inference is [photo-classify.md](photo-classify.md). The
+campaign log is [ai-generated-image-classifiers.md](ai-generated-image-classifiers.md).
+
+The shipped package does not include the catalog or the embeddings. Fitting
+the heads again uses the cache pack. The original pixels still have to be
+kept: a missing embedding, a new backbone, or an audit all need the files.
+
+## Retrain pack (caches)
+
+CPU retrain of both heads needs sha256-keyed matrices and the catalog of
+roles. That step does not open JPEG or PNG files. It is not permission to
+drop the pixels.
+
+| File | Role |
+| --- | --- |
+| `catalog.json` | 32,690 rows: `sha256`, `roles`, optional `family` / public `source` |
+| `embeddings-by-sha256.npz` | CLIP-L-ft 768-d vectors for Model 1 |
+| `extra-clip-l.npz` | CLIP-L extras for the 150 Flickr UI hashes |
+| `features-124d.npz` | 124-d residual vectors for Model 2 |
+| `probe-weights-clip-l-ft.npz` | Ridge mean, scale, weights, `thr_oi_1pct` |
+| `meta-split.json` | Meta train 217, hold-out v2 79, hold-out v3 198 |
+
+Run:
+
+```bash
+uv run python scripts/retrain_photo_classify.py --pack DIR --out DIR
+```
+
+Seeds are fixed: detector `20260940`, provider `20260956`. Two consecutive
+runs must be byte-identical.
+
+Not in the **published** retrain pack: raw photographs, COCO/Open Images/Kodak
+binaries, CORD, Danbooru. Those files stay in their public corpora or in the
+private freeze archive. Pixel rebuild of a missing embedding still needs
+`clip-l-ft.pt` and the original file.
+
+## Where the rows come from
+
+Identity is always sha256 of the file bytes.
+
+### Public, named corpora
+
+| Role | Source |
+| --- | --- |
+| `detector_photo_train`, `detector_photo_coco_hold` | COCO 2017 validation stills |
+| `detector_open_images_*`, `detector_photo_dev_oi` | Open Images photographs. Locked fresh never enters train |
+| `detector_photo_kodak` | Kodak lossless true color, 24 files |
+| `detector_photo_picsum_eval` | Picsum |
+| `detector_flux_hf_hold` | Hugging Face FLUX stills, hold-out |
+| Flickr UI cell (150) | Openverse `license_type=all-cc`, host `live.staticflickr.com` only |
+| Meta hold-out v3 (198) | Meta Muse Image API, eval-only, not in train |
+
+### In-house labeled photographs, not redistributed
+
+Provider OpenAI, Google, and TC260 train and test rows, and most detector AI
+train and test rows, are labeled photographic generations held privately.
+The published pack carries only their sha256, roles, and precomputed vectors.
+It does not carry the pixels.
+
+### Out of the freeze train
+
+CORD receipts, FUNSD forms, Danbooru, charts, and map tiles were measured as
+failure domains. They are not Model 1 train. A future universal router treats
+them as other domains, not as extra CLIP-L negatives.
+
+## What the freeze script does
+
+Historically `freeze_both_models.py` built the catalog from local paths, then
+trained. That campaign code is private and is not in this repository. The
+public entry is `scripts/retrain_photo_classify.py`, which skips catalog
+construction and fits the same heads from the pack above.
+
+1. Load CLIP-L-ft vectors by sha256. Fit the 768-512-128-1 MLP on
+   `detector_ai_train` plus extras versus `detector_photo_train` plus struct.
+   Threshold is the 1.67% quantile on `detector_photo_dev_oi`.
+2. AND that MLP with the frozen ridge in the probe file. DEFINITELY is both.
+3. Load 124-d vectors. Fit one-vs-rest focal heads for openai, google, tc260,
+   meta_muse_image, no_ai. Margin 0.30. The public class for the Muse Image
+   head is `muse-image`. `tc260` is the China AIGC label standard, mixed
+   producers, not one company.
+4. Repeat with the same seeds. Compare bytes.
+
+CLIP-L fine-tune of the last two vision blocks is earlier, seed 20260822, and
+is not repeated by the retrain script. The backbone file `clip-l-ft.pt` is an
+inference and embedding dependency, not a retrain-pack input.
+
+## Next retrain
+
+Keep the current `tc260` head until then. The next provider-head fit should
+split that catalog by `ContentProducer` (Doubao, Jimeng, Qwen, Kling, and
+the rest) instead of one label-standard class. Do not treat a `tc260` score
+as a named manufacturer.

docs/photo-classify.md

@@ -0,0 +1,126 @@
+# Photo pixel classification
+
+`classify` gives a pixel opinion on a **photograph**: camera-like, generated,
+or unknown, and optionally which renderer it resembles. It is a separate
+command from `identify`. Metadata inspection never starts it.
+
+This page is the library guide. The Hugging Face model card is the same freeze
+written for Hub publication: [photo-classify-hf/README.md](photo-classify-hf/README.md).
+Campaign notes and rejected variants live in
+[AI-generated image classifiers](ai-generated-image-classifiers.md).
+
+## When to use it
+
+Use `identify` for C2PA, IPTC, visible marks, and other provenance. Use
+`classify` when those signals are gone and the file is still a photograph.
+
+Do not use `classify` to prove a file is clean. Do not use it on receipts, UI,
+or digital art. Do not treat `provider=openai` as a decoded SynthID payload.
+
+## Install and run
+
+```bash
+uv tool install --force "remove-ai-watermarks[classify]"
+remove-ai-watermarks classify image.png
+remove-ai-watermarks classify image.png --json
+```
+
+```python
+from pathlib import Path
+from remove_ai_watermarks.classify import classify_pixels
+
+result = classify_pixels(Path("image.png"))
+print(result.label, result.detector, result.provider)
+```
+
+Missing extra raises `RuntimeError` with
+`pip install 'remove-ai-watermarks[classify]'`. `device` is a library
+parameter (`None` / `"auto"` / `"cpu"` / `"cuda"`), not a CLI option.
+
+Weights are not in git. First call downloads
+[`wiltodelta/raiw-photo-classify`](https://huggingface.co/wiltodelta/raiw-photo-classify)
+at the freeze revision pinned in `classify.py`, or reads
+`RAIW_CLASSIFY_WEIGHTS` if that directory already has `clip-l-ft.pt`,
+`probe-weights-clip-l-ft.npz`, `detector.pt`, and `provider.pt`. The training
+catalog is not published with the package.
+
+## What one call returns
+
+One request runs both heads. Model 2 runs only after Model 1 is DEFINITELY.
+
+```mermaid
+flowchart TD
+  image[Photograph] --> m1[Model 1 CLIP-L-ft ridge AND MLP]
+  m1 -->|likely_human| human["label human, provider none"]
+  m1 -->|possibly| unk["label unknown, provider none"]
+  m1 -->|definitely| m2[Model 2 124-d focal heads]
+  m2 -->|openai google muse-image tc260| named["label ai plus provider"]
+  m2 -->|no_ai or extract fail| aiOnly["label ai, provider none"]
+```
+
+| Field | Values | Meaning |
+| --- | --- | --- |
+| `label` | `ai`, `human`, `unknown` | Public verdict. `ai` only on DEFINITELY |
+| `domain` | `photo` | This freeze is photographic only |
+| `detector` | `definitely`, `possibly`, `likely_human` | Raw Model 1 gate |
+| `provider` | `openai`, `google`, `muse-image`, `tc260`, or `None` | Model 2, only if `label` is `ai` |
+
+`human` is camera-like under this contract, not a proof of authorship.
+`unknown` is POSSIBLY, or a domain this freeze does not support. `provider=None`
+on an `ai` file is often FLUX or another generator that is not one of the four
+heads, or a 124-d extract refusal.
+
+## Approach
+
+CLIP-L content embeddings separate generated photographs from camera
+photographs. They do not separate generated photographs from receipts or UI.
+A ridge on fine-tuned CLIP-L (last two vision blocks, 224 letterbox) is Model
+1. A small MLP on the same vectors, ANDed with the ridge, is the freeze
+DEFINITELY gate.
+
+Provider attribution uses a different feature: 124-d residual ratios on 256 px
+patches. OpenAI versus Gemini is a strong split there. "AI or not" is the
+wrong job on that bank, which is why Model 2 is gated.
+
+Provider names the renderer, not the product UI. Bing Image Creator signed
+Microsoft, OpenAI scores `openai`. Designer signed Microsoft, Google LLC
+scores `google`. There is no Microsoft pixel class. `openai` and `google` are
+provider classes. `muse-image` is Muse Image output, not a general Meta
+class. `tc260` is the China AIGC label standard, not one producer: Doubao,
+Jimeng, Qwen, Kling, and others share that residual class.
+
+## Evaluation
+
+Two CPU retrains were byte-identical. DEFINITELY is the shipped cut.
+
+| Head | Cell | Result |
+| --- | --- | ---: |
+| Detector DEFINITELY | AI-test | 92.4% (n=1,847) |
+| Detector DEFINITELY | Open Images fresh | 1.3% (n=3,000) |
+| Detector DEFINITELY | Kodak | 0/24 |
+| Detector DEFINITELY | FLUX hold | 83.0% (n=300) |
+| Class | OpenAI | 90.8% (345/380 of 381) |
+| Class | Google | 90.9% (339/373 of 377) |
+| Class | TC260 | 78.6% (298/379 of 384) |
+| Class | Muse Image hold-out v3 | 89.4% (177/198) |
+| Class | Muse Image hold-out pooled | 88.4% (243/275 listed 277) |
+| Class | meme templates, ungated | 29.1% leak |
+
+The ungated meme row is why Model 2 never runs on `human` or `unknown`.
+
+## Limits
+
+- Receipts, UI, scans, maps, and community art are out of contract.
+- Not SynthID, not C2PA, not `is_ai_generated`.
+- Images under 256 px cannot yield 124-d features, so provider abstains.
+- FLUX is a hold-out at 83% DEF, not a named provider class.
+- `tc260` is mixed producers under one label standard. A later retrain
+  should split it by manufacturer.
+
+`identify`, `has_invisible_target`, `all`, and `invisible` do not import this
+module. A no-signal provenance result stays unknown until you call `classify`
+yourself.
+
+Training data, the retrain pack (caches only, no images), and
+`scripts/retrain_photo_classify.py` are in
+[photo-classify-training.md](photo-classify-training.md).

docs/python-api.md

@@ -6,12 +6,29 @@ and pipeline modules are intended for maintainers and specialized workflows.
 Dependency groups are identical for the CLI and Python API. The default install
 covers metadata extraction, normalization, verdict logic, and stripping.
 Array/pixel APIs use `pixels`; visible removal uses `visible`; DWT-DCT detection
-uses `detect`; invisible image removal uses `qwen-zimage` and an NVIDIA GPU; and
+uses `detect`; pixel photo classification uses `classify`; invisible image removal uses `qwen-zimage` and an NVIDIA GPU; and
 visible video processing uses `video`. Video SynthID removal is a separate VAE
 path that still runs on CPU and combines `video` and `diffusion`. Add `heif`
 independently when path-based pixel APIs must decode HEIC, HEIF, or AVIF. See
 the complete [feature-extra matrix](installation.md#feature-extras).
 
+## Verify OpenAI SynthID
+
+```python
+import remove_ai_watermarks as raiw
+
+result = raiw.verify_openai_synthid("input.png", acknowledge_upload=True)
+print(result.status)
+```
+
+Official OpenAI JSON results expose `signal_family`,
+`provider_scope`, `backend`, `metadata_used_for_verdict`, and
+`pixels_preserved`. Remote transport and response failures raise `OpenAIProvenanceError`. Its
+`status_code`, `error_code`, `request_id`, `retry_after`, and `retryable`
+attributes let a caller implement bounded backoff or a circuit breaker without
+turning an API outage into a false `not_detected` result. One function call still
+performs at most one upload.
+
 ## Remove visible marks
 
 Install `remove-ai-watermarks[visible]` before using the visible-removal API.
@@ -112,11 +129,48 @@ raiw.remove_all(
 )
 ```
 
+`vendor="meta"` names a strength cohort explicitly (the measured Content Seal
+floor) for a stripped file whose provenance no longer carries the AI IPTC tag,
+and implies the scrub runs:
+
+```python
+raiw.remove_all(
+    "muse_output.webp",
+    "clean.png",
+    invisible=InvisibleOptions(vendor="meta"),
+)
+```
+
 `InvisibleOptions` carries only what `InvisibleEngine` itself takes, and uses the
 engine's own parameter names and defaults. `force`, which decides whether the
 engine runs at all, is a parameter of `remove_all` and `remove_batch` alongside
 `backend` and `sensitivity`.
 
+The complete field set, with the shipped defaults:
+
+| Field | Default | Effect |
+| --- | --- | --- |
+| `strength` | `None` | Denoising strength. `None` resolves per profile and vendor cohort. |
+| `pipeline` | `"qwen-zimage"` | Profile: `qwen-zimage`, `sdxl-zimage`, `chroma-zimage`, or `auto`. |
+| `vendor` | `None` | Strength cohort, and an assertion that the watermark is present. |
+| `seed` | `None` | `None` uses the certified seed 0. Removal near the floor is seed-dependent. |
+| `hf_token` | `None` | Hugging Face token for the model download; the environment and a local `.env` are read when unset. |
+| `humanize` | `0.0` | Analog film grain. 0 is off; 2.0-6.0 is the useful band. |
+| `unsharp` | `0.0` | Unsharp-mask sharpening. 0 is off. |
+| `adaptive_polish` | `None` | `None` lets the profile decide (off for `qwen-zimage`, on for `sdxl-zimage`); `True`/`False` override it. |
+| `max_resolution` | `0` | Cap the long side before diffusion. 0 keeps native geometry and the most detail. |
+| `controlnet_conditioning_scale` | `1.0` | Canny ControlNet conditioning on the global stage. Higher stays closer to the original structure and text. |
+| `cpu_offload` | `False` | Stream model components between CPU and GPU. Lower CUDA memory, slower. |
+| `tile` | `False` | Regenerate large inputs in overlapping tiles instead of downscaling. |
+| `tile_size` | `1024` | Tile side in pixels when `tile` is set. |
+| `tile_overlap` | `128` | Tile overlap in pixels. More overlap hides seams and costs time. |
+| `text_manifest` | `None` | Path to an operator-verified text manifest; see the text-restoration section. |
+| `fidelity_anchor` | `False` | Opt into the fidelity-anchor pass. |
+
+`tests/test_docs_cover_the_public_surface.py` fails when a field is added here
+and not to this table, because this seam had already drifted by eight fields
+before anything checked it.
+
 If AI metadata survives the strip, `remove_all` raises `MetadataStripIncomplete`
 **before** writing anything: an AI-readable output is worse than no output.
 
@@ -132,6 +186,34 @@ print(summary.invisible_unavailable)   # outputs that still carry the watermark
 `mode` is `all`, `visible`, `invisible`, or `metadata`. Pass a constructed
 `InvisibleEngine` as `engine` to load the model once for the whole directory.
 
+## Classify a photograph from pixels
+
+This is not provenance. `identify` does not call it. Install
+`remove-ai-watermarks[classify]` first.
+
+```python
+from pathlib import Path
+
+from remove_ai_watermarks.classify import classify_pixels
+
+result = classify_pixels(Path("input.png"))
+print(result.label, result.detector, result.provider)
+```
+
+`label` is `ai` only on a DEFINITELY detector result (ridge AND freeze MLP).
+POSSIBLY is `unknown`. Camera-like photographs are `human`. `provider` is
+`openai`, `google`, `muse-image`, or `tc260` only when `label` is `ai` and the 124-d
+head beats `no_ai` by the freeze margin. `tc260` is the China AIGC label
+standard (mixed producers), not a company. Otherwise it is `None`, including
+when 124-d extraction refuses the file.
+
+`device` is a library parameter: `None` / `"auto"` detect, `"cpu"` or `"cuda"`
+pin. It is not a CLI option.
+
+Missing extra raises `RuntimeError` with the quoted install command
+`'remove-ai-watermarks[classify]'`. Guide:
+[photo pixel classification](photo-classify.md).
+
 ## Inspect provenance
 
 The default installation evaluates file metadata. Add `visible`, `detect`, or
@@ -160,9 +242,26 @@ print(report.c2pa_validation)
 
 `c2pa_validation`, when present, reports `integrity`, `signature`,
 `signer_trust`, and `signer_validity` independently, plus the reader status
-codes. A valid hash and signature with an untrusted or expired signer is a
-medium-confidence signed claim. A hash or signature failure does not confirm the
-claimed platform or AI origin. Fallback parsing reports unknown validation
+codes. A valid hash and signature is a high-confidence signed claim; an
+unanchored or expired signer appears in `caveats` and in these fields, not as a
+lower confidence, because the reader ships no trust anchors to check against and
+`signer_trust` is therefore a missing input rather than a finding. A hash or
+signature failure, or a revoked signing credential, does not confirm the claimed
+platform or AI origin.
+
+A consumer must read `integrity_clashes`. When a credential fails validation,
+`is_ai_generated` becomes `None`, because a claim that cannot be tied to these
+bytes cannot establish origin -- the manifest may have been transplanted from a
+real AI image onto anything -- and the failure is reported in
+`integrity_clashes` instead. That is a different question from whether an AI
+watermark is physically present in the pixels, which is what
+`has_invisible_target` answers, and it stays fail-safe `True` on the same file.
+Reading only `is_ai_generated` turns a broken vendor manifest into silence.
+
+`c2pa_validation["state"]` is the reader's own aggregate and is carried for
+diagnostics only; no verdict is derived from it, because it collapses a
+transplanted manifest and a merely expired certificate into one `Invalid`, and
+its `Trusted` level depends on anchors no default installation has. Fallback parsing reports unknown validation
 dimensions, while a raw marker in an unsupported or malformed container can
 leave `c2pa_validation` as `None`.
 
@@ -233,6 +332,11 @@ the schema 1 serializer remains available for rolling upgrades. Asking a release
 an unsupported schema raises `ValueError` rather than silently returning another
 shape.
 
+Microsoft InvisMark declarations emit both the compatible generic `soft_binding`
+signal and the additive `invismark` signal. Consumers should use `invismark` to route
+the image through pixel removal; the generic signal also covers content fingerprints
+that must not trigger regeneration.
+
 A record carries metadata regions, not the primary coded-pixel stream: marker
 segments before the JPEG scan, every PNG chunk except `IDAT`, RIFF chunks except the
 coded image, the ISOBMFF provenance boxes, the container's trailer, the parsed EXIF tags the
@@ -310,8 +414,8 @@ Timings and spatial artifacts are opt-in. Artifacts include image-identifying da
 such as a thumbnail and perceptual hash; aggregate feature families do not.
 
 `identify_from_evidence` does not reopen the source file by default: it evaluates
-metadata only, and registered visible marks and pixel-backed invisible watermarks
-remain in the path-based `identify` call.
+metadata only, and the pixel-backed checks remain in the path-based `identify`
+call: registered visible marks and open invisible-watermark decoders.
 
 Pass `image_path` together with `check_visible` or `check_invisible` to add those
 pixel detectors on top of the SAME evidence. That is how a caller asking one file
@@ -529,8 +633,8 @@ independently and are not compared across detectors. Pass one of those explicit
 values to restrict the scan to a single provider. The Veo detector recognizes
 the current four-point diamond and the
 legacy `Veo` text. Seedance recognizes the boxed `AI` label, Dola recognizes
-its compact text label, Hailuo recognizes the composite MINIMAX/Hailuo label,
-and Kling recognizes its bottom-right logo, wordmark, and version suffix. Each
+its compact text label, Hailuo AI recognizes the composite MINIMAX/Hailuo AI label,
+and Kling AI recognizes its bottom-right logo, wordmark, and version suffix. Each
 variant has an independent synthetic silhouette and calibrated temporal policy.
 After each accepted frame is filled, `temporal_consistency=True` motion-aligns
 the preceding accepted fill and blends it only when the warped prior mask
@@ -553,7 +657,7 @@ to 8-bit SDR.
 
 ## Remove invisible watermarks
 
-Install `remove-ai-watermarks[qwen-zimage]`. Both profiles need it, and both
+Install `remove-ai-watermarks[qwen-zimage]`. All three profiles need it, and all
 need an NVIDIA GPU.
 
 ```python
@@ -562,7 +666,7 @@ from pathlib import Path
 from remove_ai_watermarks.invisible_engine import InvisibleEngine
 
 engine = InvisibleEngine(
-    pipeline="qwen-zimage",  # the default; the only other value is "sdxl-zimage"
+    pipeline="qwen-zimage",  # the default; also "sdxl-zimage", "chroma-zimage", or "auto"
     device=None,
     cpu_offload=False,
 )
@@ -586,7 +690,7 @@ engine = InvisibleEngine(
 )
 ```
 
-Both profiles are CUDA-only, so on a machine without an NVIDIA GPU `device=None`
+All profiles are CUDA-only, so on a machine without an NVIDIA GPU `device=None`
 resolves to `cpu` and construction raises. For the SDXL global stage instead of
 Qwen:
 
@@ -594,8 +698,10 @@ Qwen:
 engine = InvisibleEngine(pipeline="sdxl-zimage")
 ```
 
-The `qwen-zimage` extra is required for both profiles: each runs the same
-DiffSynth Z-Image face stage.
+The `qwen-zimage` extra is required for every profile, including `auto`: each
+concrete engine runs the same DiffSynth Z-Image face stage. `pipeline="auto"`
+selects chroma-zimage for OpenAI and Microsoft provenance and qwen-zimage
+otherwise, after the vendor is known and before strength resolution.
 
 The opt-in verified-text stage uses the same `text_manifest` argument as the CLI:
 
@@ -609,10 +715,12 @@ engine.remove_watermark(
 
 Install `remove-ai-watermarks[text-restoration]`. The manifest schema and safety
 constraints are documented in the CLI guide. The engine verifies its decoded RGB
-hash before loading the diffusion models and rejects SDXL, downscaling, and
-postprocessing combinations that were not evaluated. Tiling is allowed: the VAE
-donor uses the same overlapping tiles as the global pass. `InvisibleOptions` exposes the
-same field for `remove_all`; after a visible-stage edit, the manifest must be built
+hash before loading the diffusion models. Qwen and Chroma reconstruct the donor with
+the VAE already loaded for the one profile selected by `auto`; no second generative
+profile runs. The engine rejects SDXL, downscaling, and postprocessing combinations
+that were not evaluated. Tiling is also rejected because the combined
+tiled-restoration path has no provider-oracle calibration. `InvisibleOptions` exposes
+the same field for `remove_all`; after a visible-stage edit, the manifest must be built
 against the staged pixels rather than the pristine source.
 
 Use manifest schema 1 for manually reviewed text plus script metadata. Automated
@@ -624,7 +732,8 @@ default** (`fidelity_anchor=False`): that whole-frame blend was measured to
 return detector-visible OpenAI SynthID on poster-scale manifests (official
 Content Provenance API, 2026-08-19 - detected x6 with the anchor, clean x6
 without it, controls and base outputs validated in the same sessions). Pass
-`fidelity_anchor=True` to reproduce the 0.27.0 research behavior.
+`fidelity_anchor=True` with `qwen-zimage` to reproduce the 0.27.0 research
+behavior. Chroma rejects that Qwen-specific reproduction flag.
 
 ### Drafting manifest lines
 

docs/release-and-distribution.md

@@ -11,7 +11,7 @@ A release is complete only after all four published surfaces are verified:
 |---|---|---|
 | PyPI | The `remove-ai-watermarks` wheel and source distribution | `publish.yml` |
 | Homebrew | The `remove-ai-watermarks` formula in `wiltodelta/homebrew-tap` | `distribute.yml` |
-| Hugging Face Space | A factory rebuild of `wiltodelta/remove-ai-watermarks` against the new PyPI release | `distribute.yml` |
+| Hugging Face Space | The Space demo deployed on the new release through a requirements-pin bump in `wiltodelta/raiw-hf-space` | `raiw-hf-space` sync workflow; the pin bump is manual, `distribute.yml` only re-installs the pinned version |
 | ComfyUI Registry | A compatible release of `wiltodelta/ComfyUI-remove-ai-watermarks` with its own node version | `distribute.yml` and the node repository's workflows |
 
 The GitHub Release is the trigger and release record for this flow. Conda is
@@ -29,6 +29,10 @@ The package version appears in:
 Update the first two, then refresh the lock file with uv. Do not edit a
 line-number-specific location in `uv.lock`; its package order changes.
 
+Before choosing a version, verify it is absent from git tags, GitHub Releases,
+and PyPI. An unpublished remote tag still reserves that version; never move it,
+publish the next version instead.
+
 ## Publish flow
 
 PyPI publishing is triggered by a published GitHub Release, not by a tag push
@@ -58,9 +62,29 @@ PyPI API token from the repository.
 waits for the matching source distribution to appear on PyPI, then:
 
 - updates the Homebrew tap formula URL and SHA-256;
-- triggers a factory rebuild of the Hugging Face Space;
+- triggers a factory rebuild of the Hugging Face Space: this re-installs the
+  version pinned in the Space repo, it does NOT upgrade the demo;
 - synchronizes, tests, versions, and publishes the ComfyUI nodes.
 
+Upgrading the Hugging Face Space is a separate, manual step: bump
+`remove-ai-watermarks[visible,heif]` in `wiltodelta/raiw-hf-space` (`pyproject.toml`,
+`uv lock`, and the re-exported `requirements.txt`), then push. That repository's
+`sync-to-hf.yml` mirrors the files onto the Space, which rebuilds on the new
+pin. Its callback smoke tests run in that repository's CI on every push; they
+are the scenario check for the demo surface.
+
+The Hugging Face **model** `wiltodelta/raiw-photo-classify` is not part of that
+release fan-out. It holds the photo-classify freeze weights. The library extra
+`classify` downloads that snapshot on first use, or reads
+`RAIW_CLASSIFY_WEIGHTS`. Update the Hub repo only with
+`.github/workflows/publish-photo-classify-hf.yml` (`workflow_dispatch`,
+type `publish`). Full mode downloads the four weight files from the GitHub
+Release tag `photo-classify-freeze-2026-08-31` (or the tag you pass) and
+uploads them with the card in `docs/photo-classify-hf/`. Card mode updates
+the README and `operating-point.json` only. A library version bump does not
+upload new heads. Pin a Hub revision in production so a later freeze cannot
+silently change installed clients.
+
 The workflow can also be started manually with an optional version input.
 
 If a distribution job fails because a repository or Hugging Face credential is
@@ -109,11 +133,44 @@ without removing schema 1 so long-lived consumers can update separately. A packa
 release must never silently substitute its latest schema when a caller explicitly
 requests an older supported one.
 
-After publication, verify:
+After publication, the `verify-release.yml` workflow runs automatically once
+`distribute.yml` completes and checks every surface below. It can also be
+dispatched manually with a specific version. Every check fails the job; none of
+them warns and continues, because a surface nobody can confirm is not a verified
+surface, with one deliberate exception noted below. The ComfyUI check reads the
+registry's JSON API and asserts that some published node version declares this
+library release. It deliberately does NOT proxy through the sync workflow's run
+status: the node repository also runs that workflow on a daily schedule, so a
+green nightly run says nothing about whether this release was synced.
+
+Read `/nodes/remove-ai-watermarks/versions`, not `latest_version` on the node
+object. The registry reviews an upload before activating it, and
+`latest_version` reports only the active version, so during that review window a
+correctly published version is indistinguishable from one that was never
+uploaded. A new version therefore sits in `NodeVersionStatusPending` for a while
+after a release; the check reports that state in the run summary and passes,
+because it is the registry's queue rather than an incomplete release. A missing
+version, or any other status, fails. The full checklist for completeness:
 
 - both wheel and source distribution exist on PyPI;
 - the package version matches the tag;
 - the Homebrew formula points to the new source distribution;
 - the distribution workflow completed successfully;
 - the ComfyUI Registry node requires the new library version;
+- the Hugging Face Space serves the new release: its `requirements.txt` pin
+  matches (raw file via the HF API), the runtime stage is `RUNNING` after the
+  rebuild, and one live `identify` and one live `visible` API call succeed
+  against the running Space;
 - a clean install can run `remove-ai-watermarks --version`.
+
+A clean-install check run immediately after publication can fail with "no
+version of remove-ai-watermarks==X.Y.Z" even though the simple index already
+lists it: uv serves its cached pre-release view of the index. Re-run with a
+fresh cache (`UV_CACHE_DIR=$(mktemp -d)`) before treating it as a release
+failure.
+
+The ComfyUI sync run can fail the same way on its own: it resolves the version
+from the PyPI JSON API (which updates first) but installs the test dependency
+with pip against the simple index, whose CDN edges lag by minutes. Rerun the
+failed `distribute.yml` comfyui job once the simple index lists the release;
+nothing about the release itself is wrong.