Chapter 14

Data Extraction Without Invented Fields

A classifier decides where to send, extraction decides what exactly to pull out. The main risk here isn't format but invented fields. If every field is required and null is forbidden, the model gets a direct incentive to fill the gap with a plausible fabrication. So an extraction prompt must allow a missing value.

SQL

# Task
Extract the order data only from the message text.

# Rules
- Don't reconstruct missing digits from a pattern.
- Don't normalize an ambiguous date without a locale.
- For each value, return an evidence_span from the source text.
- If a field isn't found, value = null and reason = "not_present".
- If several candidates are found, reason = "ambiguous".

# Schema
{
  order_id: { value: string|null, evidence_span: string|null, reason: string },
  date: { value_iso: string|null, evidence_span: string|null, reason: string },
  amount: { value: number|null, currency: string|null, evidence_span: string|null }
}

It helps to separate three different actions that often get merged into one.

Extract - copies an observed value and its provenance, inventing nothing.
Normalize - brings the format in line with explicit locale and timezone.
Resolve - verifies the entity against a database or tool, not by linguistic plausibility.

Hence the typical mistake: don't mix extraction, a business decision, and a write action in one indistinguishable answer. First get typed data, then verify it, and only then pass it to a policy engine or a separate workflow.

An example beats a redundant instruction. Show separate cases for null, two candidates, a localized date, and a typo in an ID. These boundaries break extraction more often than an ordinary successful example.

Data Extraction Without Invented Fields

Links