How to ask an AI for output you can check
A polished answer is hard to reuse. A schema with fields, types, and explicit gaps lets you validate what AI produced before passing it to another tool.
Asking an AI to "summarize this contract" can give a useful answer, but it leaves all the hard work on the other side: someone has to locate the dates, copy the amounts, and guess whether a silence means there was no datum or that the model dropped it. If the result is going to travel to a spreadsheet, a database, or a decision, it is worth asking for a form rather than a piece of writing. The capability you take away here is turning an open task into a verifiable schema — fields, types, allowed values, and explicit handling of what is missing — so that checking the answer stops being a careful read and becomes a mechanical review.
Prose is convenient; a schema is checkable
The practical difference is who bears the effort. A prose answer is pleasant to read and expensive to verify: the reviewer has to reread the whole thing to know what datum is there and what is missing. An answer with form — a table, a data object — is less elegant and far cheaper to check: you see at a glance which fields are present, which come empty, and which would need contrasting. When an answer's destination is not a human reader but another system, prose is outright a hindrance: you have to extract from it again what could already have been requested structured.
Define the container and its rules
The most common format for this is JSON, a syntax for exchanging structured data described in RFC 8259. It is worth understanding what it does and does not: JSON does not make an answer true, it only makes its form visible. An object can be perfectly well-formed and contain a fabricated figure. To extract, say, the obligations from a document, you define concrete fields — date, responsible_party, action, source, extraction_confidence — rather than letting the model choose how to organize the answer.
Then come the rules, which are what turn a container into a control. A date must use a fixed format; an amount must carry its currency; a category must belong to a closed list of allowed values; an unknown field is worth null, not an empty string, a zero, or an invention — each of those three would later read as a real datum. JSON Schema is the standard language for expressing these constraints: types, required fields, patterns, formats, and enumerations. That last one — the enumeration — is the most underrated: if a "risk" field is only allowed the values "high," "medium," or "low," the model cannot slip in a fourth invented nuance; the form shuts the door.
Ask for gaps, not filler
The decisive instruction is a single sentence: "Do not invent values; if the document does not contain the datum, use null and explain what is missing." Without it, a model tends to fill the gap with something plausible, and that filler is indistinguishable from a real datum until someone checks it. With it, error is separated from absence: a declared null is an open, honest question; an invented date is a trap. Also ask, for each field that matters, for a reference to the exact fragment of the source it came from — not as decoration, but as the hook that makes the datum verifiable.
There is a tempting field to distrust: the "confidence" the model assigns itself. A number saying "I am 0.9 sure" is not calibrated: it does not mean it is right nine times out of ten, only that the model wrote 0.9. It works as a soft signal for ordering what to review first, never as a substitute for checking. A system's self-assessment is not evidence about itself.
Two checks, in this order
From all the above comes a two-layer verification that must not be confused. The first is structural: check that the answer meets the schema — the right types, the required fields present, the values within the allowed lists. A machine does this in an instant and discards malformed answers — and it is worth automating with a schema validator rather than eyeballing it, because the human eye tires and waves through a long object with one mistyped field in the middle. The second is factual: check the important fields against the original document, using the citations you asked for. An object can pass the first layer with a false figure; only the second catches it. The NIST generative-AI profile insists on measuring and managing risk, and applied here it boils down to a warning: do not confuse "it could be imported" with "it is correct." That a datum fits the box says nothing about whether it is true.
The failures that form does not fix
It is worth not selling structure as a cure, because it has its own traps and all are resolved in the second layer. A model can return impeccable JSON and, at the same time, silently drop an obligation that was in the document: the form is valid, but incomplete, and nothing in the object flags what is missing. It can also force a value to fit the allowed list — marking a risk it could not classify as "medium" — and so hide its uncertainty behind a correct box. And it can fill the citation field with a fragment that sounds like the source but does not say what the field claims. None of these failures is caught by the schema validator, because all of them produce a well-formed object. That is why checking against the original is not optional: it is the only one that sees what structure, by definition, hides.
A reusable template
The instruction that ties this together fits in a few lines and works for almost any extraction. State the task, the schema, the allowed values, what to do when a datum is missing, and what evidence is required. For example: "Extract the contract's obligations. Return only JSON, with no surrounding text. For each obligation include: action, responsible, date in ISO format or null, verbatim_quote, and page. Do not infer what is not written; if something is ambiguous, note it in a notes field." That template is reusable because it does not depend on the specific document: the schema changes with the task, but the discipline — form, closed values, honest null, and citation — stays the same.
The habit that remains
The rule that survives any model is simple: the farther an answer will travel — to a person, a table, an automation that acts on its own — the more it should look like a reviewable form and the less like an elegant improvisation. Pretty prose is for reading; checkable form is for trusting. And it is not a technique only for programmers: anyone who pastes an AI's answer into a spreadsheet is already, without knowing it, asking it for a form — the difference is whether they ask for it explicitly, with its rules, or leave it implicit and then fight with whatever comes out. And the order matters: first you validate the form, which is cheap and automatic, and only then the truth of the data, which is expensive and human. Asking for output with form does not make the model more truthful; it makes its untruthfulness easy to find, which in practice is almost the same thing.
Primary sources
This article was produced with artificial intelligence under human editorial oversight.
