Doctor Trigger: A Framework for Release-Bound Face Verification

What is Doctor Trigger?

Photos of faces get reposted, compressed, swapped and edited as they spread online. Platforms and investigators often cannot tell which copy is the one a person actually posted, and the evidence ends up scattered across many places.

Doctor Trigger hides an invisible code in a photo before it is posted and keeps a small private record. Later, any copy can be checked against that record. The check gives a clear result and a receipt that people can review.

Why “Doctor Trigger”?

Your face is yours, and so is the proof. The name describes the part you play.

Doctor

A doctor can only make a sound call because your medical history is on file. Here, that history is the private record you keep when you post. When a copy of your face shows up, the check reads it against your record and sorts it: this is yours, needs a closer look, or can’t tell yet. Without your record, no platform or investigator can say for sure.

Trigger

A tiny, invisible signal you place in your photo before posting. Nobody can see it, but later it is what lets you show “this one is mine” — and “that one isn’t me.”

You keep the history. You set the trigger. That is why your word can finally be backed by evidence.

From the paper: “Doctor evokes assessment against a retained history followed by triage; Trigger denotes the weak phase signal added before publication while preserving visual fidelity.”

How it works

Café selfie, the original photo — Your photobefore

The same café selfie with the invisible code added; it looks the same — What you postwith the hidden code

Step 1

Before you post

Doctor Trigger hides an invisible code in your photo. The two pictures look the same to anyone who sees them.

It also makes a small private record of the photo. That record stays with you and is never posted.

Café selfie as posted — What you postedConfirmed

A compressed repost of the same café selfie — A compressed repostConfirmed

Step 2

When a copy shows up

Say a friend sends you a copy of your selfie from another site. It was saved again and shrunk to a smaller file along the way.

Check that copy against your private record. The hidden code survives normal reposting and compression, so the copy still checks out.

The same café selfie with the face swapped — Face swappedface match 0.9535 (needs 0.9984)Unconfirmed

Step 3

The result

Every check ends in one of three plain answers.

ConfirmedThis is the photo you posted.
UnconfirmedSomething does not match, such as a swapped face. The copy is flagged for a person to review, with a receipt of what was checked.
UnavailableThe record or the copy needed for the check is missing, so no answer is given.

All people shown are AI-generated.

Hands-on

Try it yourself on real outputs of the public code.
All people shown are AI-generated.

Original vs. posted: drag to compare

Drag the slider across the photo. The left side is the original, the right side is the posted copy with the hidden code.

Posted image, carrying the hidden keyed signal

Original image, before the signal is added

OriginalPosted

Café selfie · PSNR 51.15 dB · SSIM 0.998

The hidden code is imperceptible. Each posted image carries the weak keyed signal, enrolled with the public Doctor Trigger code on a 512 px face crop, and stays at about 51 dB PSNR from its original. PSNR and SSIM are measured on the lossless PNG images; the images shown here are JPEG-compressed for size. All faces are AI-generated and do not show real people.

Demo on AI-generated faces

Four copies of each face, checked against its private record: the posted photo, a compressed repost, a face swap, and the original that was never posted.

Demo on AI-generated faces, run with the public code

Press briefing

Press briefing, face swapped — Face swapped C 0.9351 < 0.9984 G_s 1.97 ≥ 0.93 Unconfirmed face changed

Press briefing, never posted — Never posted C 0.9997 ≥ 0.9984 G_s 0.00 < 0.93 Unconfirmed hidden code not found

Café selfie

Café selfie, face swapped — Face swapped C 0.9535 < 0.9984 G_s 1.23 ≥ 0.93 Unconfirmed face changed

Café selfie, never posted — Never posted C 0.9997 ≥ 0.9984 G_s 0.00 < 0.93 Unconfirmed hidden code not found

Travel photo

Travel photo, face swapped — Face swapped C 0.9711 < 0.9984 G_s 1.18 ≥ 0.93 Unconfirmed face changed

Travel photo, never posted — Never posted C 0.9997 ≥ 0.9984 G_s -0.00 < 0.93 Unconfirmed hidden code not found

Beauty vlog

Beauty vlog, face swapped — Face swapped C 0.9379 < 0.9984 G_s 1.39 ≥ 0.93 Unconfirmed face changed

Beauty vlog, never posted — Never posted C 0.9997 ≥ 0.9984 G_s -0.00 < 0.93 Unconfirmed hidden code not found

