Decide the output format before you pick the model
A product manager at a document-heavy law firm kept arguing about which model to use. The real fight was about what shape the answer had to come out in, and nobody had settled it.
Decide the output format before you pick the model
A product manager at a document-heavy law firm told me her team had spent three weeks comparing models for a contract review tool. Which one read clauses best. Which one hallucinated less. Which one was cheaper per page. She had spreadsheets. What she did not have was agreement on one thing that turned out to matter more than any of it: what the answer was supposed to look like when it came back.
Half the team pictured a paragraph. A short written summary a lawyer could skim, flagging risky terms in plain language. The other half pictured a table. Clause type, risk level, page reference, one field per row, ready to drop into their review checklist. Those are not two versions of the same feature. They are two different products, and they demand different work underneath.
She had been treating output format as a detail to settle later. It is one of the first scoping decisions, and it quietly sets almost everything downstream.
The format decides how you can evaluate it
If the answer is freeform text, you are grading prose. Was the summary accurate. Did it miss anything. Two reviewers can read the same paragraph and disagree about whether it was good enough. Your eval becomes slow and subjective, and it stays that way.
If the answer is structured, a table with fixed fields, you can check it. Did it find all the termination clauses that were actually in the document. Is the risk field one of the allowed values. Did the page reference point to a real page. You can write those checks once and run them on every document. The feature that returns structure is a feature you can measure. The feature that returns prose is one you argue about.
This is why the format is not a cosmetic choice. It sets the ceiling on how fast you can tell whether the thing is working.
The format decides how it plugs in
The lawyers at her firm did not want to read AI paragraphs. They wanted the risky clauses to land in the review checklist they already used, in the same columns they already scanned. A paragraph would have forced a human to read the summary and retype the findings into the checklist by hand. That is not automation. That is a second draft.
A director of operations at a logistics company once described the same trap from the other side. His team built a tool that wrote lovely shipment summaries, and every summary had to be manually copied into the tracking system because it came out as text, not fields. The tool worked. Nobody used it. The output did not fit the slot it was supposed to fill.
Ask early where the answer has to go, and let the destination pick the format. A checklist wants rows. A dashboard wants fields. An email wants prose. Decide that before you decide anything about the model.
The format decides how much people trust it
Freeform text hides its own uncertainty. A confident paragraph reads as authoritative whether or not it is right, and a reader has no easy way to see what it skipped. Structured output exposes gaps. An empty field is visible. A missing row is countable. When a lawyer sees a clause type with no entry, she knows to look. The structure gives her a place to catch the mistake.
For a review tool where a missed clause has real cost, that visibility is worth more than fluent writing. The format that shows its own holes is the safer one to put in front of a professional who is accountable for the result.
How we approach it at Density Labs
When we scope an AI feature in the AI Opportunity Assessment, our fixed two-week engagement at $2,500 that maps the real work before anyone builds, output format is one of the first questions we settle, not the last. We ask what the answer has to look like, where it has to go, and how you will know it was right. Those three answers usually narrow the model choice on their own, and they often reveal that the argument about which model to use was premature. You cannot pick the tool until you know the shape of the thing it has to produce.
The model matters less than teams think. The shape of the answer matters more.
Decide what the answer looks like before you decide what produces it.