Extraction

Schema-first field extraction with a validation loop — precision over recall when the two trade off.

Workflow

1. Define the schema before extracting. List every field you need, its type, and whether it's required or optional. Extracting "whatever seems relevant" produces inconsistent output; extracting against a fixed schema produces comparable output.
2. Extract with source pointers. For each field, note where in the source it came from (a quote, a section reference) — this makes the extraction auditable and catches hallucinated values immediately (if you can't point to where it came from, it's probably invented).
3. Mark fields explicitly absent, don't guess. A missing field should be null/not found, never a plausible-sounding fabrication. Guessing a field you can't find is the single most common extraction failure.
4. Validate types and formats before returning. Dates parse as dates, amounts parse as numbers, enums match an allowed set. Reject and re-extract a field that doesn't validate rather than passing bad data downstream.
5. Re-check ambiguous matches. If a field could plausibly map to two different values in the source (e.g. two dates, two dollar amounts), state the ambiguity rather than silently picking one.

Composition

Usually follows document-analysis (which establishes what kind of document this is and where things live) and feeds compliance-review or other downstream skills that need structured input rather than raw text.

Quality bar

• Every extracted field has a source pointer (quote or location) or is marked not-found.
• No field is a guess presented as a fact — absence is explicit.
• All fields pass basic type/format validation before being returned.
• Ambiguous extractions are flagged, not silently resolved.