> This page is for version v2026-02-09 (default). > For other versions, use one of these documentation indexes: > - v2026-02-09 (default): https://docs.extend.ai/2026-02-09/llms.txt > - v2025-04-21: https://docs.extend.ai/2025-04-21/llms.txt > - v2024-12-23: https://docs.extend.ai/2024-12-23/llms.txt > ## Documentation Index > Fetch the complete documentation index at: https://docs.extend.ai/llms.txt > Use this file to discover all available pages before exploring further. > > ## API version > The current API version is `2026-02-09`, served at the site root (no version prefix in URLs). > If this page URL contains `/2025-04-21/` or `/2024-12-23/`, you are reading an older API version. > Prefer the current docs at https://docs.extend.ai/llms.txt unless the user explicitly needs that older version. > Do not treat older-version pages as the source of truth for new integrations. # Verify Signals > The Public Signal categories Verify returns, which engine runs each one, what each category detects, how evidence codes describe findings, and how signals are graded. Verify reports findings as **Public Signals**: the stable categories that can appear in `output.signals[].type`. A run returns at most one signal per category, carrying one `summary`, one `riskAssessment`, and every piece of `evidence` found in that category. Every supported check runs on every run, and signals that were not detected are not returned: absence means "not detected," never "checked and clean." ## Signal categories | Signal | Detects | Included in `verify_light` | | -------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------- | | `FILE_FORMAT_AND_PDF_STRUCTURE` | Files disguised as another type, PDF structure broken or rebuilt by an edit, content appended after the end of the file, and files that read differently to different PDF software. | Yes | | `DIGITAL_SIGNATURE_INTEGRITY` | Content changed after the document was signed, signatures that do not match the file they are attached to, and signer certificates or timestamps that did not hold up when the signature was made. | Yes | | `PROVENANCE_AND_ISSUER_MARKERS` | Content credentials (C2PA) that fail to verify, and provenance watermarks whose manifest has been stripped. | Yes | | `REVISION_AND_PRODUCTION_HISTORY` | Documents re-saved after issuance, backdated timestamps, image-editing software in the production chain, and a scanned page produced differently from the rest. | Yes | | `CAPTURE_CONVERSION_AND_LAUNDERING` | Annotation layers that hide or change what a reader sees. | Yes | | `PDF_LAYERS_TEXT_AND_FORMS` | Values covered over and retyped, image patches pasted over a scan, text hidden from readers, form values that differ from what the form displays, values set in a font the rest of the line does not use, and an OCR text layer that disagrees with the page. | Yes. The OCR text-layer check runs only when the run parses the document; see `advancedOptions.requireParsing`. | | `IMAGE_COMPOSITING_AND_RECONSTRUCTION` | Regions spliced in from another image, cloned from elsewhere on the page, or erased and painted back over. | Yes | | `AI_GENERATED_CONTENT` | Generator watermarks, content credentials that assert generation, and pages or regions a detection model judges to be synthetic. | Yes | | `CROSS_FIELD_AND_SEMANTIC_CONSISTENCY` | Dates that contradict each other, and names, addresses, identifiers, issuers, or locations stated differently in different places. | No | | `FINANCIAL_RECONCILIATION_AND_SEQUENCE_CONTINUITY` | Totals that do not match their components, running balances that do not reconcile, and gaps in page numbers, document numbers, statement periods, or transaction order. | No | > **Note** > > Categories activate over time without a change to the enum, so handle every value. Content-based categories are found by reading the parsed document, which only `verify_agentic` does. ## Evidence codes Each signal's evidence carries codes that say what was detected: the `code` on a `validation` finding, a `history` event, a `value_comparison`, or an `inventory`, and the `code` and component `role`s on a `structural_pattern`. Codes are stable `SCREAMING_SNAKE` identifiers. The set grows as new checks are implemented, so treat the codes you receive as an open list and handle values you do not recognise rather than rejecting them. An `evidenceId` is unique within the run; treat it as an opaque identifier. For the list of codes currently in use, or to understand a particular code, contact [support@extend.ai](mailto:support@extend.ai). ## How signals are graded Each signal's `riskAssessment` is graded `LOW`, `MEDIUM`, or `HIGH` in the context of the whole document, because many anomalies are normal consequences of ordinary document workflows and only the surrounding context separates a benign re-save from a suspicious one. The document `riskLevel` is the highest grade among its signals, and a run with no detections returns `LOW`. See [Response Format](/verify/response-format#risk-assessment) for the `riskAssessment` shape.