A Form With Boxes
Think of a hardware shop with a wall of small drawers, each with a label: long screws, short screws, nails, hinges. The drawers decide where every part must go, and a part that fits no label has nowhere to go at all. But the drawers cannot stop an assistant from putting a nail in the screws drawer. They fix the places, not what goes in them.
When a program uses a model's reply, it usually needs a form like this: named fields, each with a value of a known kind. The common way to write such a form in text is JSON. This lesson asks a model for a small JSON object in four different ways, from simply describing it in words to handing Ollama an exact description of every field, and measures what each way guarantees and what it does not.
The short version: all four ways gave valid JSON on this task. The differences were in the details that a program cares about, and the most useful result is the one reply where a schema made the output pass the format checks while making the answer wrong.
Asking for a Shape
JSON. A standard text format for data that programs read easily. An object is written inside curly brackets as a list of fields: {"category": "billing", "needs_human": true}.
Field. One named value in the object, such as category. A field has a type: a string (text), a number, or a boolean (true or false).
JSON mode. An Ollama option, "format": "json", that makes the reply valid JSON. It says nothing about which fields the JSON must have.
Schema. A JSON schema is a description of the exact object you want: which fields, of which types, which are required. You pass it to Ollama as "format" instead of the word json.
Enum. Part of a schema: a fixed list of allowed values for one field, such as the four categories.
With a schema, Ollama limits the model while it writes: at each step, only the tokens that keep the reply inside the schema are allowed. It does not check the finished reply again afterwards. This detail explains most of what the lab found.