Build systems that absorb the variability of human input rather than rejecting it. Accept any reasonable format, normalise behind the scenes, and produce consistent, precise output every time.
In 1980, Jon Postel — one of the engineers who designed the core protocols of the internet — wrote a principle into the specification for the Transmission Control Protocol: “Be conservative in what you do, be liberal in what you accept from others.” He was writing about network software, but the principle describes something universal about the relationship between any system and the humans who use it.
Humans are inconsistent. They spell things differently, format data differently, express the same intention through completely different words, and make the same mistakes repeatedly. A system that demands precise, correctly formatted input at every step is a system that spends most of its energy enforcing its own expectations on users rather than doing the thing users came for. Postel's Law inverts this: make the system flexible on input, precise on output. Absorb the mess. Produce clarity.
“Be conservative in what you do, be liberal in what you accept from others.”
— Jon Postel, RFC 761, 1980
A phone number is a phone number. Whether someone types “555 867 5309”, “(555) 867-5309”, “555.867.5309”, or “+1-555-867-5309”, the intent is identical and the information is the same. The system knows how to store a normalised phone number. The question is whether the work of arriving at that format belongs to the user or the system.
Rejecting any format that doesn't match a specific pattern — “Please enter numbers only, no spaces or dashes” — is the system asserting its own convenience over the user's. Accepting any reasonable format and normalising it behind the scenes is the system doing its job.
The normalised output shown in the good example is the conservative half of Postel's Law: regardless of what format the user typed, the system stores and displays phone numbers in one consistent, internationally readable format. Liberal in, conservative out.
When a user types a search query with a typo and the system returns zero results, it has made a choice: enforce exact matching over user intent. The user knows what they meant. The system knows what they typed. Only one of those is useful information for deciding what results to show.
“Did you mean…” is Postel's Law applied to search. The system infers the most likely intended query, returns results for that query, clearly discloses what it did, and allows the user to override if the inference was wrong.
The “Showing results for” banner is the conservative output half of Postel's Law: the system doesn't silently correct and pretend the typo never happened. It transparently states what it did and gives the user an explicit path to override the inference.
The most common failure mode of AI assistants when faced with an ambiguous or underspecified request is to respond with a list of clarifying questions. The request was vague. Now the user has four questions to answer before anything useful happens.
Postel's Law applied to AI says: be liberal in what you accept. An AI practising this makes a reasonable set of assumptions, proceeds with a useful response, and states its assumptions clearly so the user can redirect if needed. The clarification loop collapses from four exchanges into one.
The assumption card is the Postel's Law disclosure mechanism: the system proceeded liberally, and now conservatively states exactly what it assumed so the user can verify or correct. One working draft plus transparent assumptions is almost always more useful than five clarifying questions.
Postel's Law asks a single clarifying question about every input field, search box, and conversational interface in your product: are we making the user do work that the system could do instead? Normalising a phone number, correcting a typo, inferring intent from a vague request — all of these are tasks that a system can perform more reliably than a human, every single time, at no marginal cost.
The conservative output principle is equally important. Flexibility in what you accept does not mean imprecision in what you produce. Phone numbers stored in inconsistent formats cause downstream failures. Search corrections that aren't disclosed erode trust. AI assumptions that are hidden lead to confusion when the output is wrong. Accept flexibly, output precisely, and always make your inferences visible.
Postel, J. (1980). DoD Standard Transmission Control Protocol. RFC 761. Information Sciences Institute, USC. The principle was later stated more explicitly in RFC 793 (1981) and has been applied as a software design principle far beyond its original network context.