Doctor Trigger at a glance. Each face is enrolled with the public code, then the verifier reads four copies against the private record. The posted face and its JPEG repost pass both checks. A face swap of the posted image fails spectral agreement C; the never-posted original still looks like the same face but carries no hidden code, so key projection G_s fails. Thresholds are the 1% quantiles over 144 benign copies (JPEG q85/q90, 0.75× resize) of 48 AI-generated faces. All faces are AI-generated and do not show real people; this demo is not part of the paper's benchmark.

Pick what reached the checker and see which answer comes back, and why.

Interactive explainer

Try the verification logic

Choose what reached the verifier. Both checks use thresholds calibrated for the benign transformations the system is intended to tolerate.

Supported benign copy. A released face after a benign transformation covered by calibration. Only once benign processing is pushed well past that calibrated range would the release signal or face-consistency score drop below threshold.

Face consistency

Matches the enrolled spectral reference.

Pass

Release signal

The enrolled key is present in the circulating copy.

Pass

Verifier response

Confirmed

The face is consistent with the publisher's enrolled release.

Video

Download MP4 All people shown are AI-generated.

In depth

For researchers

The full method, results and code.

Doctor Trigger lets publishers add an invisible keyed signal to each face before release and keep a private record, so they can later check whether a circulating face is still the version they published, or a swapped or edited copy.

Abstract

Face swapping and generative editing enable realistic facial manipulation, while online redistribution complicates publisher oversight of circulating face images. Existing approaches establish provenance, detect manipulation, recover embedded watermarks, verify image integrity, or disrupt unauthorized face manipulation. These capabilities do not necessarily establish consistency with a specific publisher-enrolled release, limiting the evidence available for verification and human review. To address this gap, we introduce Doctor Trigger, a framework for verifying circulating faces against private publisher-held release records. Before publication, the publisher embeds a weak keyed Fourier-phase signal in each face while preserving visual fidelity and stores its spectral reference. Afterward, verification compares the circulating face with that reference and uses key projection to measure retention of the release-specific signal. Therefore, relation and key evidence jointly help publishers identify suspicious copies for review, potentially reducing the circulation of manipulated images. Experimental results across FF++, DFDC, and Celeb-DF show that spectral agreement separates tested face swaps and generative manipulations from enrolled releases, while the keyed signal distinguishes published versions from their unreleased originals under the evaluated key-preserving benign transformations. Doctor Trigger complements provenance metadata with release-specific face verification and record-linked evidence for further assessment.

51.2dB

PSNR of the released image: visually near-identical

≥0.99

face-swap detection AUC within & across datasets

unreleased originals accepted by key projection

5.9ms

relation-only check, in memory

Motivation

Face swaps and generative edits are now realistic, and published faces get reposted, compressed and resized as they circulate. A publisher needs to answer one question: is this circulating face still the version we released?

Provenance metadata can be stripped along the way, and image-only detectors do not check a face against a specific release. Doctor Trigger lets the publisher keep a private record of each release and verify circulating copies against it.

Examples from the benchmark datasets

Original vs released image with amplified mid-band residual; template agreement passes for release and JPEG, fails for face re-rendering. — **The same steps on a benchmark face.** Left: a weak keyed signal is added before publication, and the released face looks virtually the same as the original. Right: the circulating copy is compared with the stored record. A JPEG copy passes (C_B = 1.000); a re-rendered face fails (0.930 < 0.997).

Invisible release signal

A secret per-face key slightly shifts the Fourier phase. The released face stays visually near-identical (51.2 dB PSNR).

Two complementary checks

Face consistency catches swaps and edits. Release signal tells the published version apart from its unreleased original.

Human in the loop

Confirmed copies pass routinely. Unconfirmed ones go to a reviewer. Unavailable means inputs are missing.

Method

Two stages. The publisher enrolls each face before release. Later, a requester, such as a person or platform, submits a circulating copy to the publisher's verifier and gets a status back.

Enroll

Before release, a secret per-face key slightly shifts the Fourier phase on a mid-frequency ring. The publisher keeps a private record: the spectral reference, the key and the thresholds.

Verify

A requester submits a circulating copy. Spectral agreement asks whether it is still the enrolled face; key projection asks whether the release signal is still there.

Decide & route

Confirmed only when both checks pass. Otherwise Unconfirmed and flagged for review, or Unavailable if the record or inputs are missing.

1Enroll: add a weak keyed signal

