Define the fields before asking for extraction.

Fictional note: “Request S-17. Paula asks for three notebooks. Collection on 12 October 2026. Cost centre still to be confirmed.” Fields are identifier, requester, item, quantity, collection date and cost centre.

Define each field’s meaning. The date concerns collection, not creation. Cost centre must stay empty; the text does not let you infer it from Paula’s name.

Instruction: “Extract only the defined fields from this note. Include a supporting passage for each value. Use null when unspecified. Do not fill gaps using outside knowledge. Return quantity as an integer and the explicit date as YYYY-MM-DD.”

An instruction proposes the output format; reviewing that output remains part of the work. If the text contains an ambiguous date, add a rule requesting clarification rather than guessing its interpretation.

Expected: identifier S-17; requester Paula; item notebooks; quantity 3; date 2026-10-12; cost centre null. Converting “three” to 3 is allowed by the contract; assigning a cost centre is not.

Check each value and its evidence. A correct field paired with an unrelated passage makes auditing harder. Keep the original text associated with the extraction while reviewing it.

Change the note to mention three notebooks and then five without saying whether this is a correction. Expect a conflict or review marker. Next, include two requests in one text to check that their fields stay separate.

Validate required fields and review exceptions before importing. Preserve unresolved rows with reasons rather than silently converting them into complete records.