PROCESS

Here is How to Build

Design

Rules

The case the rule does not fit

A rule is how a requirement is met in the normal case. The Rules took a single rule and showed it whole, five decisions designed as one, sound when they agree. But a rule is built for the normal case, and not every case is normal. Sooner or later a case arrives that the rule does not fit, and the Performer who meets it cannot proceed by the rule, because for this case the rule has nothing to say. That case is an exception, and this volume is about it: how it is found, how the Performer is carried through it, and how, in time, it is made to vanish.

Begin with what the exception is not. It is not a broken rule, nor a rule poorly made. A sound rule, designed with every care, still meets cases it was not built for, because no rule can foresee every shape the work will take. The exception is not a failure of the rule; it is the edge of it, the place where the normal case ends and something the rule did not anticipate begins. So the existence of exceptions is not a sign of bad design. Every design has edges. What separates good design from poor is not whether exceptions exist, but whether the Performer who meets one is left stranded or carried through, and whether the exception is allowed to recur forever or is designed away.

The Performer is at the centre of this, and it is worth being plain about why. When a case the rule does not fit reaches the Performer, they are stuck in a particular way: the work cannot go on, and nothing tells them what to do. They can guess, and risk doing harm. They can go silent, and leave the customer in the dark. Or they can reach for a way forward that the design prepared in advance. The whole of this volume is the designer's effort to make sure that third path always exists, that whenever the rule falls silent, the design does not. An exception is, first and last, a moment when a person needs to know what to do, and the design must already have answered.

The highest possible standard is to treat every exception as a case the rule does not fit and a person who needs a way through, neither a flaw to be ashamed of nor a rarity to be ignored, but an edge of the design to be foreseen, handled, and in time removed.

Key Takeaway: A rule is built for the normal case, and not every case is normal; the case the rule does not fit is an exception, where the Performer cannot proceed because the rule has nothing to say. An exception is not a broken rule but the edge of one, the place the normal case ends; every design has edges, and what separates good from poor is not whether exceptions exist but whether the Performer is stranded or carried through, and whether the exception recurs forever or is designed away. At its centre an exception is a person who needs to know what to do, and the design must already have answered.

An exception is a case the rule does not fit, and a Performer who needs a way through where the rule has fallen silent.

MarvinPro · PROCESS · Here is How to Build · Design · Exceptions · Discipline 1: An Exception · Section: The case the rule does not fit

MarvinPro | June 2026

marvinpro.com

What the world calls an exception, and what it is

Ask what an exception is, and most answers come from the world of systems. There, an exception is a fault, an error thrown when a program meets a state it cannot handle, caught and managed by machinery built for the purpose. The word carries that weight: something has gone wrong, an alarm has sounded, a handler must catch it. This is a true sense of the word, and it is not the sense this book means. The exception here is not an error in a machine. It is a case in the work that the rule did not anticipate, met by a person, not a program.

So set the machine sense aside and take the plainer one. An exception is a designed response to a defined condition under which the normal rule does not apply, a case where the rule is intentionally set aside, met another way, or carried to someone who can decide. The condition is what marks the case as exceptional, this is not the normal case, the rule does not fit here. The response is what the design does about it. And underneath, in most exceptions, the requirement still stands. The customer must still be informed, the record must still be right; it is only that the normal rule for meeting the requirement does not fit this case, so the requirement is met another way. Now and then a requirement is deliberately set aside for a defined case, the customer who asked not to be contacted is, correctly, not contacted, but far more often the requirement survives and the exception is simply a different road to the same end.

This is why an exception is designed, not improvised. The world's machine catches an error after it is thrown; the designer, by contrast, foresees the case before it arrives and builds the response in advance. An exception, in this book, is not a thing that happens to you. It is a thing you design, a prepared answer to a case you knew might come, so that when it does, the Performer is not left to invent a response in the moment. The difference between an exception caught and an exception designed is the difference between a process that copes and a process that was built to hold.

The highest possible standard is to mean by exception not a machine's error caught after the fact, but a designed response to a foreseen case the rule does not fit, prepared in advance so the requirement is still met and the Performer is never left to improvise.

Key Takeaway: The common sense of exception comes from systems, a fault thrown and caught by machinery; this book means something else, a case in the work the rule did not anticipate, met by a person. An exception is a designed response to a defined condition under which the normal rule does not apply: the condition marks the case as not normal, the response is what the design does, and underneath the requirement usually still stands and is met another way, though now and then it is deliberately set aside. The exception is designed in advance, not improvised in the moment, the difference between a process that copes and one built to hold.

An exception is not a machine's error caught after the fact, but a designed response to a foreseen case the rule does not fit.

MarvinPro · PROCESS · Here is How to Build · Design · Exceptions · Discipline 1: An Exception · Section: What the world calls an exception, and what it is

MarvinPro | June 2026

marvinpro.com

As few as possible

There is a temptation, having learned to handle exceptions well, to be proud of how many you can handle. Resist it. The measure of a design is not how richly it handles exceptions but how few it has. Every exception is a place the rules did not reach, a case the normal design failed to cover. Handling it well is necessary, the Performer must be carried through, but handling is a repair, not a triumph. A process heavy with exceptions is a process whose rules are incomplete, however gracefully each exception is managed.