A key derived from a master seed and the sample ID picks a signed pattern on a mid-frequency ring of the Fourier spectrum. The phase at those frequencies is shifted by a tiny amount, then a fidelity gate lowers the strength until the release meets the fidelity targets.

The publisher keeps a private record: the spectral reference, the key and the thresholds. The original image is not needed later.

phase shift 0.0071–0.0235 radPSNR ≥ 35 dBSSIM ≥ 0.98

Enrollment pipeline: RGB FFT, ring selection, keyed phase shift, IFFT, blend, fidelity gate.

2Verify: two checks against the record

Spectral agreement C compares the query's phase with the stored template: is this still the enrolled face?

Key projection G_s projects the phase change onto the enrolled key: is the release signal still there? An ideal release scores about 1, the unreleased original 0, and wrong keys cancel out on average.

3Decide and route

A query is Confirmed only when both checks pass thresholds calibrated on benign processing (at most 1% benign rejection). Otherwise it is Unconfirmed and flagged for review, or Unavailable if the record or inputs are missing.

no trained model neededoptional learned record model

Verification: read the private record, verify face consistency and release signal, decide and route. — **Verification.** (a) Read the private record. (b) Check face consistency and the release signal, directly or with an optional record model. (c) Route the query. An optional image-only detector adds a separate review flag.

Results

7,366 real faces from FF++, DFDC and Celeb-DF. Each is verified as the genuine release and as a SimSwap face swap against the same record.

Face check

≥ 0.99 AUC

Catches face swaps on every dataset, without training.

Watermarks built to survive editing stay at 0.50, a coin flip.

Release check

99% → 0%

Tells the published version apart from its original.

Share of never-published originals wrongly accepted: similarity checks vs. the key.

Face check

Catches face swaps on every dataset.

How well each method separates a face-swapped copy from the genuine release. 1.00 means always right; 0.50 is a coin flip.

0.50 · coin flip1.00 · perfect

	FF++	Celeb-DF	DFDC
Doctor Trigger (direct)	1.00	0.99	0.99
LIDMark	1.00	0.74	0.84
FaceSigns	1.00	0.70	0.70
StegaStamp	0.91	0.57	0.52
SepMark	0.69	0.50	0.50
KAD-Net	0.54	0.50	0.50
WAM	0.50	0.50	0.50
VINE-R	0.50	0.50	0.50

Show table, including cross-dataset transfer

	Per-dataset			From FF++ →		From DFDC →
Method	FF++	CDF	DFDC	CDF	DFDC	CDF	FF++
StegaStamp	0.91	0.57	0.52	0.59	0.54	0.56	0.80
FaceSigns†	1.00	0.70	0.70	—	—	—	—
SepMark†	0.69	0.50	0.50	—	—	—	—
WAM†	0.50	0.50	0.50	—	—	—	—
KAD-Net†	0.54	0.50	0.50	—	—	—	—
VINE-R†	0.50	0.50	0.50	—	—	—	—
LIDMark	1.00	0.74	0.84	0.90	0.74	0.92	0.98
Ours, image-only S_df	0.99	0.98	1.00	0.68	0.76	0.93	0.95
Ours, direct spectral 1 − C_B	1.00	0.99	0.99	0.99	0.99	0.99	1.00
Ours, record model S_fake	1.00	1.00	1.00	0.98	1.00	0.97	1.00

†: fixed public weights; —: no dataset-specific training.

Also 1.000 AUC on StarGAN, UniFace, InSwapper and SD inpainting (FF++; the paper marks this comparison as exploratory).

Examples from the benchmark datasets

Released images, JPEG copies and re-rendered faces from FF++ and Celeb-DF with their sub-band template agreement. — **Benchmark examples (FF++, Celeb-DF).** Released images and their JPEG copies pass the template check; re-rendered faces fail it. Green and red borders mark acceptance and rejection.

Release check

Tells the published version apart from its original.

The original photo looks virtually the same as the release, so similarity checks accept it. Only the release carries the keyed signal.

≈ 99%

of originals accepted by similarity checks

Similarity to original (H)99.25%
Similarity to template (C)99.25%
Image similarity (SSIM)99.5%
Face identity (ArcFace)99.25%

of originals accepted by the key

99.5% of JPEG-compressed releases still pass, and all tested wrong keys are rejected.

Thresholds calibrated on JPEG copies.

Key sign pattern over the frequency ring, keyed displacement, template, query residual, and sign agreement with the correct and a wrong key. — **What the key sees**, on one FF++ face. (a) The key expands into a sign pattern over the frequency ring. (d) A benign copy's phase residual looks like noise, but its signs follow the key: **82%** of bins agree with the correct key (e), against **49%**, chance, with a wrong key (f).

