Use this whenever an automation needs an LLM to turn free-text or an image into structured data another system can act on, not just chat back a nice-sounding answer.
Steps
- State the exact output shape up front: list every key you expect, with its type. Don't let the model infer the schema from examples alone.
- For any field with a limited set of valid values (like a category), spell out the exact list. Don't leave it open-ended, it invites drift over time.
- Add explicit formatting instructions: "no prose, no markdown fences, JSON only." Without this, models often wrap valid JSON in a sentence or a code block, which breaks naive parsing downstream.
- If your platform supports a JSON-mode or structured output flag (some APIs call this
responseMimeTypeorresponse_format), turn it on, it enforces the shape more reliably than prompt instructions alone. - Give the model a way to say "this isn't valid input" instead of forcing it to always return a fully populated object. Without this, ambiguous or irrelevant input gets force-fit into the schema anyway, producing confident-looking garbage.
Gotcha
A model instructed to "always return this JSON shape" will do exactly that, even when the input doesn't actually contain the data being asked for. If nothing in the prompt explicitly allows for "no, this doesn't apply," expect it to hallucinate plausible-looking values rather than flag the mismatch. Add a boolean flag or similar signal explicitly, and check it downstream before trusting the rest of the object.
Quick reference
Reply with ONLY a JSON object with keys: [list exact keys and types].
[field] must be one of: [exact allowed values].
If the input does not contain a valid [thing], set is_valid to false.
No prose, no markdown fences, JSON only.