Prompt · Data
Data extraction prompt
Pulling fields out of invoices, emails, CVs or support tickets into something a program can use, where a plausible wrong value is worse than an empty one.
Extract structured data from the text below.
<text>
{{text}}
</text>
Return JSON matching exactly this shape:
{{schema}}
Rules:
- Use only values present in the text. Do not infer, complete or correct anything.
- If a field is not present, return null for it. Never guess, and never omit the key.
- Copy values verbatim, including formatting, unless the schema specifies a format.
- If the text contains several candidates for a single-value field, return the one nearest to the field's own label; if that is ambiguous, return null.
- If the text is not the kind of document this schema describes, return every field as null.
Return the JSON object only. No markdown fences, no commentary.What to fill in
{{text}}- The raw source. Do not clean it up first — extraction prompts should be tested on the messy version, because that is what production sends.
{{schema}}- A literal example object with the exact keys and types you want. Showing the shape works better than describing it.
Why it is written this way
Every rule in the prompt is there because of a specific failure it prevents. Knowing which is which is what lets you adapt it instead of only pasting it.
Null is defined, not left to judgement
This is the whole prompt in one rule. A model asked to extract an invoice number from a document that has none will produce something invoice-number-shaped. Saying "return null, never guess" converts a silent data corruption into a visible gap you can handle.
The key is never omitted
A missing key and a null value are different to every parser. Without this line you get objects with varying shapes and code that fails on the third document rather than the first.
Ambiguity has a defined resolution
Documents contain several dates and several numbers. Without a rule the model picks one and gives no indication that it chose. The nearest-label rule is not perfect, but it is deterministic and explainable when it is wrong.
The schema is shown, not described
A literal example object produces markedly higher structural compliance than a prose description of the same shape. If the API supports schema enforcement, use that too — this instruction is the belt, that is the braces.
Wrong-document-type has an answer
Send a restaurant menu to an invoice extractor and without this rule you get a confident invoice. All-null is a signal your code can act on.
The version most people write, and what it costs
Extract the invoice number, date and total from this text and return JSON:
{{text}}On a document missing the invoice number it invents one — usually something plausible drawn from another number nearby. That value flows into your database indistinguishable from a real one. This is the most expensive failure in this list, because nothing about the output looks wrong.
What it still gets wrong
- Structured output modes constrain the shape, not the truth. A schema-valid response can still contain the wrong value.
- Verbatim copying degrades on long documents; values far from the field label are more often mis-associated.
- Extraction accuracy varies sharply by document layout. Test on your worst-formatted real examples, not on a clean sample.
Check it before you ship it
- Function Calling Tool Schema BuilderOne line per tool, valid schema out, with the per-request cost shown.
- LLM JSON Output ValidatorPull JSON out of a chatty answer and check the contract holds.
- JSONL Validator for Fine-Tuning DatasetsLine-numbered parse errors plus the structural checks uploads actually fail on.
To build one of these from scratch for a task not covered here, the prompt generator assembles the same structure — delimiters, output contract, edge cases — from an expert-authored blueprint, and the prompt review checklist is what to run over the result.