On this page
Provenance Review
Purpose and reading guide
Provenance Review helps a person inspect generated content, understand the strength of each available observation, and authorize a precisely described derivative while retaining the original. Its central design commitment is evidence with a declared scope. An invisible character, a statistical watermark result, a signed assertion, and a provider's response metadata answer different questions. The interface keeps those answers separate.
The service is useful for investigating unexpected formatting, evaluating an owned text-watermark deployment, inspecting attribution claims, validating a compatible signed text assertion, and retaining an intelligible record of approved changes. It also provides a common review framework around existing image and video provenance capabilities. It makes no universal AI-authorship determination and provides no universal watermark-removal guarantee.
This reference combines the research background, implemented architecture, user workflows, calibration philosophy, operating boundaries, and limitations. Service names describe logical responsibilities. Several responsibilities can share a process; the architecture does not require a distributed microservice deployment.
Use Tools > Provenance Review for pasted text and supported media. Completed chat responses expose the shared text review in their content-management controls, and archived responses expose it in the response reader. The Flowchart > Provenance Review tab provides seven architecture/workflow sub-tabs with pan, zoom, fullscreen, and SVG downloads.
| Reading goal | Relevant sections |
|---|---|
| Understand what a SynthID result can establish | Research background, SynthID Text, evidence model |
| Inspect and edit a response | Local inspection, review transaction, user workflows |
| Operate an owned detector | Compatible verification, calibration, hosting and access |
| Evaluate a signature | Signed text provenance, media and Content Credentials |
| Preserve an investigation | Capture, history, export, and restoration |
| Assess uncertainty or a failure | Limits, failure semantics, research references |
Default capability: local observations and exact selected editing are available without a statistical profile. Live statistical verification remains disabled until the operator supplies an authorized owned profile, its pinned artifacts, and qualifying calibration evidence. Public research code alone supplies no compatible production Gemini verifier.
Philosophy, threat model, and evidence boundaries
An investigation should preserve the evidence it is trying to interpret. Accordingly, the canonical response remains available after every Confirm or Reject decision. A derivative receives its own content hash and lineage. Applying a selected text edit never silently replaces the provider conversation history or the response used for provider continuation.
Four principles govern the implementation:
- Observation precedes attribution. Exact character presence is directly inspectable. A generator's identity or an intentional encoding scheme requires additional evidence.
- Claims carry prerequisites. Statistical evidence requires compatible tokenization, configuration, a detector, and calibration. Signature evidence requires an actual signed envelope, a content binding, and an explicit trust policy.
- Consent is specific. Editing consent binds an exact preview. Network consent separately authorizes sending a captured representation to the configured verification host.
- Uncertainty is a normal result. Unavailable, insufficient, inconclusive, invalid, and failed operations remain visible. They never become a reassuring absence result.
The main risks include accidental linguistic corruption, false attribution, stale results attached to a changed source, unsupported classifier scores presented as probabilities, secret-key disclosure, verifier feedback used as an oracle, forged or copied attribution labels, and unsigned archives mistaken for freshly authenticated evidence.
The boundary also matters in the opposite direction. A person possessing a statistical watermark's configuration can create text bearing that configuration's signal. A compromised signing key can authenticate false assertions. An operator can curate an unrepresentative evaluation set. Cryptography and statistics each provide useful evidence under assumptions; neither mechanism independently establishes the truth of all content.
Provenance results should support informed review. High-stakes decisions about people, authorship, misconduct, or legal responsibility require broader evidence, a documented error model, and an appropriate review process.
Research background and mechanism taxonomy
The SynthID family
SynthID is Google's family of watermarking technologies for generated media and text. Its text mechanism encodes statistical structure during language-model generation. Its image, audio, and video mechanisms operate in their respective signal domains. A text detector cannot inspect a watermark embedded in pixels or audio samples, and a media detector cannot establish a token-level mark from a pasted paragraph.
Google's product description identifies text watermarking in the Gemini app and web experience. Product and endpoint coverage can differ and can change. The supported verifier must establish compatibility for the actual source under investigation. 1 2
There are three particularly important SynthID Text implementations:
| Implementation | Purpose and signal | Detection prerequisites | Important boundary |
|---|---|---|---|
| Google's deployed SynthID Text integration | A keyed statistical pattern introduced into next-token selection | A compatible authorized verifier or matching production configuration and detector | Public algorithm descriptions supply no automatic access to the deployed product's profile |
| DeepMind's research reference | Reproducible watermarking and mean, weighted-mean, and Bayesian detection experiments | Matching configuration and tokenization; trained parameters for Bayesian detection; suitable thresholds | The reference describes research-only mix-ins and static configuration; its hash accumulator has no cryptographic-security guarantee |
| Official Transformers integration | A generation logits processor, watermark configuration, and compatible detector building blocks | Trusted tokenizer, matching configuration, trained detector, and representative calibration | An available class or example checkpoint does not establish compatibility with a provider's production watermark |
Google recommends the official Transformers integration for production integration. That recommendation concerns the implementation building blocks. A deployment remains responsible for access controls, artifact qualification, representative evaluation, limits, and accurate claims. 3 4 5
Related text watermarking approaches
The following schemes provide useful context for interpreting a request to "check for watermarks." They have different signal spaces and compatibility requirements.
| Mechanism | How a signal is introduced | How it is detected | Interpretation |
|---|---|---|---|
| KGW and related green-list schemes | A keyed context-dependent vocabulary subset is promoted during token sampling | Reconstruct green-token membership and evaluate its excess under an appropriate null model | Evidence for the configured green-list scheme |
| Distortion-free inverse-transform or exponential-minimum sampling | Tokens are coupled to a keyed pseudorandom sequence under a specified sampling construction | Align the text with the configured random sequence and evaluate correlation or a permutation statistic | Evidence for that sequence and construction, subject to the paper's assumptions |
| Semantic watermarking, including SemStamp | Candidate sentences are accepted according to selected embedding-space partitions | Reproduce the embedding, segmentation, partition, and statistical decision process | Semantic-partition evidence for a compatible profile |
| Character and formatting channels | Invisible characters, spacing, substitutions, or other formatting choices carry information | Decode the agreed codebook or inspect the underlying characters | Character presence alone leaves intentional encoding unverified |
| Explicit labels and response headers | Text or metadata asserts a generator, identifier, watermark, or signature | Parse the claim; separately authenticate its origin and content binding | An unverified assertion until supporting verification succeeds |
| C2PA and other signed provenance | A signed manifest or envelope binds assertions to an artifact | Validate the signature, asset binding, and applicable trust policy | Integrity and provenance assertions from a signer |
| Post-hoc AI classifiers | No intentional watermark is required; a model learns distributional similarities | Apply a classifier evaluated for the target population | A classifier outcome with domain-dependent errors |
The original KGW paper describes softly promoting a randomized set of green tokens and testing the resulting bias. The distortion-free research describes inverse-transform and exponential-minimum constructions with explicit assumptions and generation budgets. SemStamp uses sentence embeddings, locality-sensitive hashing, and rejection sampling to improve robustness to some paraphrases. These are separate mechanisms, with separately evaluated error behavior. 7 8 9
A stylistic tendency, repeated phrase, or generic classifier score cannot authenticate SynthID. Ordinary prose can contain every visible term used to discuss provenance. A copied label saying "SynthID" or "signed" supplies no proof of key possession or provider identity.
SynthID Text in detail
Generation and keyed structure
A language model generates vocabulary token IDs. Tokens can represent word fragments, words, punctuation, or other text. A word-counting regular expression cannot reproduce an arbitrary model tokenizer.
SynthID Text uses context-dependent pseudorandom g-values and a sequence of watermarking layers during tournament-style sampling. Its configuration includes the key sequence, n-gram length, sampling-table parameters, and repetition history. Tokenizer identity and implementation behavior are also part of compatibility.
The key list determines the watermarking depth. The public integration guidance discusses using approximately 20 to 30 distinct random keys as a practical tradeoff. Configuration should be protected because disclosure can permit replication of the watermark. Strong random key selection and careful operational controls remain important even though the research reference's hash accumulator supplies no cryptographic-security guarantee. 3 4
The watermark is carried by the resulting token choices. It can be present in text consisting entirely of ordinary visible characters. There is no universal SynthID suffix, Unicode code point, regular expression, or removable token tag.
Reconstruction and masking
A compatible detector reconstructs g-values from token IDs and the matching configuration. The published detection flow excludes initial positions without enough context, handles end-of-sequence positions, and masks repeated contexts according to the configured algorithm. A padded batch also needs correct attention-mask handling.
The usable sample count is therefore the number of eligible contexts after masking. Character length and word count cannot substitute for that count. Repetition can make a long response contain little independent evidence.
Detector inference can use the tokenizer, g-value processor, and trained detector without loading the full generation language model for every inspection. Producing representative training examples can still require an owned generator and correctly labeled watermarked and unwatermarked outputs.
This implementation's owned profile uses a declared decoded-response re-tokenization contract. It adds no special tokens and applies no prose normalization. Decoding and re-encoding can produce a different token sequence from the one sampled during generation. Qualification must evaluate that actual round trip instead of assuming that original sampled IDs are recovered.
Scoring and calibration
The research reference includes mean and weighted-mean detectors, as well as a Bayesian detector. Weighted-mean thresholds need to account for effective sample length. A Bayesian detector requires representative labeled examples for its watermark configuration. A detector can be shared across models using the same tokenizer only when the training and evaluation populations adequately represent those models. 3 4
A Bayesian model score depends on the detector's fitted likelihoods and prior. A z-score and a p-value describe different quantities. A score of 0.99 from a particular model should retain its score-type label. It supplies no general 99% probability that a person used AI.
Compatible statistical results in the application identify the profile, input contract, calibration revision, effective sample counts, score type, operating threshold, and measured error bound. A positive state is enabled only after those prerequisites pass.
Robustness and limitations
The public research and integration guidance describe robustness to some cropping, limited edits, and mild paraphrasing. Thorough rewriting or translation can reduce detectability. Longer, diverse outputs usually provide more opportunity to encode and detect a signal. Short factual answers, constrained text, copied quotations, code, and low-entropy outputs can provide weak evidence. 1 3 4
These observations are evaluation-dependent. They provide neither a guarantee against deliberate manipulation nor a reliable recipe for certifying removal. A lower score after editing describes that detector's response to the edited input.
Evidence model and result states
The evidence register separates the following classes.
| Evidence class | Directly established information | Additional requirements for a stronger claim |
|---|---|---|
| Exact text observation | A supported character, sequence, or narrowly formatted claim is present at the reported location | A decoder or authenticated source is needed to establish intentional watermarking or attribution |
| Unverified provenance assertion | A footer or allowlisted header makes a claim | A compatible signature, provider attestation, or other authenticated binding |
| Compatible statistical result | A registered profile's evaluated decision procedure returned the stated result for this capture | Valid domain assumptions, effective sample eligibility, calibrated operating conditions, and controlled configuration |
| Trusted text signature result | A configured key authenticated a supported assertion bound to the exact capture | Appropriate key governance and independent assessment of the assertion's factual meaning |
| Media credential result | A format-specific service found structures or validated a manifest under its reported capability | The actual artifact, compatible verifier, content binding, and trust anchors |
The statistical result model has explicit states:
| State | Meaning |
|---|---|
Unavailable |
A necessary authorized capability, profile, runtime, or input is absent |
NotApplicable |
The selected evidence mechanism does not apply to the artifact or requested scope |
InsufficientText |
Too few usable contexts remain for the calibrated decision procedure |
Inconclusive |
The score lies in an uncertainty band or no validated bucket covers the declared input |
EvidenceDetected |
Evidence for the registered mark exceeds the calibrated positive threshold |
NoEvidenceDetected |
The tested profile's score falls below its negative threshold |
VerificationFailed |
A supplied claim, signature, binding, or verification contract failed validation |
Error |
The requested operation could not complete correctly |
Operational HTTP failures appear as explicit errors. They do not create a new successful evidence record. A prior recorded result remains associated with its original capture and timestamp, and the interface identifies it as the last recorded result.
NoEvidenceDetected is scoped to the selected compatible test. Other schemes may be unsupported, the detector may miss a compatible mark, or the content may be ineligible. Human authorship is a separate question.
The signature and statistical lanes remain independent. A signature can authenticate a false generator assertion. A statistical mark can be replicated by someone with the configuration. Neither result should silently upgrade an ordinary metadata claim into authenticated provider identity.
Component architecture
Figure 1. Canonical capture, local observation, review, verification, and history are separate responsibilities. Select the figure to inspect both lanes in the interactive diagram viewer.
| Logical service or component | Responsibility | Trust boundary |
|---|---|---|
| Canonical Capture | Preserve the decoded response, representation, completion scope, stable identity, and hash | A decoded text capture differs from a transport-byte capture |
| Local Observation Analyzers | Inspect supported Unicode, explicit claim syntax, normalization state, and permitted metadata | Observations establish presence; intent remains contextual |
| Removal Eligibility Policy | Decide whether a supported observation can participate in the selected removal policy | Language-sensitive content stays protected |
| Proposal Builder | Produce exact ordered edits, expected removed text, source identity, expiry, and result hash | No source mutation occurs during preview |
| Review Transaction Controller | Validate Confirm or Reject against the reviewed source and proposal | A changed source, selection, or acknowledgment invalidates a preview |
| Private Profile Registry | Resolve administrator-approved identities, pinned artifacts, input contracts, and calibration evidence | Clients supply a registered ID rather than an arbitrary path or executable |
| Verification Gateway | Enforce access, consent, fixed routes, input limits, rate limits, cancellation, and response bindings | Sending text to the host is an explicit action |
| Owned Detector Runtime | Load compatible local artifacts, reconstruct features, and return a typed model score | Watermark keys and weights remain on the trusted host |
| Calibration Tooling | Build versioned held-out operating evidence with split and error-budget checks | Training, threshold selection, and final evaluation remain independent |
| Signed Text Verifier | Validate the supported ES256 envelope, content binding, validity interval, and configured signing key | Public-key trust is explicitly configured |
| Session History and Export | Preserve originals, independent derivatives, decisions, and scoped reports | Imported unsigned records remain historical assertions |
| Format-Specific Media Services | Inspect image/video structures and invoke optional compatible native validation or processing | Structural presence, cryptographic trust, and visible-region processing remain separate |
The standalone text workspace and the chat readers use the same local evidence and transaction rules. The application presents a consistent review contract across hosting modes while keeping their execution locations explicit.
Capture, representation, and scope
What is captured
A text capture identifies its decoded assistant-response string, hash representation, review timestamp, completion status, model identifier when supplied, and a permitted request identifier. Only an allowlist of noncredential response metadata is retained in the review document.
The capture represents the response channel. User prompts, tool outputs, reasoning, rendered Markdown, and application-added content can have different origins and transformations. They should be investigated as separate scopes rather than silently folded into the same statistical test.
Completed turns are distinguished from partial, canceled, interrupted, and restored responses. A partial response can still contain useful observations, but its sample length and completeness must remain explicit.
Encoding and locations
For well-formed Unicode, the content hash covers UTF-8 re-encoding of the declared decoded string. Locations use UTF-16 offsets and columns, matching the application text model. Eligible findings additionally expose their UTF-8 byte position. Supplementary Unicode scalars occupy two UTF-16 units.
The service applies no automatic normalization. NFC normalization can change code-point identity even when the visual appearance is similar. NFKC and other compatibility transformations can have broader semantic effects. Any proposed normalization would require a separately reviewed transformation and diff.
Malformed UTF-16 receives an explicitly declared raw-code-unit hash rather than a silently repaired UTF-8 representation. Its hash input has a reserved invalid-UTF-8 prefix followed by little-endian code units, separating that domain from valid UTF-8 text. The code units remain available in application memory for review. Derivation, UTF-8 export, and remote verification are blocked. Browser transport or rendering may display replacement glyphs; that display supplies no lossless recovery of malformed provider bytes.
The text review does not preserve a byte-for-byte network response or original generation token IDs. Such evidence would require a separately captured transport or token channel. A browser paste can also normalize line endings before the application receives the text.
Stable identity and source changes
A capture identity is persisted independently of an in-memory conversation turn's UI identity. A change to the source produces a different capture context and invalidates pending work. Hash and revision checks prevent a result or edit from silently attaching to another response.
Figure 2. Exact observations, removal eligibility, and compatible verification are distinct lanes. Unavailable or uncertain verification still leaves local review usable.
Local observation and removal eligibility
The local analyzer reports supported hidden, directional, mathematical, variation, and tag characters, together with visible references and narrowly recognized attribution lines. A finding explains its location and limits. Findings are paged into the register so a bounded review remains usable without silently truncating the analysis.
Supported local evidence
| Observation | Possible legitimate role | Default treatment |
|---|---|---|
| Leading U+FEFF | Decoding or transport residue; context can still matter | Individually selectable transport candidate |
| Trailing U+0000 padding | Residual transport padding | Individually selectable transport candidate |
| Embedded U+0000 | Downstream text-processing behavior | Preserved |
| U+200B zero-width space | Word or line-break opportunities, including scripts with no visible spaces | Advanced per-occurrence deletion with acknowledgment |
| U+2060 word joiner | Suppression of a line break | Advanced per-occurrence deletion with acknowledgment |
| U+00AD soft hyphen | Discretionary hyphenation | Advanced per-occurrence deletion with acknowledgment |
| Interior U+FEFF | Legacy no-break or joining behavior | Advanced per-occurrence deletion with acknowledgment |
| U+200C and U+200D | Natural-language shaping and emoji composition | Protected |
| Directional marks, embeddings, overrides, and isolates | Bidirectional text order and punctuation behavior | Protected |
| Variation selectors and tag sequences | Grapheme identity, ideographic presentation, and emoji sequences | Protected |
| Invisible mathematical controls | Function application, multiplication, separation, or mathematical meaning | Protected |
| Combining grapheme joiner and similar script controls | Combining-mark order or script-specific behavior | Protected |
| Nonbreaking spaces | Legitimate language, number, and typography rules | Protected |
| Provenance-related wording | Discussion, quotation, or an attribution assertion | Review-only ordinary wording |
| Narrow complete-line provenance claim | An explicit but unauthenticated attribution statement | Advanced deletion of the exact line content |
The advanced claim syntax recognizes complete lines in bracketed or HTML-comment form, such as [provenance: ...]. A discussion containing those words elsewhere remains ordinary content. The parser authenticates no signer and infers no provider identity.
Unicode security standards and the Unicode Emoji specification explain why indiscriminate stripping is dangerous. Joining controls can alter words, emoji ZWJ sequences can represent a single intended grapheme, and variation or tag characters can be essential to presentation. Identifier-security recommendations also require care when applied to natural-language prose. 11 12
Educational statistics
The optional educational panel can compute phrase-repetition and public-seed word-bias statistics. These are explicitly separated from compatible SynthID results and from the published sample catalog.
The repetition example measures repeated three-word sequences after a minimum word count. The teaching watermark hashes lowercased five-word sequences with a public seed, counts eight binary layers, and counts repeated sequences once. It requires enough distinct sequences before displaying its teaching statistic.
That mechanism illustrates selection bias. Its word splitting, public seed, and uncalibrated threshold provide no production-provider verification. Educational observations cannot populate the compatible statistical evidence state.
The preview, Confirm, and Reject transaction
Figure 3. The reviewed proposal binds a source identity, policy, exact spans, and resulting content hash. Editing consent remains independent of verification consent.
Selection and preview
Every removal begins unselected. The conservative policy permits individually selected leading BOM and trailing NUL candidates. An advanced policy separately enables eligible formatting and attribution deletion, with an explicit acknowledgment of meaning, wrapping, or attribution risk.
Preview reconstructs the selected findings against the current canonical capture. It rejects unknown or duplicated selection identities, unsupported observations, overlapping edits, invalid ranges, and changes that would split a Unicode scalar.
The preview records:
| Field | Purpose |
|---|---|
| Preview identity | Identify the exact reviewed proposal and support idempotent confirmation |
| Capture identity and revision | Bind the edit to the current source context |
| Original hash | Establish the declared original representation |
| Policy identity | Distinguish conservative and acknowledged advanced operations |
| Ordered edit spans | Define exact expected removed text and locations |
| Result hash | Identify the exact proposed derived copy |
| Acknowledgment state | Bind the applicable risk acknowledgment to the preview |
| Expiration | Require a fresh review after the preview's validity window |
The before/after view makes invisible selected characters visible through annotations. Red changed spans identify source material selected for deletion. Green removal-position labels show where those spans disappear. Preserved hidden characters are also made visible where necessary for intelligibility.
Annotations are view data. They are excluded from copied and downloaded response text. Existing line endings and untargeted code units remain unchanged.
Confirm
Confirm revalidates the source identity, revision, original hash, selected policy, expected text, nonoverlapping spans, acknowledgment, expiry, and result hash. It then creates a separate derivative and records the decision.
Repeating Confirm for the same already-confirmed preview is idempotent. A preview with a Reject decision cannot later be confirmed. A new preview is required.
The original response, raw response views, and provider continuation remain canonical. A person can explicitly copy a derivative into a future prompt through the available copy action. That is a separate editorial and conversational action.
Reject
Reject records the decision and discards the pending proposal. It creates no derivative. The original remains unchanged.
Changing the source or selection, revoking acknowledgment, starting a replacement turn, or expiring the preview prevents use of the stale proposal. Cancellation and asynchronous result checks also keep obsolete verification work from mutating a new capture.
What an approved edit establishes
An exact text deletion can establish that the selected code units were removed and that the remaining code units were preserved. It cannot establish the absence of every statistical, semantic, character, or media watermark.
A derived copy inherits no verified signature or statistical result. Reports attached to the original remain scoped to the original. Altering an artifact can break a signature's content binding even when its metadata is retained.
Compatible statistical verification
Figure 4. Offline preparation and administrator approval precede a user's bounded verification request. A failed qualification gate leaves the profile unavailable.
Approved profile contract
The private registry resolves a configured profile ID. A client cannot select an arbitrary model name, artifact directory, URL, executable, checkpoint, or configuration file.
An owned profile binds the following information:
| Profile information | Why it matters |
|---|---|
| Profile identity and algorithm | Selects the intended compatible scheme |
| Input-contract identity | Defines decoded text, re-tokenization, special-token policy, and scoring scope |
| Tokenizer directory digest | Prevents silently changing the vocabulary or tokenization behavior |
| Trained detector digest | Pins the actual evaluated weights and associated configuration |
| Watermark-configuration digest | Binds the private g-value construction and sampling settings |
| Exact declared package versions | Detects incompatible Transformers, tensor-runtime, or safe-weight-loader changes |
| Manifest fingerprint | Provides a single identity for the declared profile contract |
| Calibration artifact | Connects the profile to held-out thresholds, domains, lengths, and error bounds |
| Administrator approval | Prevents a merely present file from automatically enabling an evidence claim |
The runtime uses CPU inference and loads local-only tokenizer and safe tensor artifacts. Remote model code and implicit model downloads are disabled. Its environment excludes inherited host credentials, disables implicit Hugging Face tokens and telemetry, and places any package cache beneath the approved private root.
Artifact directories have bounded size and file counts. The worker recomputes pinned digests before inference. A missing dependency, changed artifact, incompatible package version, or failed model load produces an explicit unavailable/error path.
Capability discovery checks registration, approval, manifest compatibility, and calibration metadata. It does not run a full model-health evaluation. Actual execution supplies the additional runtime and artifact checks.
Input contract and scoring
The currently supported owned statistical profile is the Bayesian SynthID Text construction under the decoded-response re-tokenization contract. It consumes the complete assistant response, adds no special tokens, and applies the official EOS and repeated-context masks. Batch preparation additionally accounts for padding and attention.
The worker returns the manifest fingerprint, source hash, input-contract identity, token count, eligible-context count, and finite model score. The gateway validates those bindings before recording the result.
The caller predeclares the supported domain. The service does not independently prove that the text belongs to the declared language or genre. Incorrect declarations undermine the interpretation of calibration. Operators should restrict supported populations and qualify any automatic domain routing as part of the full pipeline.
The selected domain and eligible-context count choose a nonoverlapping calibrated bucket. A score above its positive threshold yields compatible watermark evidence. A score below its negative threshold yields a scoped no-evidence result. Intermediate scores remain inconclusive. Inputs outside coverage remain insufficient or inconclusive; no unsupported score is promoted into a positive result.
The pipeline performs no sliding-window search and no best-score search across arbitrary keys. Manual repeats or adaptive selection require their own error accounting.
Calibration, evaluation, and research rigor
Independent stages
Training fits the detector. Calibration selects the operating thresholds. Final evaluation measures the chosen pipeline against held-out data. Reusing the same examples for these roles can produce misleading performance claims.
The owned training command requires at least 10,000 curated examples covering known watermarked and unwatermarked generation classes. This follows the scale of the official integration guidance, while actual adequacy still depends on the use case. The trained output is a new safe-weight artifact.
Batch scoring preserves known generation labels, example IDs, declared domains, source hashes, and prompt-family identifiers. Calibration enforces disjoint IDs, source hashes, and declared prompt families across training, calibration, and final evaluation. Semantic near-duplicate detection and reliable prompt-family assignment still require dataset curation.
Outputs are created as new artifacts. Existing files are not overwritten. A failed batch does not publish a partial score file as a completed result.
Representative populations
Qualification should include:
- Human writing and unwatermarked model outputs from the intended population.
- Owned-key watermarked outputs with matching generation settings.
- Wrong-key, wrong-tokenizer, and wrong-checkpoint controls.
- Short, factual, repetitive, code, table, quotation, and mixed-source responses.
- Supported languages and genres, with declared eligible-length intervals.
- Cropped, edited, paraphrased, translated, and otherwise transformed samples.
- Decoded/re-tokenized round trips matching the deployed input contract.
- Canceled and partial responses, if the deployment will interpret them.
The absence of a false positive in a small test set supplies little evidence for a very low false-positive claim. Distribution shift, template leakage, and adaptive test selection can invalidate apparently strong results.
Thresholds and uncertainty bands
The calibration tool selects a conservative positive threshold from calibration negatives. It uses a separate lower threshold to create an uncertainty band. Final evaluation counts false positives and true positives independently.
The negative threshold helps avoid forcing every score into a binary answer. It supplies no universal false-negative guarantee. Recall and the treatment of missed marks require separate measurement and domain-specific interpretation.
Eligible-length boundaries are predeclared. Multiple domain/length strata need adequate positive and negative evaluation evidence. Ineligible evaluated captures are counted explicitly rather than represented as successfully tested examples.
Error and confidence budgets
The default proposed family-wise false-positive target is 0.0001. A deployment can select a different approved operating target within the configured bounds.
The registry size defines the profile family. Each profile must meet its allocated portion of the family-wide error budget. Adding or removing a registration changes that declared family and requires deliberate calibration requalification.
The tool computes a one-sided Clopper-Pearson false-positive upper bound and sensitivity lower bound. It allocates confidence across both metrics, registered profiles, and declared buckets, so an independently stated interval is not silently presented as a simultaneous global assurance. Positive controls must establish a sensitivity lower bound above the false-positive upper bound.
For a single bucket with zero observed false positives, the one-sided upper bound can be written as:
upper = 1 - (1 - confidence)^(1 / negative_count)
For one bound at 95% confidence, approximately 30,000 independent representative negatives with zero false positives support an upper bound near 0.0001. The default joint two-metric pipeline allocates 97.5% confidence to each bound for one profile and one bucket, requiring approximately 37,000 such negatives. More profiles, more buckets, nonzero false positives, or stronger simultaneous confidence require more evidence.
The host recomputes the count-based bound and rejects incompatible claims, overlapping buckets, reused dataset digests, a mismatched profile fingerprint, an unsupported input contract, and an incompatible family size.
A failed held-out gate produces an explicit failure instead of an approved artifact. Evaluation outcomes should be retained. Tuning a revised pipeline against the same already-observed final set compromises independence; a future revision needs fresh held-out qualification.
A p-value is different from a predictive probability
A simplified green-list test is often described by:
z = (green_hits - green_fraction * eligible_count)
/ sqrt(eligible_count * green_fraction * (1 - green_fraction))
That expression is specific to a simplified green-list null model. Dependencies, repetition, seeding policy, and search affect its calibration. It cannot replace SynthID's g-value construction or trained detector.
A false-positive rate is conditional on a negative population. A posterior model score depends on assumptions and a prior. A positive predictive value also depends on prevalence.
For illustration only, suppose a particular mark occurs in 0.1% of inspected texts, sensitivity is 90%, and the single-test false-positive rate is 0.1%. Under those hypothetical assumptions, approximately 47.4% of positive outcomes would actually carry that mark. These are arithmetic assumptions, without a measured SynthID performance claim.
Upgrades and drift
Tokenizer changes, detector retraining, key rotation, package updates, input processing changes, model-family additions, and new domains can alter results. A changed profile fingerprint requires corresponding calibration evidence. Hardware or numerical differences can still matter around a threshold and should be included in operational qualification.
The service's approval gate checks artifact consistency and declared metrics. The operator remains responsible for truthful labels, representative data, sufficient independence, and scientifically defensible evaluation design.
Signed text provenance and trust
The application supports an explicitly defined compact JWS envelope for an owned text assertion. It uses ES256 with the P-256 curve, an application-configured public key, and a content hash over the declared decoded-text UTF-8 representation. 15
The protected header identifies the algorithm, configured key ID, and text-provenance envelope type. The payload includes a schema version, source hash, representation, generator assertion, issued-at time, and expiration.
| Check | Required behavior |
|---|---|
| Structure | Exactly three base64url segments with unambiguous object properties |
| Algorithm | The supported ES256/P-256 construction |
| Header policy | The documented type and known fields; unsupported critical behavior is rejected |
| Content binding | The signed source hash and representation match the exact current capture |
| Trust | The signing key is enabled in the application trust configuration |
| Validity | The assertion is current, respects bounded clock skew and lifetime, and fits the key's approved interval |
| Signature | The actual signed input verifies with the configured public key |
| Claim format | The generator assertion fits the declared bounded text contract |
The maximum assertion lifetime is 30 days, with a bounded future clock-skew allowance. Operators control key activation, validity intervals, and revocation by updating the configured trust policy and restarting the host where required.
Successful validation means that the configured key authenticated the bound assertion under that policy. It does not independently establish the factual truth of the generator assertion. A configured key name should not imply Google or another provider's identity without an independently governed trust relationship.
The application performs verification, without issuing a new text signature for a derivative. Signing authority remains a separate operator-controlled responsibility.
C2PA media credentials continue through their format-specific services. A pasted statement mentioning C2PA can omit the original manifest and asset binding, so its visible text alone supplies no cryptographic context.
History, export, and restoration
Figure 5. The capture and its independent review records survive supported history and archive paths. Import validates consistency before exposing historical evidence.
A review document contains the canonical capture, Confirm/Reject decisions, derived copies, recorded statistical reports, and any supplied supported signed envelope. A derived copy identifies its source hash, result hash, policy, exact edits, and confirmation time.
Completed-turn capture and session snapshot services preserve those records alongside response diagnostics. The same document is available in live responses and archived response readers. Legacy archives can load without inventing a prior provider-verification result.
If another turn is running, an archived review remains in memory and its automatic history write waits for the next completed session snapshot. This avoids marking an active generation as finished. Downloading the review JSON provides an immediate independent file.
Supported imports validate the version, canonical hash, capture identity, edited spans, policy eligibility, derived content, result hash, and decision consistency. Duplicate or contradictory decisions are rejected. Malformed Unicode is blocked from lossy UTF-8 export.
An unsigned archive can be edited by its owner or an attacker. A successful structural import therefore establishes internal consistency, without authenticating every stored assertion. Restored statistical and signature reports are labeled historical and unverified. A fresh successful verification updates its own live result lane; it does not silently authenticate an unrelated older report.
The JSON review export contains captured text and can contain sensitive content. It excludes verification access keys and private watermark configuration. The original text download and each derivative download contain underlying text, without visual diff annotations.
The standalone paste workspace is an in-memory investigation with explicit downloads. It does not automatically save pasted text into browser storage. Chat retention follows the existing user-controlled session history and archive behavior. A response-only autosave should not be mistaken for an independently exported complete investigation.
Hosting, privacy, and authorization
Figure 6. Local review and remote verification have separate execution and permission boundaries. The private worker receives a minimal environment and approved local artifacts.
Execution locations
| Responsibility | Interactive-server host | Browser WebAssembly host |
|---|---|---|
| Local text observation | Runs within the application server's shared evidence core | Runs within the browser's shared evidence core |
| Preview and editing rules | Shared exact-text transaction semantics | Same shared semantics |
| Source presentation | Browser view of the canonical captured response | Browser view of the canonical captured response |
| Statistical inference | Explicit request to the protected application verifier and owned worker | Explicit same-origin request when a compatible trusted backend is deployed |
| Signed text assertion | Protected host verification with configured public-key trust | Same protected service when available |
| Private profile keys and weights | Trusted host only | Excluded from client assets |
| Local offline behavior | Requires the normal server connection | Available after required application assets are cached |
The WASM deployment routes the fixed text-verification API to its bundled private host when that host is available. A purely static or offline deployment retains local review and reports external verification as unavailable.
Explicit transmission consent
Discovering capabilities sends no captured text. Statistical or signature verification requires a separate consent control, identifies the application verification destination, and sends the current capture with its identity and hash.
Verification access keys are supplied for this dedicated service, held in memory, and excluded from session exports and ordinary profile persistence. The host never substitutes a provider model key or an ambient managed identity.
Production verification requires an authorized dedicated access key. Local Development hosts can explicitly permit development requests, with that setting ineffective as anonymous production authorization.
The gateway uses fixed application routes and registered profile IDs. It imposes request size, rate, process-time, and concurrency limits. It disables redirects and proxies for its internal application client, and the detector worker loads only approved local artifacts.
Data minimization
Operational logs record bounded failure categories and decision counts rather than captured text, private watermark keys, request bodies, or verification access keys. Even content hashes can be correlatable; deployments should apply their data-classification policy to any telemetry or exported investigation.
The worker's environment is reduced to necessary runtime settings. Offline package loading, implicit-token suppression, telemetry controls, safe-weight loading, and the approved private root reduce accidental network and credential exposure.
Those controls do not replace dependency review, host isolation, access governance, or secure storage. Installed Python and model-runtime dependencies need an operator-reviewed, locked environment and normal maintenance.
Media provenance and Content Credentials
Figure 7. Text assertions, token statistics, image metadata, video structures, and cryptographic credentials use compatible services with separate result states.
Image review
Image review captures original supported image bytes, records their hash, and inspects supported metadata and C2PA-related structures. Structural detection identifies candidate information; it does not by itself validate a signature, trust a signer, or detect every watermark in the image's pixels.
Metadata removal is an explicit derivative operation. EXIF, orientation, ICC color information, or attribution metadata can influence interpretation. Removing metadata is not a general proof that an image's visual appearance or provenance properties are unchanged.
Video review
Video review preserves original supported ISO BMFF media, inspects C2PA structures and container metadata, and can use compatible tools for stream/frame inspection. Browser-local bundled tools and optional native host tools have different limits and capabilities.
Compatible native C2PA validation requires the actual artifact and configured validation capability. Signature validity and trusted-signer status remain separate results. Optional derivative signing additionally requires signing configuration and authorization.
Selected metadata processing and visible-region treatment create separate, approval-gated derivatives. Reinspection and media checks validate the supported operation. Invisible provider watermarks can remain after those transformations.
Provider policy can make an operation review-only. Applicable terms, contractual obligations, licenses, and attribution requirements remain part of the authorization decision.
What C2PA establishes
C2PA Content Credentials can carry assertions about origin, edits, and AI use in a cryptographically bound manifest. A compatible verifier checks integrity, asset binding, and trust according to its supported policy.
The C2PA explainer emphasizes that the mechanism validates provenance structure and tamper evidence rather than making a value judgment about every assertion's truth. Missing or removed credentials also leave the content's origin unresolved. Soft bindings can complement embedded manifests, so deleting one metadata structure may leave discoverable provenance elsewhere. 10
Text, image, audio, and video watermarking should therefore remain separate from generic metadata cleanup. Each mechanism needs its own compatible verifier and an explicitly scoped claim.
User workflows
Inspect a pasted assistant response
- Open Tools > Provenance Review > Text.
- Paste the exact intended response or choose a published SynthID-generation sample.
- Enable Inspect provenance signals.
- Read each finding's location, rationale, and removal eligibility.
- Keep verification states unavailable unless a compatible service is actually configured.
- Select supported observations individually, preview the changes, and choose Confirm or Reject.
- Download the original, approved derivative, or review JSON as needed.
Selecting a sample replaces the editor's content and starts a different capture context. The catalog contains three exact published responses about watches, English contractions, and poetry from the SynthID key-A and key-B arms of xlr8harder's Qwen3-4B corpus. It contains no added provenance labels or artificial invisible-character payloads. Source metadata appears separately: pinned record, generator, published watermark key ID, generated token count, original content hash, and generation-manifest link. 16
The source corpus declares a 30-layer, five-token n-gram SynthID configuration and a sampling table produced by the official Transformers processor. The corpus publisher reports watermark-enabled generation. This is community research evidence and remains independently unverified in the application. Selecting a sample never adds a positive detector report. A compatible tokenizer, configuration, detector, and qualifying calibration remain necessary for an actual verification result.
Contains information from xlr8harder's Qwen3-4B SynthID corpus, made available under the ODC Attribution License. The retained responses are unchanged, including their original Unicode, punctuation, spacing, and line breaks. Their content can contain model errors.
Enable Wrap long lines in the editor toolbar to fit long logical lines to the available width. Wrapping is display-only: it inserts no newline characters and changes no captured text, content hash, copied text, or export. The gutter continues to number logical lines. Line navigation and signal markers remain aligned after wrapping, scrolling, and resizing.
Review a completed or archived chat turn
- Open the response's content-management controls or its archived response reader.
- Enable the shared provenance inspector.
- Inspect the canonical response and any existing review history.
- Authorize exact selected changes through the diff workflow.
- Keep the original as the provider continuation. Use a deliberate copy action if a derived text should become input to another request.
- Preserve the full session or review export when investigation history is important.
Request authorized statistical verification
- Obtain access to an operator-approved owned profile.
- Enter the dedicated verification access key in the memory-only field.
- Discover capabilities without transmitting the captured text.
- Select the available profile and a supported predeclared domain.
- Read the destination and explicitly authorize sending the capture.
- Request verification.
- Interpret the returned state together with eligible contexts, profile identity, score type, calibration, error bound, and limitations.
A busy, inaccessible, incompatible, or failed verifier leaves the original unchanged. Cancellation and source-race protection prevent an obsolete result from being attached to a new capture.
Validate a signed text assertion
- Obtain the actual compatible compact signed envelope from its issuer.
- Preserve the exact text to which it is supposed to bind.
- Discover the trusted host's signature-verification capability.
- Authorize transmission of the text and envelope.
- Verify the signed assertion and inspect its key identity, binding, validity, and limitations.
- Reverify after restoration or content changes as appropriate.
Copying a claim that says "signed" is insufficient. A derivative's text change can invalidate the original assertion's content binding.
Qualify an owned statistical deployment
- Establish ownership, authorized use, and a supported generation configuration.
- Curate representative known-label data with independent prompt families and source examples.
- Train or obtain a compatible detector using the owned configuration.
- Pin tokenizer, trained weights, watermark configuration, package versions, and the actual input contract.
- Score disjoint training, calibration, and final evaluation splits.
- Predeclare domains, eligible-length strata, uncertainty policy, family size, target error, and confidence allocation.
- Generate a qualifying held-out artifact or retain the explicit failed qualification.
- Register and approve the exact profile on the trusted host.
- Exercise unavailable, wrong-profile, short-input, cancellation, timeout, and drift cases before enabling operational claims.
- Requalify deliberately when a profile or population changes.
Administrator approval authenticates the deployment decision. It does not relieve the operator of responsibility for the scientific validity of the evaluation.
Limits, failure semantics, and operational safeguards
Implemented bounds
These are application limits and defaults, rather than performance or detection-accuracy guarantees.
| Boundary | Current behavior |
|---|---|
| Local text inspection | At most 200,000 UTF-16 units and 4,096 observations; excess produces an explicit error |
| Owned statistical tokenization | At most 32,768 token IDs; input is not silently truncated |
| Bayesian feature expansion | At most 16,777,216 token/layer-pair cells; high-depth profiles can have a lower effective input limit |
| Verification request body | At most 2 MiB |
| Compatible signed text envelope | At most 32 KiB |
| Client verification report | At most 128 KiB |
| Worker score report | At most 64 KiB |
| Private metadata artifact | At most 1 MiB for each registry manifest or calibration document |
| Pinned tokenizer/detector tree | Bounded file count and 256 MiB per artifact tree |
| Default process deadline | 120 seconds, operator-bounded configuration |
| Default concurrent inspections | One owned detector process |
| Default request budget | Twelve protected requests per minute |
| Text preview validity | Ten minutes |
| Per-capture decisions and statistical records | Up to 128 of each |
| Per-capture derived copies | Up to 32 |
| Supported signed assertion lifetime | At most 30 days, within key validity |
The interface reports exhausted limits and preserves the source. Capacity is bounded to avoid unbounded response histories, model work, or browser rendering.
Failure and recovery
| Situation | User-visible meaning and recovery |
|---|---|
| No configured or approved profile | Verification unavailable; continue local review or ask the operator for a qualified profile |
| Unauthorized access | Supply a permitted dedicated access key |
| Unknown profile or unsupported domain | Select an allowed profile and declared calibrated domain |
| Changed tokenizer, checkpoint, configuration, or package | Requalify the profile; do not reuse the old calibration claim |
| Too few usable contexts | Insufficient text; retain the observation without inventing a score |
| No valid bucket or uncertain score | Inconclusive for the declared conditions |
| Invalid content binding | Reject the result or proposal and capture the current source |
| Expired or stale preview | Create and review a fresh preview |
| Overlapping or protected edits | Change the selection; preserve unsupported sequences |
| Malformed Unicode | Preserve code units for review and obtain a valid source representation |
| Busy service or rate limit | Wait before retrying |
| Runtime failure or deadline | Explicit failure; retain the original and last recorded reports with their timestamps |
| Invalid archive lineage | Reject the inconsistent archive rather than silently repairing evidence |
| Missing signing trust or artifact manifest | Signature verification unavailable for the supplied context |
Fundamental limitations
There is no universal SynthID character pattern to strip and no universal text-watermark detector. Provider coverage and authorized verification access can change. Open research implementations and sample keys do not grant access to a production provider's private configuration.
The application does not certify that a derivative is watermark-free. Rewriting, translation, regeneration, or changes in representation can affect both meaning and detectability. A changed detector response remains specific to that detector and its operating scope.
The workflow includes no paraphrasing engine or feedback-driven bypass optimizer. Google's public detector terms restrict automation and adversarial optimization using service feedback. The application integrates its own authorized verification boundary instead of scraping a public portal.
During the latest research insptection (October 16, 2026), the public portal exposed image/audio/video file uploads and no visible text-entry control. Google's earlier launch announcement had described text along with media. That observation describes the public interface inspected, while account-specific and partner capabilities remain independently verifiable. 6 13
A signature proves an assertion was authenticated under a key policy. Statistical evidence supports a configured mark under evaluated assumptions. An exact artifact scan establishes supported observations. None of those results alone establishes human authorship, factual truth, lawful use, or the absence of other provenance.
References and primary sources
The research foundation uses primary documentation, official implementations, research publications, and relevant standards. Availability statements are dated observations rather than permanent product guarantees.
- Google DeepMind, "Watermarking AI-generated text and video with SynthID". May 14, 2024. Product scope, token-level mechanism, and documented entropy/transformation limitations.
- Google DeepMind, SynthID overview. Modality-specific watermarking and deployed-product context.
- Google Responsible Generative AI Toolkit, SynthID. Configuration, secrecy, repetition handling, production implementation guidance, and verification deployment options.
- Hugging Face and Google DeepMind, SynthID Text integration. Official integration introduced in Transformers v4.46.0, detector training, tokenizer compatibility, and limitations. The historical introduction version is a research reference; operators should qualify and pin an appropriate maintained compatible environment.
- Google DeepMind, SynthID Text reference implementation. Mean, weighted-mean, and Bayesian detection, compatibility details, training expectations, research-only caveats, and hash-security disclaimer.
- Google, SynthID Detector launch announcement. May 20, 2025. Initial portal scope and early-tester rollout; current capability requires a separate availability check.
- Kirchenbauer et al., "A Watermark for Large Language Models", ICML 2023, and the official watermarking implementation. Green-list generation and statistical detection.
- Kuditipudi et al., "Robust Distortion-free Watermarks for Language Models". Keyed random sequences, inverse-transform and exponential-minimum sampling, alignment, assumptions, and experimental limitations.
- Hou et al., "SemStamp: A Semantic Watermark with Paraphrastic Robustness for Text Generation", NAACL 2024. Semantic partitions, locality-sensitive hashing, and rejection sampling.
- C2PA 2.2, Content Credentials explainer. Manifests, assertions, asset binding, trust, and complementary soft bindings.
- Unicode UTS #39, Unicode Security Mechanisms. Joining controls, confusables, script context, and the limits of applying identifier rules to prose.
- Unicode UTS #51, Unicode Emoji. ZWJ, variation, and tag sequences with essential display semantics.
- Public SynthID Detector. Public interface and additional terms (last inspected October 16, 2026).
- Dathathri et al., "Scalable watermarking for identifying large language model outputs", Nature 634, 818-823 (2024). Primary research publication underlying SynthID Text. Technical behavior in this reference was cross-checked through official documentation and implementation material.
- IETF RFC 7515, JSON Web Signature and RFC 7518, JSON Web Algorithms. Compact signed representations and the ES256/P-256 signature construction. The application's signed-text assertion uses its explicitly documented payload and trust policy.
- xlr8harder, Qwen3-4B SynthID three-arm corpus, pinned revision
5dc8f92ae083944e3b4670a82dad4d8eeb2c035b, and its generation manifest. Published model outputs, separate key-A/key-B watermark arms, generation parameters, model revision, artifact hashes, and ODC-BY attribution. This community corpus supplies the sample source claims; the application has not independently verified the embedded watermarks.
Related operational guides: provenance processing, session history, and model access and authentication.