Before an extracted value becomes a payable, contract term or customer record, establish where it came from, what it means and which checks remain unresolved. Verification works best when each finding leads back to a specific field and its supporting text.
Start with the business field you intend to use
Consider a fictional invoice from Grayhaven Instruments. The supplied document text shows a subtotal of $8,000.00, tax of $640.00 and a total due of $8,640.00. An extraction system returns 8000.00 as the total due. The value is a valid amount and appears in the document. It still answers the wrong business question.
Define the field before testing it. A name such as total_due and a description such as “the total payable including tax” give the review a clear target. Keep subtotal, tax, invoice date and payment terms as separate fields. One verdict about one field is easier to investigate than a general assurance about an entire document.
Keep the source text with the extracted value
The AI output verification use case accepts an extracted_field item with document_id, field, value and value_type. The value travels as a string. Supported types are text, number, money, date and percent. An optional field_description explains the intended meaning.
Supply the corresponding document in context.records.document, including its stable id and text. This API checks the text in the request; it does not fetch a document from a URL or inspect an original PDF image. Keep the original file, its text extraction and the relationship between them in your own records. A transcription error already present in the supplied text can survive a text-based check.
Separate the checks that answer different questions
| Check | What it establishes | What still needs attention |
|---|---|---|
value_located | The value occurs in the supplied source, within the locator when one is provided. | A matching number may belong to another field. |
value_typed | The value fits its declared type. | A valid amount can still be the wrong amount. |
totals_consistent | A declared sum reconciles across the supplied extracted fields. | The caller must supply the relation and its components. |
right_field | The surrounding text supports assigning the located value to the requested field. | This judgment can remain unresolved under the running model configuration. |
For the fictional invoice, 8000.00 can satisfy location and type checks while failing a declared total relation. If the extractor returns 8460.00, that amount appears nowhere in the source. These failures need different corrections: field assignment in the first case, and a value or transcription investigation in the second.
Cite the right occurrence of a repeated value
An invoice may repeat an amount in a line item, subtotal and payment summary. Without a locator, the matching logic uses the first occurrence for the field-meaning question. Supply a text_quote containing the relevant label and value, or a byte_span identifying the exact source text.
Byte spans refer to UTF-8 bytes, not character positions. If a pipeline changes whitespace, encoding or source text after creating the locator, the cited bytes may no longer contain the quoted text. Retain the same text snapshot through extraction and verification. A failed locator should send the record back to source preparation instead of being silently discarded.
Declare arithmetic relationships explicitly
For Grayhaven’s invoice, the intended relationship is total due equals subtotal plus tax. Supply that relation in context.references.relations, and provide the other extracted fields in context.records.extracted_field or as items in the same batch. The check uses exact decimal arithmetic over those values.
A relation can add named fields and subtract fields listed in less, such as a discount. Missing or ambiguous component records leave the relation unresolved. With no declared relation, the total check is not applicable; it has not independently discovered and validated the document's arithmetic. The schema guide explains how to inspect the current request contract.
A reconciled sum establishes a relationship among the supplied values. If a document and its extracted fields share the same upstream error, they can agree without the business amount being correct. Retain a way to inspect the original record and how it was prepared. The evidence-origin investigation explains why agreement among copied facts is different from independent support for those facts.
Give unresolved results a useful destination
Some source formats cannot support an exact comparison. An ambiguous numeric date or a near match under another number convention can leave location unresolved. Separately, a field-meaning question may be unqualified or unanswered. Inspect the assertion’s outcome, message, facts and evidence pointers to distinguish these cases.
Use three operational paths: correct a demonstrated mismatch, obtain evidence for an unresolved check, or accept a completed result within its stated scope. HTTP 200 only means verification completed. A probability value does not turn missing evidence into a supported finding. The results guide explains the verdict, certainty basis and undecided reasons.
Check generated statements at sentence level
If your application also produces a summary, submit each sentence as a statement with its cited document ids. OpenAuditor checks numbers, quotations and whether source passages support the statement. A number occurring somewhere in a source does not establish the surrounding claim: “paid $8,640” and “owes $8,640” have different meanings.
Keep a reviewer path for semantic questions and incomplete source collections. Statement verification does not search the web for corroboration or establish the authenticity of the underlying document. The scope remains the text you supplied.
Validate the workflow before posting records
Build a small reviewed set with correct values, wrong-field matches, missing sources, repeated amounts and stale locators. Compare the returned assertions with the source documents. Track which cases need correction or human review; do not infer extraction accuracy from the share that received a decided verdict.
NIST’s AI Risk Management Framework places trustworthiness considerations across AI design, development, use and evaluation. For this workflow, make source verification an explicit step before downstream posting, with an owner for exceptions.
Use single verification to establish the request, then follow the batch review workflow for a population. If an agent will act on the extracted values, also verify the proposed action; reliable extraction and authorized execution require separate evidence.