Check every field your AI extracted against the document
One call per field: is the value in the document, the right item, whole? Flagged fields go to a larger model or a person; code does the sums.
Try it on this example
Field name in your schema: total_amount_due
What the field should hold, from your schema: The total the customer must pay for this invoice, including VAT, in the invoice currency, as a number.
Value the model extracted (empty if none): 1860.00
Text of the document the value was extracted from
- Is the document text readable enough to check the value against?Yes98%
- Does the document give a value for this field?Yes99%
- Is the extracted value absent from the document, or different from what the document says?Yes95%
- Is the extracted value taken from a different item in the document from the one the field asks for?Yes99%
- Does the extracted value leave out part of what the document gives for this field?Yes72%
- Does the document give more than one value that could fit this field?No89%
- What should happen to this extracted value before it enters the finance system?Extract again with a larger model97%
These are real answers stored from one run on this example.
The prism behind it
Check every field your AI extracted against the document
Fields
- Text of the document the value was extracted from
- Field name in your schema
- What the field should hold, from your schema
- Value the model extracted (empty if none)
Context
Extraction checks for the accounts payable team of Selwyn Foods, a food manufacturer. A small generative AI model reads each supplier invoice, credit note and delivery note and extracts the fields of our schema for the finance system. Schema validation in code already rejects a value of the wrong type or format. This check runs once for each extracted field, before the record enters the finance system, and asks whether the value is the right one for the field. Code sends a document to a larger model, and then to a person, when any one of its fields is flagged; it never averages across fields. The field description comes from our schema and says what the field should hold. A value counts as given in the document when the document states it, even if the model changed its format, for example 2,232.00 written as 2232.00, or 14/09/2026 written as 2026-09-14. The document text comes from a scanner and may contain small reading errors. Code does the arithmetic: whether the lines add up, whether the tax is right, and whether a date falls in range. These answers say only whether the extracted value is the one the document gives for the field.
Questions
Is the document text readable enough to check the value against? Yes / No
Read the document text, especially where a value for this field would appear. Yes: The text is readable enough to see what the document says for this field, even with small reading errors. No: The text is garbled, cut off or mostly symbols where the value would appear, so the value cannot be checked.
Does the document give a value for this field? Yes / No
Read the field description, then the document. Ignore the extracted value for this question. Yes: The document states a value that fits the field description. No: The document gives no value for this field. A label with nothing after it counts as not given.
Is the extracted value absent from the document, or different from what the document says? Yes / No
Look for the extracted value in the document. Yes: The value, or part of it, appears nowhere in the document, or differs from the document in a digit, a word or a name beyond a change of format. No: The whole value appears in the document, word for word or in another format with the same meaning, or the extracted value is empty. A value that appears in the document but as a different item is asked about separately.
Is the extracted value taken from a different item in the document from the one the field asks for? Yes / No
Find where the extracted value appears in the document and compare that item with the field description. Yes: The value appears in the document, but as another item, such as the subtotal instead of the total, the invoice date instead of the due date, or the supplier's address instead of the delivery address. No: The value is the item the field description asks for, or it does not appear in the document at all, or the extracted value is empty.
Does the extracted value leave out part of what the document gives for this field? Yes / No
Compare the extracted value with what the document gives for this field. Yes: The value is the right item but cut short, such as an address without its postcode, a reference missing characters, a name missing a part, or one line of two. No: The value holds all of what the document gives for the field, or the extracted value is empty or a different item.
Does the document give more than one value that could fit this field? Yes / No
Read the field description, then the whole document. Yes: Two or more different values fit the field description, such as two totals, two order numbers or a figure corrected by hand, so the right one is not clear from the description alone. No: Only one value in the document fits the field description, or none does. Values that plainly belong to other fields, such as a subtotal where the field asks for the total including tax, do not count.
What should happen to this extracted value before it enters the finance system? Choice
Judge the value, the field description and the document together. The answer is a suggestion; code applies it together with the flags above. If more than one option fits, choose the one lowest in the list.
Lens columns
enough_to_judge, enough_to_judge_probability, field_present, field_present_probability, unsupported_value, unsupported_value_probability, wrong_item, wrong_item_probability, incomplete_value, incomplete_value_probability, several_candidates, several_candidates_probability, suggested_step, suggested_step_probability
Run it on your own text
Add this prism in the app, change any question, and test it on a file of your own.