So this volume holds two aims at once, and the second governs the first. The first aim is to handle: when an exception arrives, give the Performer a sanctioned way forward, never stranded. The second aim is to remove: design the exception away, so that over time the work needs fewer and fewer of them. These are not in tension; they are a sequence. You handle the exception today because it is here and the Performer needs a way through. You remove it tomorrow by folding the recurring case back into the rules, so it stops being an exception at all. A good designer does both, and never mistakes the first for the whole job. To handle an exception and leave it standing forever is to manage a leak instead of mending it.

This is the thread that runs through every discipline that follows. When you surface an exception, you are finding a gap in the rules. When you give the Performer a way forward, you are handling that gap with care. And when you fold the recurring case back into the rules, you are closing the gap, so the exception is needed no more. The aim, held steadily from the first what-if to the last fold, is a design with as few exceptions as possible, where almost every case the work meets is, once more, a case the rules already fit.

The highest possible standard is to hold, through all of the work that follows, that handling an exception well is necessary but never the goal, and that the goal is always a design with as few exceptions as possible, every recurring one folded back into the rules.

Key Takeaway: The measure of a design is not how richly it handles exceptions but how few it has; every exception is a place the rules did not reach, and handling it is a repair, not a triumph. The volume holds two aims, and the second governs the first: handle the exception today, because the Performer needs a way through, and remove it tomorrow, by folding the recurring case back into the rules so it stops being an exception. To handle an exception and leave it standing forever is to manage a leak instead of mending it.

Handling an exception well is necessary but never the goal; the goal is a design with as few exceptions as possible.

MarvinPro · PROCESS · Here is How to Build · Design · Exceptions · Discipline 1: An Exception · Section: As few as possible

MarvinPro | June 2026

marvinpro.com

A real example

Return to the software company, through the exception lens. Most of what the Performer meets is a known issue: trouble the company has seen before, with a template ready and a way forward written. The rule fits, and the Performer proceeds. This is the normal case, and most cases are normal, which is the design working as it should.

The exception is the unknown issue, the trouble with no template, because no one yet understands it well enough to write one. Here the rule does not fit. The Performer faces a customer in trouble and has nothing written to send, no instruction to follow. They cannot proceed by the rule, because for this case there is no rule. And this is not a broken rule or a careless one; it is the edge of a sound design, the place where the known ends and something new begins. No set of templates, however complete, could have foreseen every trouble the software might one day produce. The unknown issue is the design's edge, and meeting it is not a failure but an inevitability.

What separates this design from a poor one is what happens next. The Performer is not left to invent a reply or to fall silent. A way forward was built in advance, the escalation path, carrying the case to those who can work it, with shaped updates to keep the customer informed meanwhile. And the exception does not last: once the trouble is understood and resolved, it is turned into troubleshooting and templates, and the unknown becomes known, folded back into the rules so the next Performer simply proceeds. The exception is handled today and removed tomorrow. That is the whole of this volume, seen in one case: a Performer carried through the edge of the design, and the edge itself, in time, designed away.

An exception is the edge of a sound design, a case the rule does not yet fit, met with a way forward today and folded into the rules tomorrow.

MarvinPro · PROCESS · Here is How to Build · Design · Exceptions · Discipline 1: An Exception · A real example

MarvinPro | June 2026

marvinpro.com

An Exception

A rule is how a requirement is met in the normal case, but not every case is normal. The case the rule does not fit is an exception, and the Performer who meets it cannot proceed by the rule, because for this case the rule has nothing to say. An exception is not a broken rule or a careless one; it is the edge of a sound design, the place where the normal case ends and something the rule did not anticipate begins. Every design has edges, so the existence of exceptions is no shame. What separates good design from poor is whether the Performer who meets one is carried through or left stranded, and whether the exception is allowed to recur forever or is designed away.

The world's common sense of the word comes from systems, a fault thrown and caught by machinery. This book means something else: a case in the work that the rule did not anticipate, met by a person. An exception, here, is a designed response to a defined condition under which the normal rule does not apply, the rule intentionally set aside, met another way, or carried to someone who can decide. The condition marks the case as not normal; the response is what the design does about it; and underneath, in most exceptions, the requirement still stands and is simply met another way, though now and then it is deliberately set aside. The exception is designed in advance, not improvised in the moment, a prepared answer to a case you knew might come.

And the goal, held from the first discipline to the last, is to need as few of them as possible. The measure of a design is not how richly it handles exceptions but how few it has, for every exception is a place the rules did not reach. So the volume holds two aims, the second governing the first: handle the exception today, so the Performer is never stranded, and remove it tomorrow, by folding the recurring case back into the rules until it is an exception no longer. To handle an exception and leave it standing forever is to manage a leak instead of mending it.

This is what the disciplines that follow will build. You will surface exceptions by asking the Performers their what-ifs, well before the work goes live. You will triage them, scoping in what you can and honestly parking the rest. You will give the Performer a way forward, written where it can be and escalated where it must be. And you will fold the recurring ones back into the rules, until the work, once more, meets almost every case with a rule that fits. An exception is a case the rule does not fit and a person who needs a way through; the designer's task is to see that the way through is always there, and that the exception, in the end, is not.

An exception is a case the rule does not fit and a Performer who needs a way through; the design must answer where the rule fell silent, and then close the gap so it falls silent no more.

MarvinPro · PROCESS · Here is How to Build · Design · Exceptions · Discipline 1: An Exception · Chapter Outcome

MarvinPro | June 2026

marvinpro.com

Think Simple.