The first thing I write down about any system is what it is not allowed to do.
What it may never do, however good it gets at everything else. The list is short, it is usually the hardest part of the design, and it is almost always the part that gets skipped.
Most of the conversation about AI in organizations runs the other way. A demo shows what the tool can do, somebody asks how soon it can do it here, and the question of what it should refuse arrives later — usually right after the first time it did something nobody expected. By then every rule is a patch.
Four refusals I built on purpose
I run my own work and home life through a system I built, and the parts of it I trust most are the parts that say no.
The investing engine cannot place a trade. It reads everything I give it and can do nothing with it. No trade API, no brokerage login, no setting somewhere that turns execution on. That is the architecture, not a setting. It produces a score, the score feeds a written memo, and a person decides at the bottom of the memo.
The filing router is allowed to fail. When a note arrives that it can’t confidently place, it doesn’t force it into the nearest folder. It puts it in a queue for me. Giving it permission to say “I don’t know where this goes” did more for the quality of the whole system than any improvement to the classifier.
The tractor log won’t invent a date. Eight years of maintenance on memory left gaps, and the easy thing would have been to fill them with plausible guesses. Instead, anything undated carries an amber verify flag. The flags are ugly. They are also the only reason I trust the green ones.
The hunting engine has never once said go. Forty-one stands, none validated, every area on hold. That is not a broken system. It is a system that will not recommend a morning on evidence it does not have, and it is working exactly as designed.
Refusals cost something
I want to be straight about the price, because it is real.
A queue has to be drained. A grey tile on a dashboard invites the question “why isn’t this done?” A system that says no when you wanted a yes is irritating in the moment, every time, and the temptation to add an override “just for this case” never goes away.
That temptation is the whole test. An override added for convenience is a refusal you have quietly withdrawn, and you usually withdraw it on the one day it mattered.
Where the people stay
In a household this is a design habit. In an organization it is something more important.
The refusal list is where you decide which judgments stay with people. Every line on it names a decision a person owns — who approves the money, say, or who signs the letter that goes out with the organization’s name on it. When that list exists before the automation does, adopting AI is mostly a question of what to hand over. When it doesn’t, it becomes a question of what got taken, and nobody can quite say when.
So that is the order I work in now. Before choosing a tool, write down what it may do on its own, what it may do only with review, and what it may never do. The first two lists will change as the tools get better. The third one shouldn’t change much at all.
Write the refusals first. The capabilities will take care of themselves. They always do.
■