The epistemology, not the implementation.
This page covers what VeracityAPI claims to measure, what it explicitly doesn't, and the trust contract behind every response. For the technical pipeline (model, temperature, thresholds, scoring code), see /how-it-works.
Most AI-detection products blur these together: 'here's what we do' and 'here's how we do it' end up in one document. I split them deliberately. /methodology answers 'what can I trust this for?' — which is the question that should be settled before integration. /how-it-works answers 'what's running under the hood?' — which is the question that matters during integration. Different audiences, different cadences of change.
What we measure
- Specificity gaps and generic slop risk — does the text describe a category or name actual things?
- Provenance weakness — claims without sources, attributions without traceability, evidence without a chain.
- Visible synthetic-image cues — for uploaded/public image URLs at v0.1 visual-rubric resolution.
- Routing fit — the deterministic output that says what your workflow should do next: allow, revise, human_review, or reject.
What we do not claim
- No proof of human vs AI authorship. The result is workflow risk, not provenance.
- No legal, academic, employment, identity, or forensic determination. The response is not court-ready evidence.
- No guarantee of truth, safety, or legality. Specific text can still be wrong; generic text can still be true.
- No plagiarism source-matching. A different category of product solves that problem.
The trust contract: what every response actually contains
Every /v1/analyze response combines model-observed evidence with deterministic post-processing. Agents should branch on recommended_action, store evidence and limitations alongside the routing decision, and escalate high-stakes uncertainty to humans rather than tightening thresholds.
| Signal | Purpose | Safe use | Unsafe use |
|---|---|---|---|
content_trust_score | 0–1 confidence that content is usable for the workflow. | Rank queues; monitor quality trends over time. | Don't use as a threshold; the calibration may shift across versions. |
risk_level | Normalized low/medium/high rollup. | Set default routing thresholds in your local policy. | Don't treat 'high' as evidence of malfeasance. |
recommended_action | Deterministic routing label. | Branch your code on this field; it's the stable contract. | Don't show as a probability to a human user — it isn't one. |
evidence | Typed spans/cues explaining the route. | Use as a rewrite prompt; show to a human reviewer. | Don't treat as exhaustive — evidence is what the model surfaced, not everything it found. |
limitations | Boundary language for your UI. | Display alongside the result so users understand scope. | Don't hide; the limitations are part of the trust contract. |
Privacy posture
Default text requests don't retain raw content — store_content defaults to false. Image analysis stores no raw bytes, no base64 payloads, no full URLs. Operational logs keep request ID, hashed inputs, hostname, latency, model version — the metadata needed for support and debugging without retaining what you submitted.
For details on subprocessors and data flow: see Privacy, Security, and Subprocessors.
Evaluation posture
Published evals report routing-action agreement, not authorship detection accuracy. The 2026 benchmark program will publish binary-flagging F1 alongside routing-action F1 once vendor terms, corpus licensing, and frozen artifacts are complete. 'Where Veracity loses' will appear on the page regardless of headline favorability.
Current published numbers: 0.871 macro F1 on a 500-item seed corpus, 88.0% routing accuracy. See evals for per-action precision/recall and reproducible artifacts.
Recommended escalation policy by intended_use
The policy module isn't a recommendation — it's the deterministic logic the API applies after scoring. When you set intended_use in the request context, the routing thresholds shift accordingly.
| intended_use | low risk | medium risk | high risk |
|---|---|---|---|
publish | allow | revise | human_review |
train | allow | human_review | reject |
cite | allow | human_review | reject |
moderate | allow | allow | revise |
other | allow | revise | human_review |
The asymmetry reflects the cost of getting it wrong. Publishing a marginal page is recoverable; training on it amortizes over millions of inference calls. The intended_use field exists precisely so the policy doesn't have to be uniform across use cases.
When the right answer is 'don't use VeracityAPI'
I think every methodology page should include a 'don't use this product if...' section. Here's mine:
- Academic-integrity disciplinary processes. The score is not authorship proof. If a student's grade or graduation depends on the outcome, this is the wrong tool.
- Employment, hiring, or performance decisions. Same reason.
- Court-ready synthetic-media forensics. Forensic vendors (Reality Defender, DeepMedia, others) are built for that and provide the chain-of-custody artifacts courts require.
- Audio or video synthetic-media detection. VeracityAPI scrubbed audio and video from the marketing surface in 2026; for those modalities, use a specialist vendor.
- Plagiarism source-matching. Use a plagiarism-specialized tool (Copyleaks, Turnitin, Originality.ai's plagiarism module).