Asking for a Shape
Last timeShowing Instead of Explaining
When a program has to read the answer, the shape has to be specified, validated and repaired, because it will come back broken often enough to matter.
Asking for a shape
Once a program rather than a person reads the answer, the answer needs a shape,
and the shape should be the simplest one that carries what is needed.
Every piece of structure is something that can come back wrong. A single word
from a fixed list almost never fails. A flat record of four fields fails
occasionally. A nested structure with a list of records inside it, each with
optional fields, fails regularly. So the first question is whether the task
genuinely needs the structure it is being given.
The specification itself works best as a named shape with an example filled in.
A description of the fields leaves a dozen things open, and one filled example
settles them: whether a missing value is an empty string or absent, whether
numbers are quoted, whether the list may be empty, whether the order matters.
SHAPE = """Reply with exactly this shape and nothing else:
{"category": one of billing, delivery, technical, other,
"urgency": a whole number 1 to 5,
"order_id": the id if the message names one, otherwise null,
"summary": one sentence}
For example:
{"category": "delivery", "urgency": 3, "order_id": "A-4192",
"summary": "Asks where a parcel posted on Tuesday has got to."}"""
ok, problem = validate(reply, SHAPE) # shape only, not meaning
if not ok:
reply = model(body + broken_note(reply, problem)) # one repair attemptWhen it comes back broken
However clearly the shape is specified, some share of answers will not match
it. A field will be missing, a number will arrive as a word, the output will be
wrapped in an explanatory sentence, or a list will have one item too many.
- the share of answers that arrive broken
- the share you are willing to leave broken
- the share of broken answers the repair must fix
Validating and repairing
The mechanism is small and the details matter.
Validate the shape as soon as the answer arrives, against the same definition
that was sent in the request, so the two cannot drift apart.
On a failure, make exactly one more attempt, with the broken output and the
specific complaint attached: the field that was missing, or the value that was
not one of the allowed ones. A general note saying the output was invalid works
much less often than a specific one, for the same reason a good rejection
message works in a tool using system.
Stop after that one attempt. A second repair rarely succeeds where the first
failed, and the right behaviour is to record the case and return a failure the
rest of the system can handle.
The lesson stops here
2 more paragraphs to go
You have read the opening. The rest of the argument, the problems that check whether it landed, and the lines worth keeping at the end all come with a plan.
The first lesson of every course in the library reads the whole way through, free, so you can see exactly what the rest of them are.
See the planThe contentsThis is the reading half
Starting the course gives you your own copy of it. Every idea on every page has problems standing under it, marked with a reason rather than a tick, and any sentence you do not believe can be opened and argued with. None of that can happen on a page nobody owns.
The contents