Limits and shape: output you can use as is

In the request checklist, Limits and Shape are the two parts that turn a "decent" result into one you can use as is. This lesson covers both, plus a rule that is often forgotten: what the model must do when data is missing.

Limits answer three things. What must not be done: for example, add no facts beyond the material, do not name customers, do not promise dates. How long: write a number, not an adjective. "Short" to you might be three sentences, to the model three paragraphs. "At most 120 words" or "five bullet points" is far clearer. What tone: "friendly but direct, no opening pleasantries" is easier to follow than "nice to read". Keep in mind that the length you ask for is a request. The hard limit on how much text the model may write is usually set by the app, as explained in the lesson Tokens and the context window.

Shape answers one question: what form can you paste straight into your work? If the result goes into a spreadsheet, name the columns one by one and in order. If it is an email, ask for a subject line, greeting, body and sign-off. If it is for a slide, ask for short bullets without long sentences. A clear shape saves editing time and also makes the result easier to check, because every part is in the same place every time.

Then the rule for missing data. Models are trained to give complete answers. If the material has no price, warranty or date, the model tends to fill it with something plausible. That is why you write the rule: "If something is not mentioned in the material, write 'not mentioned'. Do not guess and do not write zero." Missing data does not mean the value is zero, and it does not mean it may be made up. With this rule an empty cell becomes information: you know exactly what to ask about again.

The three support each other. Clear limits keep the model from wandering, a clear shape makes the result easy to read, and the missing-data rule makes the gaps visible. After a few tries, writing all three takes a minute.

A few habits make limits easier to follow. Say what to do, not only what is forbidden: "use short sentences, one idea per sentence" helps more than "don't ramble". If a ban really matters, give the reason, for example "do not mention prices, because the new prices are not approved yet". A reason helps the model apply the ban to cases you did not list.

Capital letters and exclamation marks do not make a limit stronger. Clarity and placement do. Put important limits near the end of the request, after the material, so they do not sink under long text.

For shape, one sample row is often clearer than an explanation. If you want a table, write the column headings and one sample row with content that is obviously made up. If there are filling rules, give them per column: dates as day-month-year, money without thousand separators, the status column only "done", "in progress" or "not started".

Limits you use again and again, such as your office's writing style or a ban on customer data, do not need rewriting every time. Many apps offer a place for system instructions or standing instructions. How to write them is covered in the Produce real work module.