Define Fields So AI Fills Them the Same Way Every Time

Step 1: Say what kind of field each one is

Before defining any single field, sort them by kind, because different kinds of field drift for different reasons and need different definitions. Most structured records mix a few types: a category field that picks from a fixed set (issue_type), a decision field that applies a rule to reach a verdict (priority), a source field that captures what the input actually says (customer_reason), a judgment field that holds the model's own read (suspected_cause), and an action field that states what to do (next_action). The trouble starts when a record treats them all the same — asks for five fields as if they were one kind of thing — because a category needs a list, a decision needs criteria, and a source field needs a quoting rule, and none of those substitutes for the others.

Naming the kind up front also catches the field that's secretly two fields. "reason" is the classic one: it wants to be a source field (what the customer said) and a judgment field (why it's happening) at the same time, so the model fills it as whichever fits the row. The fix is structural — split it into two clearly-typed fields — and it starts here, by refusing to write a definition for a field until you can say which single kind it is. A field you can't type yet isn't defined yet; it's a question with two answers.

Step 2: Define each field with include, exclude, and a counterexample

With the kind settled, write the definition that closes the gaps the name left open. The test for a good one: could two careful people, reading it, fill the same field differently? If yes, it isn't defined. A workable shape per field: a one-sentence plain-language meaning, what it includes, what it explicitly excludes, the allowed type or values, one good example value, and — the part that does the most work — one bad counterexample that would be easy to get wrong. "issue_type: the normalized category of the reported problem; includes the technical area affected; excludes the customer's emotion and the fix; allowed: login_access, billing, feature_request, bug_unknown, other; good: billing; bad: 'angry customer' (that's sentiment, not a type)."

The counterexample is what separates a definition that reads well from one that holds. A positive example shows the model a target; a bad example fences off the specific mistake the field invites, and every ambiguous field has one — the plausible wrong fill that a definition-by-inclusion-only never rules out. The Turn a JSON Schema into a Prompt resource shows the readable form these definitions take — one line per field with its type and a description that constrains the value, plus a realistic example — the format a model follows far better than a bare name or raw schema syntax. Write the meaning and the include/exclude yourself; that resource is the shape they travel in.

Step 3: Keep source fields and judgment fields apart

This is the distinction that quietly breaks the most tables, so it gets its own rule: a field that holds what the source says and a field that holds what the model concludes must never be the same field. When "reason" is allowed to mean both, one row gives you the customer's own words and the next gives you the model's theory of the bug — and downstream, nobody can tell which rows are reported fact and which are AI inference, because they share a column. Split them: customer_reason captures what the ticket states, quoting or closely paraphrasing, and never adds a diagnosis; suspected_cause, if you want it at all, holds the model's read and is explicitly labeled as inference, not report.

For the source field, the definition should say "from the input only — do not infer," and for the judgment field it should say the opposite plainly: "this is the model's conclusion, mark it as such, and if the input doesn't support one, leave it empty rather than guess." The point isn't that inference is forbidden — sometimes the model's read is exactly what you want — it's that report and inference are different kinds of claim and a reader has to be able to tell them apart. A table that blends them looks like data and behaves like opinion. Keeping the two in separate, clearly-typed fields is what lets you trust the reported column and weigh the inferred one, instead of taking the whole row on faith.

Step 4: Give decision fields criteria, and every field a missing rule

A decision field like priority or status is only consistent if the rule that sets it is written down, because "high / medium / low" without criteria is just three words the model assigns by feel. Spell out what earns each value: "priority is high when the ticket blocks a critical workflow today, or carries legal, security, or payment risk, or is an enterprise escalation — not high because the customer is angry." That last clause matters more than it looks: naming the tempting wrong basis — emotion, loudness, message length — is often what stops the model from using it. An enum field needs its criteria as much as its list; the list says which values are legal, the criteria say which one a given row earns.

Then decide, per field, what happens when the answer isn't in the input — because eventually it isn't, and an undefined absence is where consistency dies. Set one rule and state it: an absent value returns a specific marker — an empty string, a null, or a literal "not_stated" — and the model never fills a field it can't support from the source. This is especially strict for the judgment fields and the decision fields: a suspected_cause with no evidence gets the missing marker, not a guess; a priority that can't be determined is flagged for review, not guessed at. The Missing Data in AI Extraction resource lays out the handful of missing-value behaviors and when each is right — a visible, agreed marker in every row beats a mix of blanks, "N/A", and quietly invented values.

The JSON Output Prompt Builder is where these field definitions become a prompt: you give it each field with its type, its allowed values, and a one-line description, and it assembles the structured-output contract the model fills against. It carries the type and the allowed values into the output; the plain-language meaning, the include/exclude, and the criteria are the descriptions you write into each field. It assembles the prompt; you run it in your own AI tool, on your data.

Step 5: Define first, fill a sample, then check consistency

Field definitions are a draft, so review them before you fill anything, and test them before you trust them. Read each definition and ask what the model can't: is "priority" really impact-and-urgency in your world, or did you mean something else? Does "issue_type" cover the categories your tickets actually produce, or will half of them land in "other"? Edit until the definitions match your data and your intent — this is the step that makes every later row consistent, because the model stops filling by feel and starts filling by your rules. Then run the approved definitions on a small, deliberately awkward sample — a ticket that's angry but low-impact, one where the cause is unstated, one that fits two categories — and read the filled rows against the definitions, not just for shape but for logic: did priority follow the criteria, did customer_reason stay free of diagnosis, did the missing rule fire?

Where the sample drifts, the fix is almost always the definition, not the data: a criterion that was still fuzzy, an exclude you didn't state, a missing case the rule didn't cover. A structural check helps you see the drift — the Validate Structured Output from AI resource shows how to catch a missing field, an invented one, or prose creeping into the object — but be clear on what that catches and what it can't: it confirms the shape obeys the contract, not that a value obeys your definition or is correct. "priority: high" is valid structure and can still be the wrong call. So the final read is yours: the definitions are candidate rules you approve, the filled rows are candidate data you verify against the source, and for anything with legal, financial, medical, security, or compliance weight, that verification belongs with the domain owner, not the model.