fidelity_metrics.py at each engine's clean strengths: klein keeps Latin and
Cyrillic sign lettering better on two Google carriers, but loses every face
comparison and the verified CJK text, which the 512-pixel LPIPS had hidden.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The fourth Google carrier clears at 0.25, so the klein operating point with
the usual cross-source margin is 0.40, where the limiting carrier is at
LPIPS 0.270 against qwen-zimage's 0.183. klein is not a replacement global
stage for either vendor. Also record that Gemini's image-check allowance is
per account and the new "checks on similar images" quota wording.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Three of four Google carriers clear with klein at or below 0.20, where it
matches qwen-zimage's PSNR at 0.35, beats its LPIPS, and keeps the objects
qwen-zimage redraws. The fourth is detected at 0.10 and inconclusive at 0.20,
so there is no Google operating point yet.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Stock Flux2KleinInpaintPipeline feeds the clean source back as reference
tokens, so it copies the source and OpenAI SynthID survives strength 0.30.
Without those tokens klein clears OpenAI between 0.05 and 0.20, at lower
fidelity than qwen-zimage at its floor. Google is unmeasured: the Gemini
Verify AI tool answered with a tool error or quota limit, which also casts
doubt on two of the earlier color-restoration "inconclusive" rows.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Collect provider samples from Higgsfield, Runway and Dreamina plus Google
Photos, Gemini, Grok and YouTube re-encodes into data/captures/2026-09 with
a hash-checked manifest, and use them to fix attribution and false positives:
- Attribute aggregator outputs: Higgsfield job metadata, Dreamina's
re-signed manifests, Runway's own C2PA signer, TC260 video producers.
- Veto any visible video mark when a valid C2PA claim names another vendor
(a Gemini Omni clip read as Sora on steam), and gate Kling and Hailuo
matches on edge, anchor and white-label evidence.
- Veto the Gemini sparkle when trusted provenance names another vendor.
- Report SynthID as present for Google Photos AI edits: Google's checker
found it on all four measured edits, though manifests record no action.
- Add Vidu video and Wan image marks, TC260 audio placements, and record
the AIGC key in metadata records.
- Document the research sweep, the Dreamina badge decision, and verified
Google statements on SynthID in Photos.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Repair image and metadata publication contracts, detection routing, research
artifact validation, release verification, and the published agent skill.
Refresh the dependency lock and reconcile documentation with verified behavior.
Add regression coverage and record the completed audit and corrected VideoSeal
measurements. Preserve the existing Accelerate and Lightning versions.
Validation: Ruff and Pyright pass; 2358 tests pass with 3 skipped. The maintenance
gate exits 2 on the documented Accelerate and Lightning security findings.
The Content Seal manifest named the production GPU worker in its provenance
column and in two row keys, several docstrings described their sources as user
uploads from the private corpus, and that corpus was called by the storage
product holding it. Each is now what a public reader can check: a pipeline and
strength, material that is not publication-cleared, and a private corpus. The
corpus test follows the renamed rows. Deployment and tier detail goes the same
way, since which backend each hosting tier can afford is a product decision,
not a library fact.
Twelve harnesses that need a cloud GPU account leave scripts/. The research
pages that cite their findings name them as harnesses kept outside this
repository and stop implying a reader can rerun them; the tracked inputs and
recorded verdicts remain the durable record, and the offline analysis step
stays here with its test. A development invariant states the rule so the next
harness is not added back.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Three withheld zero-face carriers, all confirmed zero-face with the same YuNet
detector the adaptive arms gate on, first cleared at 0.045 / 0.06 / 0.11. The
zero-face operating point is 0.11 + (0.11 - 0.045) = 0.175, which the shipped
0.20 already covers, so that floor now rests on both content classes rather than
only the face-bearing carriers it was derived from.
The content split this cohort kept suggesting does not survive the measurement:
the two classes differ by 0.025 while the spread WITHIN each is 0.065 and
0.0625, so a face split would key on a variable explaining about a quarter of
the variation it leaves behind.
The methodological point is the durable half. The fixture-only view of zero-face
OpenAI content spans 0.015 of boundary; the real carriers span 0.065, four times
wider. A narrow fixture spread yields a small worst-clean-plus-one-spread margin
and a false impression of homogeneity, and that impression is what made a split
look justified twice.
Every verdict is the public verifier's separate SynthID line with Content
Credentials reported not detected alongside, over RGB-identical metadata-stripped
positive controls.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The four-fixture Google calibration showed a clean YuNet face-count split:
both zero-face text cards need 0.25 first-clean, both face fixtures clear
at 0.12 with zero cross-source spread. The adaptive arm routes face
content (face_count > 0) to the measured 0.125 rung, saving 6.4 dB PSNR
and doubling face identity cosine vs the flat 0.40 floor. The split is
Google-SynthID-specific: OpenAI's face fixture was harder than its text
fixture, so no other cohort gets an adaptive arm.
Extract TwoStageZImagePipeline shared base from QwenZImagePipeline so all three
profiles are siblings, not a chain. Add ChromaZImagePipeline on that base with
diffusers ChromaImg2ImgPipeline bf16, neutral calibrated prompt, guidance 5.0,
four effective steps with Diffusers truncation compensation, no Canny.
Flat vendor floors from the 2026-08-29/30 oracle calibration across OpenAI
(0.09), Microsoft InvisMark (0.125), Google (0.40), Meta Content Seal (0.17),
seed-stability verified on Meta, full-path face-stage interaction clean through
the Gemini oracle. Research record in docs/chroma1-engine-research.md with the
matched-strength addendum showing Chroma1 regenerates better per unit strength
but its boundaries scatter wider than qwen's. Fix text-manifest guard to reject
chroma-zimage at the boundary, update all profile references from 'both' to
'all three' across src, docs, README, and python-api.
