{"course":{"slug":"ai-for-small-business","title":"AI for a Small Business","url":"https://addaly.com/learn/ai-for-small-business","level":"beginner","track":"work"},"lesson":{"slug":"fields-not-prose","title":"Getting fields out instead of paragraphs","url":"https://addaly.com/learn/ai-for-small-business/fields-not-prose","position":59,"of":88,"minutes":9,"answer":"Asking for named fields turns an output a person must read into one a machine can check, because a missing field is an error your software can catch while a missing sentence is not.","keyIdea":"Asking for named fields turns an output a person must read into one a machine can check, because a missing field is an error your software can catch while a missing sentence is not."},"body":{"format":"markdown","text":"## The shift that makes automation possible\n\nA paragraph is only checkable by reading it. A set of named fields is checkable by a rule.\n\nThat 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.\n\n## What it looks like\n\nThe request says what fields you want and what to do when one is not present:\n\n```text\nRead the enquiry below and return exactly these fields:\ncustomer_name, contact, product_code, quantity, needed_by, budget_mentioned, notes\n\nRules:\n- Use exactly the field names above, one per line, as field: value.\n- If something is not stated in the enquiry, write NOT STATED. Do not guess.\n- product_code must be one of: BK-01, BK-02, TR-14, TR-15. If the enquiry\n  describes something else, write UNMATCHED and put the description in notes.\n- quantity must be a plain number with no words.\n```\n\nMost 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.\n\n## The two failures, and they are different\n\n**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.\n\n**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.\n\nThe 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.\n\nThe 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.\n\n## Validate before you use, not after\n\nThe order matters. Every field goes through a check before any action touches it:\n\n- Is it one of the allowed values? Reject anything else, including near-misses.\n- Is a date actually a date, and is it plausible: not in the past, not in 2035?\n- Is a number a number? Is it within a range you would believe?\n- Does the reference exist in your own records? Look it up; do not trust it.\n\nAnything 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.\n\n## The mistake that wastes a weekend\n\nAsking for twenty fields.\n\nExtraction 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.\n\nAsk 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.\n\n## Where this pays for itself\n\nStructured 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.\n\nAnd 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."},"check":{"question":"An extraction prompt for supplier invoices returns invoice_number, date, net, vat and total. A builder adds a check that net plus vat equals total, and finds it passes on every invoice. What has he established?","options":[{"text":"That the extraction is working, since an arithmetic relationship holding across every invoice would be very unlikely if the figures were being read incorrectly.","correct":false,"tempting":"Assumes errors would be random; a model that reads one figure wrong tends to adjust the others to be consistent, which is what makes this check weak."},{"text":"That the model is computing the total itself rather than reading it, which is the error module six warned about, so the check should be removed.","correct":false,"tempting":"Right to be suspicious of arithmetic, but the check is cheap and catches some misreads; the problem is what it fails to catch, not that it exists."},{"text":"That the invoices are internally consistent, so any remaining errors must be in fields the check does not cover, such as the invoice number or the date.","correct":false,"tempting":"Locates the remaining risk in the unchecked fields only, when the checked fields can also be wrong together."},{"text":"Only that the three numbers agree with each other, which they will even if all three were misread from the wrong column or the wrong page.","correct":true}]},"prev":{"slug":"the-permission-ladder","title":"Five rungs of letting go, and what licenses each one","url":"https://addaly.com/learn/ai-for-small-business/the-permission-ladder"},"next":{"slug":"what-a-call-costs","title":"What a call costs, and how a loop becomes a bill","url":"https://addaly.com/learn/ai-for-small-business/what-a-call-costs"},"authorship":"Founder and series editor: Dr Mustafa Mun. Written by AI models to a written standard. Exam keys checked blind by a second model: 3,665 of 3,666 agreed. Academic review invited.","review":{"status":"Draft, open for academic review"},"cite":"Addaly (2026) 'Getting fields out instead of paragraphs', in AI for a Small Business. Edited by M. Mun. Addaly. Available at: https://addaly.com/learn/ai-for-small-business/fields-not-prose (Accessed: 13 October 2026).","licence":{"name":"CC BY-NC-SA 4.0","url":"https://creativecommons.org/licenses/by-nc-sa/4.0/"},"reader":{"schema":1,"title":"Getting fields out instead of paragraphs","courseTitle":"AI for a Small Business","module":{"index":7,"slug":"letting-it-act","title":"Letting it act: automation you can trust with the keys"},"answer":null,"keyIdea":"Asking for named fields turns an output a person must read into one a machine can check, because a missing field is an error your software can catch while a missing sentence is not.","hero":{"kind":"plate","image":null,"alt":null,"caption":null},"blocks":[{"t":"h2","id":"the-shift-that-makes-automation-possible","runs":[{"text":"The shift that makes automation possible"}]},{"t":"p","runs":[{"text":"A paragraph is only checkable by reading it. A set of named fields is checkable by a rule."}]},{"t":"p","runs":[{"text":"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."}]},{"t":"h2","id":"what-it-looks-like","runs":[{"text":"What it looks like"}]},{"t":"p","runs":[{"text":"The request says what fields you want and what to do when one is not present:"}]},{"t":"code","lang":"text","label":"Text","text":"Read the enquiry below and return exactly these fields:\ncustomer_name, contact, product_code, quantity, needed_by, budget_mentioned, notes\n\nRules:\n- Use exactly the field names above, one per line, as field: value.\n- If something is not stated in the enquiry, write NOT STATED. Do not guess.\n- product_code must be one of: BK-01, BK-02, TR-14, TR-15. If the enquiry\n  describes something else, write UNMATCHED and put the description in notes.\n- quantity must be a plain number with no words."},{"t":"p","runs":[{"text":"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 "},{"text":"json","code":true},{"text":" module and a dozen lines. You do not need a paid product to do structured extraction."}]},{"t":"h2","id":"the-two-failures-and-they-are-different","runs":[{"text":"The two failures, and they are different"}]},{"t":"p","runs":[{"text":"A missing field.","b":true},{"text":" 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."}]},{"t":"p","runs":[{"text":"A plausible field.","b":true},{"text":" The model returns "},{"text":"needed_by: 2026-11-04","code":true},{"text":" 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."}]},{"t":"p","runs":[{"text":"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 "},{"text":"looks","i":true},{"text":" like data, and data feels factual in a way prose does not. It is the same model making the same guesses, wearing a costume."}]},{"t":"p","runs":[{"text":"The defence is the one from module two, applied here: the "},{"text":"NOT STATED","code":true},{"text":" 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 "},{"text":"quote","code":true},{"text":" field carrying the exact words the value came from. A wrong quote is visible in a second; a wrong date is not."}]},{"t":"h2","id":"validate-before-you-use-not-after","runs":[{"text":"Validate before you use, not after"}]},{"t":"p","runs":[{"text":"The order matters. Every field goes through a check before any action touches it:"}]},{"t":"ul","items":[[{"text":"Is it one of the allowed values? Reject anything else, including near-misses."}],[{"text":"Is a date actually a date, and is it plausible: not in the past, not in 2035?"}],[{"text":"Is a number a number? Is it within a range you would believe?"}],[{"text":"Does the reference exist in your own records? Look it up; do not trust it."}]]},{"t":"p","runs":[{"text":"Anything that fails goes to a person. Anything that says "},{"text":"NOT STATED","code":true},{"text":" 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."}]},{"t":"h2","id":"the-mistake-that-wastes-a-weekend","runs":[{"text":"The mistake that wastes a weekend"}]},{"t":"p","runs":[{"text":"Asking for twenty fields."}]},{"t":"p","runs":[{"text":"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."}]},{"t":"p","runs":[{"text":"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."}]},{"t":"h2","id":"where-this-pays-for-itself","runs":[{"text":"Where this pays for itself"}]},{"t":"p","runs":[{"text":"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."}]},{"t":"p","runs":[{"text":"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."}]}],"check":{"question":[{"text":"An extraction prompt for supplier invoices returns invoice_number, date, net, vat and total. A builder adds a check that net plus vat equals total, and finds it passes on every invoice. What has he established?"}],"options":[{"text":[{"text":"That the extraction is working, since an arithmetic relationship holding across every invoice would be very unlikely if the figures were being read incorrectly."}],"correct":false,"tempting":[{"text":"Assumes errors would be random; a model that reads one figure wrong tends to adjust the others to be consistent, which is what makes this check weak."}]},{"text":[{"text":"That the model is computing the total itself rather than reading it, which is the error module six warned about, so the check should be removed."}],"correct":false,"tempting":[{"text":"Right to be suspicious of arithmetic, but the check is cheap and catches some misreads; the problem is what it fails to catch, not that it exists."}]},{"text":[{"text":"That the invoices are internally consistent, so any remaining errors must be in fields the check does not cover, such as the invoice number or the date."}],"correct":false,"tempting":[{"text":"Locates the remaining risk in the unchecked fields only, when the checked fields can also be wrong together."}]},{"text":[{"text":"Only that the three numbers agree with each other, which they will even if all three were misread from the wrong column or the wrong page."}],"correct":true,"tempting":null}],"order":[1,0,3,2],"why":null},"prev":{"slug":"the-permission-ladder","title":"Five rungs of letting go, and what licenses each one","minutes":9},"next":{"slug":"what-a-call-costs","title":"What a call costs, and how a loop becomes a bill","minutes":9}}}