Extract structured data from text

Why this prompt works

• →A JSON example is a stronger schema than a description — the model copies its exact keys and value shapes instead of inventing near-misses.
• →"Null for missing, never infer" is the anti-hallucination core: extraction tasks fail worst when blanks get quietly filled with plausible values.
• →The ambiguity list after the JSON gives the judgement calls a home outside the data, so the JSON stays machine-consumable.

Part by part

Return ONLY valid JSON

Excludes the explanatory prose that otherwise wraps the output and breaks any parser consuming it.

every value must come from the text — never infer or embellish

The core constraint. Extraction that fills gaps with plausible values produces data indistinguishable from real data.

Use null for anything the text doesn't state

A defined marker for absence, so a missing field is visible rather than inferred or omitted.

copy numbers, dates and names exactly as written

The three fields most often silently normalised — a date reformatted or a number rounded is a change to the data.

list anything ambiguous you had to leave out

Surfaces what did not fit the schema, which is often the most informative part of the run.

Common mistakes

• Extract the key information from this text as JSON.

  Without a schema, the shape varies between runs, so nothing downstream can rely on it. Two documents produce two different structures for the same kind of data.

• Extract this data and fill in anything missing.

  Explicitly asks for invention. The output then contains values that look extracted and were generated, with no way to tell them apart afterwards.

• Normalising dates during extraction.

  Reformatting a date requires interpreting an ambiguous format, and 03/04 is two different days depending on the convention. Extract verbatim, then normalise as a separate step you can check.

Questions