Getting fields out instead of paragraphs

The shift that makes automation possible

A paragraph is only checkable by reading it. A set of named fields is checkable by a rule.

That is the whole reason this matters. If you ask a model to “summarise this enquiry”, you get prose, and the only way to know whether it got the delivery date right is for a person to read it against the original. If you ask for six named fields, your spreadsheet can test that the date is a date, that it is in the future, that the quantity is a number, and that the product code exists in your catalogue. Four checks, no reading.

What it looks like

The request says what fields you want and what to do when one is not present:

Read the enquiry below and return exactly these fields:
customer_name, contact, product_code, quantity, needed_by, budget_mentioned, notes

Rules:
- Use exactly the field names above, one per line, as field: value.
- If something is not stated in the enquiry, write NOT STATED. Do not guess.
- product_code must be one of: BK-01, BK-02, TR-14, TR-15. If the enquiry
  describes something else, write UNMATCHED and put the description in notes.
- quantity must be a plain number with no words.

Most current chat tools will also return JSON reliably if you ask, and several offer a strict mode that guarantees the shape. Free path: this works on a free chat tier by hand, in a spreadsheet with a formula-driven prompt, and in Python with the json module and a dozen lines. You do not need a paid product to do structured extraction.

The two failures, and they are different

A missing field. The model returns five fields when you asked for six. This is the harmless failure, because your software notices immediately. Treat it as a rejected row.

A plausible field. The model returns needed_by: 2026-11-04 for an enquiry that said “sometime before the school holidays”. This is the dangerous one. It is well-formed, it passes every structural check you have, and it is invented.

The structural checks catch shape, never truth. This is worth sitting with, because it is the exact point at which people over-trust structured output: JSON looks like data, and data feels factual in a way prose does not. It is the same model making the same guesses, wearing a costume.

The defence is the one from module two, applied here: the NOT STATED licence, and an explicit rule that a value must be copied from the text rather than derived from it. For anything that matters, add a quote field carrying the exact words the value came from. A wrong quote is visible in a second; a wrong date is not.

Validate before you use, not after

The order matters. Every field goes through a check before any action touches it:

• Is it one of the allowed values? Reject anything else, including near-misses.
• Is a date actually a date, and is it plausible: not in the past, not in 2035?
• Is a number a number? Is it within a range you would believe?
• Does the reference exist in your own records? Look it up; do not trust it.

Anything that fails goes to a person. Anything that says NOT STATED goes to a person. The automated path only handles rows where everything validated, and in a typical small business that will be 70 to 85% of them. The remainder is where your attention now goes, which is exactly the right place for it.

The mistake that wastes a weekend

Asking for twenty fields.

Extraction accuracy is not uniform across fields. Names and explicit numbers come out reliably. Anything requiring inference (urgency, sentiment, “is this customer likely to buy”) comes out as a confident guess, and once one invented field is sitting in the same row as six correct ones, the whole row acquires an unearned air of authority.

Ask for the fields that are literally present in the text. Nothing else. If you want an urgency judgement, make it a separate step with its own review, so the guess is visibly a guess.

Where this pays for itself

Structured output is what converts AI from a writing aid into a thing that plugs into your existing software. Enquiries into your CRM. Supplier invoices into your accounts as a draft. Job sheets into your diary. Reviews into a tagged list.

And it is the format that makes the rest of this module possible: you cannot log a paragraph usefully, you cannot deduplicate a paragraph, and you cannot write a rule that stops a paragraph doing something silly. Fields you can.