Designing JSON Outputs For A Tiny Model
A practical owner guide to choosing fields, rules, examples, and review checks before a focused local model is trusted to return structured results.
Start With The Business Decision
A tiny model becomes easier to trust when its answer has a clear shape. For many useful workflows, that shape is JSON. A support message can become a department, urgency level, and short summary. A lead form can become a readiness score, missing fields, and next action. A document note can become dates, names, amounts, warnings, and a confidence note.
The mistake is starting with the JSON before deciding what the business will do with it. Structured output is not valuable because it looks technical. It is valuable because another system or person can act on it without guessing. Before training or prompting a tiny model, write down the decision that happens after the output appears. Will a lead move to human follow up. Will a ticket enter a queue. Will a manager review a warning. Will a record be archived.
Once that decision is clear, the fields become easier to choose. Each field should either help a person act, help software route the item, or help the owner review quality later. If a field will not change any action, it probably does not belong in the first version.
Keep The Schema Small At First
A focused local model works best when the target is narrow. The same principle applies to JSON. Start with a small schema that can survive ordinary messy inputs. A first version might need five to eight fields, not thirty.
For a support routing model, the first schema may include category, urgency, summary, missing information, and needs human review. For a sales intake model, it may include budget range, timeline, service fit, reason, and suggested next step. For an operations note model, it may include task type, owner, due date, risk level, and follow up question.
Small does not mean weak. A small schema is easier to explain, easier to test, and easier to correct. It also reduces the chance that the model invents details just because the schema asks for too much. If the first version proves useful, new fields can be added later from real review notes.
A good rule is simple. If a normal reviewer cannot explain why a field exists, remove it or rename it. The schema should read like an operations checklist, not like a database designed before anyone understands the workflow.
Name Fields In Plain Language
Field names shape behavior. If the names are vague, the output becomes vague. A field named status may mean too many things. A field named next_action is clearer. A field named priority may invite debate. A field named response_urgency is easier to connect to a service rule.
Use names that match the words already used by the business. If the team says ready for call, needs details, and archive, use those values. If the team uses billing, tech support, delivery, and owner review, use those exact categories. A tiny model should learn the owner vocabulary, not force the owner to translate every result.
Also decide which fields are required and which fields are optional. Required fields should be safe to answer for nearly every input. Optional fields should be allowed to stay empty when the information is absent. This matters because empty can be an honest answer. A model that knows when to leave a field blank is often safer than a model that fills every box with a guess.
Give The Model Allowed Values
Free text fields can be useful, but allowed values make a tiny model easier to test. If urgency can only be low, normal, high, or owner review, quality checks become straightforward. If category can only come from the accepted queue list, routing mistakes are easier to spot.
Allowed values also protect the workflow from creative phrasing. A large model may write a pleasant phrase that sounds correct but breaks the next step. A tiny model should prefer boring reliable labels. For structured output, boring is a feature.
Add a short definition beside each allowed value in the handoff packet. High urgency might mean the customer is blocked, a deadline is near, or money is at risk. Owner review might mean the request is unclear, sensitive, outside policy, or too important for automatic handling. These definitions help example writers label data consistently, and they help reviewers explain corrections later.
Include Missing Information As A First Class Field
Many workflows fail because the model tries to answer from incomplete input. A better pattern is to make missing information visible. Add a field that lists what is absent, unclear, or needed before action.
For a lead intake model, missing information might include budget, location, timeline, contact method, or project type. For a document extraction model, it might include date, signer, amount, address, or reference number. For a support model, it might include account id, error message, order number, or device type.
This field is useful even when the rest of the output is not perfect. It tells the human reviewer what to ask next. It also keeps the model from pretending certainty. In many business processes, the best next step is not an answer. It is a clear follow up question.
Train With Good And Bad Examples
A tiny model needs examples that show the desired JSON shape, but it also needs examples that show restraint. Include clean inputs where every field is obvious. Include ordinary messy inputs where the correct answer requires a missing information note. Include edge cases where the model should choose owner review instead of forcing a category.
Do not make every training example look perfect. Real submissions include spelling mistakes, pasted signatures, mixed languages, partial sentences, and extra context. The model should see those shapes during preparation. Private details should be removed or replaced with safe placeholders, but the structure of the mess should remain.
For each example, keep the original input, the correct JSON, and a short reason. The reason does not need to be included in the final model output, but it helps the builder understand the rule. It also helps later when someone asks why a label was chosen.
Validate Format Before Trusting Meaning
Structured output has two layers of quality. First, the output must parse. Second, the answer must be correct. Test both.
The first test is mechanical. Can the output be read as valid JSON every time. Are required fields present. Do allowed value fields stay inside the approved list. Are numbers returned as numbers when the receiving system expects numbers. Are empty values represented consistently.
The second test is human. Did the model choose the right category. Did it capture the missing details. Did it summarize without changing facts. Did it mark sensitive or unclear cases for review.
Do not skip the mechanical test because the demo looks good. A single broken brace or unexpected label can stop an automation. Tiny Model Generator should include format checks in the eval report so the owner knows whether the model is ready for a real handoff.
Add A Human Review Rule
A structured tiny model should not pretend to be final authority in every case. Add a review rule to the schema. This can be a boolean field like needs_review, an allowed value like owner review, or a confidence note that explains uncertainty.
The review rule should trigger when the input is unclear, when the request is outside the known categories, when private or sensitive judgment is involved, or when the model detects missing information that blocks action. This protects the business and makes the model more useful. Instead of failing quietly, it raises a flag.
The owner should decide what happens to review items. They may go to a dashboard, an inbox, a spreadsheet, or a simple queue. The important part is that review is designed before launch, not added after the first confusing output.
Make The First Version Easy To Improve
The best structured output project leaves a trail for improvement. Save examples where the model returned invalid JSON. Save examples where the format was valid but the decision was wrong. Save examples where the owner changed a label or added a missing detail.
Those review notes become the next dataset. They show which field names are confusing, which allowed values need clearer definitions, and which edge cases deserve new examples. A tiny model does not need to become large to improve. It needs a clean loop from real usage back into better examples and better rules.
For an owner, the practical goal is simple. Start with a small schema, make every field useful, test the format, test the meaning, and keep human review visible. When that foundation is in place, a tiny model can return structured results that software can use and people can trust.