Pre-Compiled Refusal

Colloquially: “The computer won’t let me do that.”

Context

A system encodes rules at design time about what kinds of requests can be processed. Reality produces a request that falls outside those rules but is, on examination, perfectly reasonable — the kind of accommodation a thoughtful human would make without hesitation. The system refuses. The line employee shrugs and says some version of “the computer won’t let me.” The customer absorbs the friction. The legitimate accommodation doesn’t happen.

This is the failure mode of encoding judgment as rule. Rules at design time can only anticipate the cases the designer thought of. Encounter time produces cases the designer didn’t think of and couldn’t have. The system has compiled away the practice that would have handled them.

Cost type

Primarily behavioral, borne by users and the business — not by developers. Lost customers, eroded trust, employee morale damage, regulatory complaints, brand damage. This is the rare entry in this catalog whose primary cost falls outside the engineering team. That makes it harder to surface in normal engineering channels, which is partly why it persists.

What goes wrong

• A customer requests a small accommodation (refund a partial day, change a delivery address mid-shipment, override a date constraint by 24 hours, combine two policies). It’s reasonable and would have been done in person. The system has no path for it. Refused.
• The line employee — who often understands the situation better than anyone else in the chain — has no authority to override because the rule lives in the system, not in their judgment. Their professional knowledge has been compiled away.
• The customer’s experience of “the company” becomes the company refuses things for no good reason. The actual people inside the company would have helped; the system wouldn’t.
• Workarounds metastasize. Employees develop unauthorized practices (“I can do it as a refund-and-re-bill”); customers learn to escalate aggressively; engineering teams add more rules to handle the edge cases the previous rules didn’t handle, accelerating the encoding spiral.

Prospective indicators

• Requirements language is shaped as “the system shall enforce X.” The enforcement framing pre-decides that the rule lives in code rather than in judgment.
• A use case description ends with “and if the customer wants something different, the system rejects it.” The “different” is being treated as out-of-scope rather than as the interesting case.
• Validation rules are accumulating without an escape valve. Each added rule reduces the surface for legitimate exceptions.
• Designers describe the rule using the verb force or ensure rather than support or guide.
• A new feature is being designed as additional rule logic rather than as a recorded event with a downstream judgment.

Retrospective indicators

• Customer service interactions where the CSR clearly knows what should happen but cannot make it happen.
• Internal documents (Slack threads, wiki pages, training materials) describing workarounds that aren’t in the official process.
• Customer complaints clustering around “your system won’t let me do X” rather than around “your service is bad.”
• Engineering tickets shaped as “add a rule for the case where customers want to do Y” — additions on top of additions, never replacing.
• “I’d love to help you with that, but…” as a verbal tic among service staff.

Prevention

• Encode at the right level. ACID (or its equivalent) for things that genuinely need atomicity — money transfers, inventory commitments, reservations. Practice for things that are encounter-laden — adjustments, accommodations, edge cases. The mistake is using the same mechanism for both.
• Event-sourced architectures (and the broader outside-data discipline — Pat Helland, Data on the Outside vs. Data on the Inside) preserve the encounter as a record of what happened, leaving the projection of state to a layer that can be reasoned about per-case rather than locked in advance.
• AI-assisted projection layers — reasoning over the event stream at encounter time to propose the right action for this case, with human authorization — are the architectural shape that gets practice back into the loop without abandoning audit, compliance, or consistency. See ../post-conversational-design.md.
• Treat “the system shall enforce” as a smell at requirements-gathering time. Replace with “the system shall record what happened, surface anomalies for judgment, and execute decisions once authorized.”
• Give line employees a bounded escape valve: a documented, audited path for “this rule doesn’t fit this case; here’s what I’m going to do instead.” Compliance is preserved (the deviation is recorded). The customer is served (the deviation is permitted). The audit log is now the truth; the rule is now a default.

When this isn’t a failure mode

• Domains where the rule genuinely is the substance: regulatory minimums, security controls, financial atomicity, anything where a deviation is a violation rather than an accommodation. ACID-grade enforcement is correct here.
• High-volume low-stakes interactions where the cost of judgment exceeds the cost of refusal (consumer-grade self-service flows where the user can route around the limitation cheaply). The friction is real but bounded; building a judgment layer would be more expensive than the friction.
• Cases where the rule was correct but the requestor is genuinely out of scope (the request is unreasonable, not edge-case-reasonable). The catalog can’t tell you which is which; the team has to.

Note

This is the first entry in the catalog whose primary victim is the user, not the developer. It also originates from a sphere mismatch: business-encounter logic (which lives natively in the outside-data / event-sourced sphere) gets implemented in inside-data / ACID-shaped systems. The mismatch propagates from architecture choice up through application logic and out into the customer-facing UI, where it surfaces as the colloquial “the computer won’t let me.”

See also Jeff’s worked example: Bean Soup and ACID. The bean soup metaphor is doing exactly the family-resemblance work — ACID is the bacon grease, treated as essential to a category (business systems) when it’s really characteristic of one specific dish (atomic state changes).

The deeper cure is architectural. The failure mode itself is recognizable and partially addressable at smaller scales — a team can prevent specific instances by interrogating their requirements language and giving employees escape valves, without restructuring the whole system at once.