Ask for the format your next step needs, not the one that looks tidy

Readable and machine-readable pull in opposite directions

A response arrives with bold headings, a numbered list, a short introduction and a closing remark, and it looks like a professional document. Then you try to move the useful part of it into a spreadsheet, and you discover that the numbers are embedded in sentences, two of the entries have been merged because they were related, and the introduction has no obvious boundary.

That output was not badly made. It was made for a reader, because nothing in the request said otherwise, and a reader benefits from the framing sentence that a parser chokes on. The tidiness that impressed you on screen is the exact property that makes the result expensive to use.

So the first question about format is not what looks good. It is who or what receives this next, and what that receiver is capable of ignoring. A person ignores stray commentary effortlessly. A script does not ignore anything, which is why the specification has to be stricter than it feels necessary to be.

Choose a format the receiver already knows how to read

If the next step is a spreadsheet, ask for delimited rows and name the columns in order. If the next step is code, ask for a single object with named fields and nothing outside it. If the next step is a person skimming on a phone, ask for short paragraphs and no table at all, because tables collapse badly on narrow screens.

Inventing a bespoke layout is where people lose time. A homemade arrangement of dashes and pipes has to be described in full, gets interpreted slightly differently on each run, and needs a parser you now have to write and maintain. Common formats survive because everything downstream already understands them.

The same reasoning applies to how much you ask for in one response. A structure holds together well over a short output and degrades over a long one, so a request for two hundred rows in a strict layout is more likely to drift than four requests for fifty. Length is a format decision even though it never looks like one.

Name the fields, and say what an empty one contains

A field list is only half a specification. The other half is what happens when the source material does not supply that field, and leaving it unstated is the most common reason a structured pipeline breaks in a way nobody notices for a week. Something has to go in the gap.

State it directly: if the date is not stated in the document, the date field is the word unknown. That single sentence converts a silent invention into a value you can filter on. Without it, the plausible-looking guess sits in the column alongside the real values and is indistinguishable from them at a glance.

Types deserve the same treatment. Say whether a quantity is a bare number or a number with a unit attached, whether a date is written out or in a fixed numeric order, and whether a field may hold several values or exactly one. Every ambiguity you leave gets resolved differently on different inputs.

The wrapping is what usually breaks the parse

The structured part is often correct while the response as a whole is unusable, because a friendly sentence has been placed before it and a summary after it. A parser handed that text fails on the first character. The fix is to say that the response must begin and end with the structure and contain no other text, which is a requirement people find oddly rude to write and which works.

Even then, expect the wrapping to reappear occasionally, particularly on inputs that confused the tool. A step that strips anything before the first opening bracket and after the last closing one costs a couple of lines and removes an entire class of intermittent failure from your process.

It also helps to make the failure loud rather than clever. A parser that quietly skips a malformed record leaves you with a short file and no explanation, while one that stops and shows you the offending text tells you immediately whether the problem is the instruction or the input.

Sometimes the structure is the wrong thing to ask for

Rigid formats suppress the parts of an answer that do not fit the boxes. Ask for a judgement as a score out of five and you will get a number, including for the cases where the honest response was that the question does not apply to this document. The container has no room for that, so it gets discarded.

For analytical work the better arrangement is often to ask for the reasoning in prose and only then, in a separate request, to reduce it to fields. You keep the nuance where the nuance is useful and impose the structure at the point where a machine takes over, rather than making both requests fight for the same response.

The general rule holds up well enough: structure the output when something mechanical consumes it, and leave it open when a person does. What you should not do is impose a strict shape because it looks organised, then spend your afternoon reading between the cells for the thing the shape squeezed out.