There is a special kind of confidence that appears just before a rule meets a person.
The rule looked complete in the meeting. It fit on one slide. It survived the test suite. Everyone agreed that the categories were clear, the inputs were known, and the result would be consistent. Then someone arrived with a name the form could not accept, a body the sensor could not read, a family the dropdown did not describe, or a way of speaking the system had not anticipated.
We tend to call this an edge case.
It sounds technical and harmless. The center is where ordinary life happens; the edge is where unusual things occur. We can support the edge later, perhaps after launch, when there is time. Yet the person standing there is not experiencing themselves as an edge. To them, this is simply Tuesday.
What if the exception is not evidence that a person is unusual? What if it is evidence that our rule was smaller than the world?
The comfort of a clean category
Software requires categories. A database column needs a type. A function needs to know what it can receive. A security policy needs to distinguish permitted action from forbidden action. We cannot build anything if every decision remains permanently open.
The trouble begins when a necessary simplification starts presenting itself as a complete description of reality.
In Purity and Danger, the anthropologist Mary Douglas examined how societies decide what belongs where. Her famous observation was that dirt is not an absolute substance. Dirt is “matter out of place.” Mud in a garden may be welcome. The same mud on a kitchen floor becomes a problem. The material has not changed. The category has.
This is a useful way to think about the systems we build. A value rejected by a form is often not meaningless. It is meaningful data in a place where the designer did not expect it. A user flagged by a fraud system may not be behaving irrationally. They may be living a life that does not resemble the life represented in the training set. A colleague who breaks the team’s preferred workflow may not be careless. They may be carrying a responsibility the workflow never accounted for.
When the system says “invalid,” we should sometimes hear a quieter sentence underneath it: “I do not know what to do with you.”
That is a confession of limited knowledge, not a verdict on the person.
What a map leaves out
James C. Scott’s Seeing Like a State explores what happens when institutions try to make complicated human communities legible. Forests become inventories of timber. Neighborhoods become grids. Citizens become standardized records. Legibility makes administration possible, but it also erases forms of knowledge that do not fit the map.
A map is useful precisely because it leaves things out. If it included every pebble, footstep, smell, memory, and argument attached to a place, it would no longer help us navigate. The ethical failure is not making the map. It is forgetting that we made one.
Our software is full of maps. A user profile is a map of a person. A performance review is a map of a year’s work. An access role is a map of trust. A model’s output is a map of patterns found in its training. These representations can be extraordinarily useful. They can also become dangerous when we confuse what is legible to the system with what is real.
Developers are trained to reduce ambiguity. That is part of the craft. We turn a vague request into a specification, a specification into behavior, and behavior into tests. But moral life asks us to preserve a little ambiguity too. It asks us to remember that the specification may be wrong, the behavior may exclude, and the passing test may only prove that the machine faithfully implemented our incomplete imagination.
The question is not whether our categories have edges. Every category does. The question is what happens to a person when they reach one.
The person who pays for our certainty
Consider the familiar instruction to “contact support” when an automated process fails. For the team that designed the process, support is the escape hatch. For the person using it, support may mean gathering documents, repeating a painful story, waiting without a deadline, and trying to persuade a stranger that their life is real.
The clean interface remains clean because the mess has been transferred to someone else.
This transfer is easy to miss. The team measures how many people pass through the standard path, then celebrates the efficiency of the design. The people who do not fit become a small percentage in a report. Their difficulty is statistically minor, even when it is personally enormous.
There is nothing wrong with measuring the common path. There is something wrong with treating frequency as a measure of moral importance.
A rare medical condition is still devastating to the person who has it. An uncommon name is still someone’s name. A small religious community still experiences a mandatory meeting scheduled on its holy day as mandatory. A single employee whose disability is incompatible with a new tool does not become less real because everyone else adopted it smoothly.
Scale tempts us to believe that small groups deserve small attention. Ethics pushes in the opposite direction. The fewer people affected, the easier it is for their experience to disappear. That is exactly when deliberate attention matters most.
Designing a merciful failure
We will not anticipate every life. No research process is complete enough, no team diverse enough, and no test suite imaginative enough to eliminate surprise. Humility in design does not mean refusing to create rules. It means designing rules that know they can be wrong.
A humble system explains what happened in language a person can understand. It provides a meaningful path to appeal. It allows a human being to exercise judgment. It records recurring exceptions so that yesterday’s surprise can become tomorrow’s supported path. Most importantly, it does not make the user carry the shame of the system’s ignorance.
This matters inside engineering teams too. Code review can ask, “What happens when this assumption fails?” Product planning can ask, “Who has to do extra work so this experience feels simple?” Leadership can ask, “Which people are absent from the metric we are celebrating?” None of these questions make a project slower by definition. They make its definition of success more honest.
There is also a deeper professional habit at stake. Every time we encounter an exception, we are given a choice. We can defend the rule, or we can become curious about the world that exceeded it.
Defending the rule feels efficient. Curiosity feels like delay. But curiosity is often where the real engineering begins. The unexpected input teaches us about the domain. The inaccessible workflow teaches us about the body. The confused user teaches us where our language failed. The exception is not noise around the product. It is information about the product’s relationship to reality.
Perhaps the most responsible sentence a system builder can say is not “We handled every case.” It is “We built a way to discover the cases we missed.”
There will always be another person at the edge of our map. When they arrive, will our system tell them that they do not belong, or will it let their presence redraw the map?