Your few-shot examples show a bare label but the task asks for a label plus a reason. What breaks?

## Instruction versus demonstration A few-shot prompt usually contains two descriptions of the task: a written instruction near the top, and a set of worked examples below it. When they agree, nothing interesting happens. When they disagree about the *shape* of the answer, the examples generally dominate. The reason is mechanical. The model is continuing a sequence, and the strongest local evidence about what comes next is the pattern in the immediately preceding tokens — three records that each ended after a single label. The instruction is a general claim sitting further back in the context. It is not ignored, but it is competing against a concrete, repeated, adjacent template, and the template usually wins. ## The characteristic symptom is inconsistency What makes this bug annoying is that it rarely fails cleanly. On some inputs the instruction wins and you get `fast_track — low value, single peril`. On others the pattern wins and you get `fast_track`. On a few you get a bare label followed by an unrequested paragraph. A parser written against the first sample breaks on the second, and because the split depends on the input, it survives a quick manual test and fails in production. If you see a prompt whose output format is *usually* right, the first thing to check is whether the exemplars actually demonstrate the shape the instruction asks for. ## Shape-matching, stated as a rule Make the demonstration a literal specimen of the response you want: 1. **Every field you expect back appears in every exemplar.** Not most of them — every one. A field present in three of five exemplars teaches the model that it is optional, and you will get it about that often. 2. **The fields appear in the order you want them generated.** The model produces the record top to bottom; if you want the reason after the decision, show it after the decision in every example. 3. **The value style matches too.** If you want a one-line reason, do not demonstrate three-sentence reasons. The exemplars set the expected length, register and vocabulary just as firmly as they set the field list. 4. **The live query stops at the first field to be produced**, so the model completes the record rather than starting a fresh answer. ## The mismatch runs both ways The expensive direction is often the reverse of the one in the question. Teams build a prompt with richly explained exemplars because it reads well during development, then ship it in a path that only consumes the label. Every call now generates a rationale nobody reads: more output tokens, higher cost, and — because output tokens are generated one at a time — meaningfully more latency on a per-request path. If the consumer wants a label, demonstrate a label. There is also a middle case worth naming: you want a justification, but for humans reviewing flagged cases only. Rather than have every response carry one, the usual designs are a second, cheaper call on the subset that needs it, or two clearly separated fields so the consumer can drop one — but the demonstrations must reflect whichever you choose. The format you show is the format you buy. ## Diagnosing it Given a prompt with unstable output shape, work in this order. First, read the exemplars as if you were the model: what record shape do they demonstrate, field by field? Second, compare that shape to what the instruction asks for and to what your parser expects — three descriptions that must agree. Third, check whether any field is present in some exemplars and absent in others; that is the single most common cause of intermittently missing fields. Only after those should you reach for instruction rewording, because rewording an instruction to fight the demonstrations is arguing with the stronger signal. ## What this is not Shape-matching demonstrations makes the desired output *likely* and stable. It does not make the wrong shape impossible — the model can still emit a malformed record on an unusual input, and any consumer parsing the response needs to handle that. Guaranteeing structure is a separate, decode-time concern with its own tooling. Demonstration format and generation-time enforcement solve overlapping problems from different ends, and a strong answer keeps them distinct: format the examples so the model *wants* to produce the right shape, and validate on the way out because it sometimes will not.