Checking What the Model Asked For
Last timeDescribing a Tool Well
The program should treat a requested call the way it treats a form submitted by a stranger: check the shape, the values and the permission, and refuse in a way the model can recover from.
A requested call is untrusted input
A web application receiving a form from the public internet validates every
field, and nobody argues about it. The call a model requests deserves exactly
the same treatment, for two separate reasons.
The first is that the model is unreliable. Not malicious, just wrong
sometimes, in the ways the previous lesson described: an amount in the wrong
units, an identifier in the wrong format, a value outside the allowed set.
The second is more serious. The text the model produced may have been
influenced by content the system fetched earlier, which is the subject of the
seventh lesson. A request that arrives at the program carries no evidence of
where its contents came from, which means it cannot be given any standing at
all.
| applies to a web form | applies to a model call | usually written | cost to write | |
|---|---|---|---|---|
| does the field exist | 1 | 1 | 1 | 1 |
| is it the right type | 1 | 1 | 1 | 1 |
| is it in the allowed ran | 1 | 1 | 0 | 1 |
| is the caller permitted | 1 | 1 | 0 | 2 |
| is it the right shape of | 1 | 1 | 0 | 1 |
| is the action rate limit | 1 | 1 | 0 | 2 |
The four checks
In order, because the order matters for what the error message can say.
Does the tool exist. A model will occasionally request a tool that is not in
the list, often one that would be reasonable to have, and the rejection should
name the tools that do exist.
Is the request well formed. The right values present, of the right types,
identifiers matching their expected shape. This is schema work and it should
be generated from the same definition the description was generated from, so
the two cannot drift apart.
Are the values allowed. A refund not exceeding the order total. A date range
not longer than a year. A row count within the limit. This is where business
rules live and it is the check most often absent, because the rules are known
to the people who built the tool and were never written down anywhere a
program could read.
Is the caller permitted. Not whether the model is permitted, which is a
meaningless question, but whether the person on whose behalf the system is
acting may do this to this record. A system that holds broad credentials and
acts for a specific user has to apply that user permissions itself, because
nothing else will.
- calls made
- the share of them that are bad in some way
- bad calls you are willing to let through
- the share of bad calls validation must catch
Refusing in a way the model can use
A rejection is not the end of the interaction. It goes back into the
conversation, the model reads it, and it tries again. So the rejection is an
instruction, and its quality determines whether the second attempt is right.
The lesson stops here
3 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