Schema before prompt

When you finally reach the prompt, the work should already be mostly done. The best prompts are short, because the structure around them did the heavy lifting. That structure is the schema.

What this means

A schema is a fixed shape for your data and your output. Instead of "extract the important stuff from this document," you give the model a defined set of fields: parties, dates, obligations, amounts. Instead of "write a summary," you ask for a specific object.

The difference is the difference between a pile of text and a row in a database. Structured output is checkable, and checkable is the whole point.

Why schema beats prose

1. Checkable. You can validate the output against the schema automatically: is the date a date, is the field present, does the amount parse. Prose cannot be validated.
2. Composable. Structured fields feed the next step (a table, an API, another model) without re-parsing text.
3. Easier for the model. A model asked for a clear schema makes fewer mistakes than one asked to "do the right thing" in prose.

How to do it

1. Define the fields and their types before you write the prompt.
2. Ask the model for that exact structure (many runtimes support structured/JSON output natively).
3. Validate the result against the schema in code, not by eye.

The connection to your design

This is where the earlier lessons click: the objective defined what matters, the use-case model defined the entities, and the schema is those entities made explicit for the model. A "client has cases, a case has documents" model becomes a JSON schema the model fills in.

The rule

If you find yourself writing a very long prompt full of instructions, ask whether the shape of the problem should have been a schema instead. Long prompts are often a symptom that the structure is missing.

Schema first, prompt second, and the prompt writes itself.