How the detector works
The current service tokenises and segments each passage, then returns a model-relative detector score with its model and policy metadata. The score is not a probability of authorship. The interface maps policy thresholds to low signal, review, high signal, or refused states and links to the applicable evaluation limitations.
The review state means the available evidence is insufficient for a strong detector claim. It requires contextual human review rather than a forced binary label. Refusal and missing coverage are reported as missing evidence, never as a human result.
Inputs accepted
- Plain text, up to 2,000 characters per scan in the web UI.
- Language coverage depends on the active model version; the language selector does not itself guarantee support.
- Use complete contextual passages. Citations, quotations, formulas, translation, and specialist terminology can materially affect detector behavior.
What the scan details contain
Scan details are an unsigned JSON object containing the detector response and metadata currently returned by the API. Signed analysis receipts remain a planned, separately gated feature. Until that feature ships with a public verifier and production key operations, this object must not be presented as cryptographic proof.
For API integrations
Product teams should start with the white-hat detector API guide. It covers server-side token handling, per-sentence detector states, abstention, scan details, and review workflows for products such as ChargeIntel or KlarAds where detector output gates publication or escalation rather than making a final accusation.