Hands-on

How the hidden code is found

Walk through the six steps, then try your own repost settings. The ring is a drawing of the idea; the scores below come from running the public code on the AI-generated demo faces.

1 / 6

Try a repost

Repost quality 85 heavily compressedbest Resize 1.0× half sizefull size

Face

Hidden code

Face

The ring is a drawing of the idea. The scores come from running the public code on the AI-generated demo faces above: each copy is resized, saved as a JPEG at the chosen quality, then checked against that face's private record. As in the paper, the pass mark is tuned separately for each kind of sharing so that about 1 in 100 normal copies is flagged. Here it is tuned on 48 other AI-generated faces, so the pass mark is simply the lowest score any of their normal copies got; the 4 demo faces are kept out of the tuning. The line under the verdict counts, for the chosen setting, how the 4 demo faces fare; over all 50 settings, 4 of their 200 normal copies are flagged (2%), a little above the 1-in-100 target because 48 tuning faces give only a rough mark. All people shown are AI-generated. Readout: template reading C vs τ_C and key projection G_s vs τ_G, both recalibrated at every (JPEG quality, resize) setting on benign copies of 48 enrolled calibration faces: one shared lower-tail quantile ≤ 1% chosen so joint calibration rejection is ≤ 1%, which with 48 faces is the calibration minimum; the wrong code is deterministic_wrong_keys(key)[0]. Steps (a)–(d) are illustrative; the 82% / 49% sign agreement in (e)–(f) is the paper's FF++ example above.

Invisible

The release looks virtually unchanged.

51.2 dB PSNR, compared with 29.9–41.4 dB for the compared watermarking methods on the same face. Across all 7,366 enrollments the average is 51.20 dB (minimum 49.3 dB) with SSIM 1.00, and it holds at 128, 256 and 512 px on all three datasets.

Same FF++ face marked by eight methods with PSNR, and 10x amplified residuals. — Residuals amplified 10× below each face. Payload and reference budgets differ across methods.

Lightweight

Verification runs on a CPU, with no model weights.

The relation check takes 5.9 ms on a CPU using the in-memory record. The compared watermark decoders run on a GPU with 68–3833 MiB of weights.

	Time (ms) ↓		Memory (MiB) ↓
Method	Embed	Verify	Weights	GPU
StegaStamp	9.3	2.6	208	375
FaceSigns	4.4	1.7	72	102
SepMark	12.5	17.8	550	653
WAM	14.9	17.0	360	450
KAD-Net	17.0	12.5	563	650
VINE-R	79.3	10.7	3833	4569
LIDMark	6.0	5.9	68	93
Ours, relation check	66.7‡	5.9‡	0	0
Ours, record model	66.7‡	149.9‡	0.04	0

Means over 20 256² crops. ‡ Xeon Gold 6248R CPU; other methods on an A5000 GPU.

Robustness

Reliable after common sharing, with known weak spots.

Nearly all manipulations are rejected after re-encoding, screenshots, JPEG and one repost. Repeated reposting, H.264 compression and cropping weaken face-swap rejection.

	Manipulation rejected ↑
Channel	Face swap	Reenactment	SD inpaint	Benign pass ↑
Lossless re-encode	100%	100%	100%	99%
Credential stripping	100%	100%	100%	99%
Screenshot (1.25×)	100%	100%	100%	99%
JPEG q85	100%	100%	100%	99%
Social repost (0.75×, q70)	98.5%	100%	100%	99%
Repost of a repost	63%	100%	100%	99%
H.264 intra, per image	11%	99.5%	97.5%	99%
Center crop 90%	6%	99%	81.5%	99%

200 FF++ releases; cutoffs target 1% benign rejection. Selected channels shown.

BibTeX

@misc{lee2026doctortrigger,
  title  = {Doctor Trigger: A Framework for Release-Bound Face Verification},
  author = {Lee, Chia-Ming and Lin, Chia-Yu and Huang, Hung-Kai and Ku, Yi-Ting and Liang, Yu-Chen and Hsu, Chih-Chung},
  year   = {2026},
  eprint = {2610.16336},
  archivePrefix = {arXiv},
  primaryClass  = {cs.CR},
  url    = {https://arxiv.org/abs/2610.16336},
  note   = {Project page: https://ming053l.github.io/Doctor-Trigger/}
}