Example Selection Criteria

The wrong examples actively harm performance. Examples that are too easy create a model that handles easy cases well and hard cases poorly. Examples that are too similar create a model that handles one type of input and fails on variations. Selection is not a matter of taste — it is a structured decision.

1. Representativeness Examples must cover the input distribution you will encounter in production, not the inputs that are easiest to solve. If 40% of real requests are edge cases, at least 1-2 of your examples should be edge cases. "Representative" means representative of reality, not representative of the ideal.
2. Format Demonstration At least one example should showcase every output format element you require. If outputs need a header, a bulleted list, and a closing statement — make sure these all appear in your examples. Absence of a format element in examples predicts absence in outputs.
3. Difficulty Variation Include at least one straightforward case and at least one complex case. The straightforward case anchors the baseline. The complex case shows how to handle ambiguity, missing information, or competing constraints. Both are necessary.
4. Quality Ceiling Examples are the upper bound on quality — the model calibrates to them. If your examples are mediocre, your outputs will be mediocre. Every example should be the best output you could produce for that input. Do not use examples you wouldn't ship.

Before finalizing your example set, verify:

□ Examples cover the real input distribution (not just easy cases)
□ Examples cover every required output format element
□ At least one example shows handling of ambiguous/incomplete input
□ At least one example shows edge case behavior
□ Every example represents the quality level you want to receive
□ Examples are not all from the same category/type/domain
□ No example is so long it signals "long responses are acceptable" if they aren't
□ No example is so short it signals "short responses are acceptable" if they aren't