PROCESS

Here is How to Build

Design

Exceptions

Every handling was a bridge

Everything Part 1 built was meant to be temporary. The pre-approved guide, the work-around, the escalation path, none of these was the destination. Each was a bridge, put in place because the case needed a permanent step the designer could not take at once. The permanent step is to fix the case, to negotiate the agreement it turns on, or to implement the change it requires, and any of these takes time. Fixing may need resources allocated that are not yet free. Implementing may need development built that is not yet done. Negotiating may need alignment across stakeholders and partners, or a new contract with a party outside the organisation, and such agreements are slow. The business cannot stop and wait for any of this. So the designer scopes in the handling to bridge that time, to keep the work moving and the business running while the permanent step is worked toward.

This is the honest reason the handling exists. It is not that handling an exception well is the goal; it is that the real fix is slow, and something must carry the business across the gap in the meantime. The bridge does that. It lets the Performer proceed today on a case whose permanent answer will not be ready for weeks or months. But a bridge is built to be crossed and then taken down, not to stand forever. The handling was scoped in with the intention, from the first day, of being made permanent and removed. To leave it standing once the permanent step is possible is to forget why it was built.

And this tells the designer what to watch. An exception that keeps returning is a bridge still standing, a permanent step not yet taken. Recurrence is the signal, both that the rules have a gap where this case should be covered, and that a bridge the designer meant to take down is still carrying traffic. The more a case recurs, the more the bridge is used, and the more it is worth finishing the permanent step and folding the case away. So the designer reads the recurring exceptions not as the handling working but as a list of bridges awaiting their far side, the permanent steps still to be taken, in order of how much each is used.

The highest possible standard is to treat every piece of handling as a bridge, scoped in because the permanent step, to fix, negotiate, or implement, takes time the business cannot wait through, and to hold in mind, from the first day, that the bridge is meant to be crossed and taken down, watching which exceptions recur as the sign of which bridges still await their far side.

Key Takeaway: Everything Part 1 built was meant to be temporary. Each handling, pre-approved guide, work-around, escalation, is a bridge, scoped in because the permanent step takes time: to fix needs resources, to implement needs development built, to negotiate needs alignment or a new contract, and the business cannot wait. The bridge keeps the business running meanwhile. But a bridge is built to be crossed and taken down, not to stand forever. A recurring exception is a bridge still standing, a permanent step not yet taken, and recurrence tells the designer which to finish first.

Every handling is a bridge, scoped in because the permanent fix is slow, and built to be crossed and taken down, not to stand forever.

MarvinPro · PROCESS · Here is How to Build · Design · Exceptions · Discipline 7: Fold It Back · Section: Every handling was a bridge

MarvinPro | June 2026

marvinpro.com

Fold it into the rules

To fold an exception back is to reach the far side of the bridge. When the permanent step finally lands, the resources allocated, the development built, the alignment reached, the contract signed, the case can at last be handled the normal way, and its answer is written into the rules. A rule is changed, or a new one is added, so that the case the rule once did not fit is now a case the rule covers. From that moment the case is no longer an exception. It is ordinary work, met by a rule like any other, and the handling that carried it, the guide, the work-around, the escalation, is retired, because there is nothing left for it to carry.

This is where Exceptions returns to the Rules. The answer folded back is not left as a guide, which would still be handling; it graduates into the ruleset, and it is designed there the way any rule is designed, as a single statement that is five decisions made as one. So the two volumes are a loop. The Rules build the process; the process meets cases its rules do not fit, which are its exceptions; the recurring exceptions are folded back into the Rules; and the process, tightened, meets fewer cases it cannot fit. The designer moves between the two, ruling the recurring, handling the rest, and the design closes its own gaps over time, each folded exception one gap closed for good.

Finding the permanent step is not always simple, and where the cause is buried, it may take real investigation to know what the permanent rule should say. That deeper reading, what a pattern of exceptions reveals about the system beneath it, is the work of another domain, and this discipline does not reach for it. Here the act is the plain one: a case has recurred, its answer is now known, and the designer writes that answer into the rules so the case need never be handled as an exception again. The exception is not merely managed; it is ended, absorbed into the design that should have held it from the start.

The highest possible standard is to fold each recurring exception into the rules once its permanent step has landed, designing the answer as a proper rule by the Rules disciplines, so the case becomes ordinary work and its handling is retired, and the design closes the gap that the exception marked, for good.

Key Takeaway: To fold an exception back is to reach the far side of the bridge: when the permanent step lands, the case's answer is written into the rules, a rule changed or added, so the case the rule once did not fit is now one it covers, and the handling is retired. This is where Exceptions returns to the Rules: the folded answer graduates into the ruleset, designed as a proper rule, and the two volumes form a loop, the design closing its own gaps, one folded exception at a time. Finding the permanent step may take investigation, but that deeper reading belongs to another domain; here the act is plain, a recurring case, its answer known, written into the rules so it is an exception no longer.

Fold the recurring exception into the rules, designed as a proper rule, so the case becomes ordinary work and the gap is closed for good.

MarvinPro · PROCESS · Here is How to Build · Design · Exceptions · Discipline 7: Fold It Back · Section: Fold it into the rules

MarvinPro | June 2026

marvinpro.com

Fold what earns a rule

Not every exception should be folded into a rule, and knowing which should is a judgment with two sides. On one side is the danger of leaving a bridge standing too long. A handling meant to be temporary, if never finished, becomes permanent by neglect, a work-around that quietly turns into the way things are done, carrying its cost unquestioned for years. A recurring exception left handled is a bridge no one took down, and its upkeep, the escalations, the repeated decisions, the guide to maintain, is a tax the design keeps paying. So a case that recurs enough to earn a rule should be folded, and not left indefinitely on a bridge that was only ever meant to be crossed.

On the other side is the opposite danger, and it is easy to miss when the first is fresh in mind. Not every exception recurs enough to earn a rule. A case that arrives once and may never arrive again does not belong in the ruleset; a rule written for the almost-never is clutter, a line every reader must pass and no case will use, and a process thick with such rules is as poorly designed as one thick with exceptions. Folding the genuinely rare into a rule does not tighten the design; it bloats it. That case is better left handled, its rare occurrence met by an escalation or a small guide, and the ruleset kept clean. The aim is not to turn every exception into a rule. It is to have as few exceptions as possible and as few rules as necessary, and the recurring case that earns a rule serves both, while the rare case forced into one serves neither.

So the designer folds by weight. A case that keeps returning has earned its rule and should have it, closing the gap and retiring the bridge. A case that almost never returns keeps its handling, which costs little precisely because it is rarely used. Between them the designer judges, folding what recurs enough to belong in the rules, leaving what is rare enough to belong in a handling, and keeping both the exception load and the rule count as low as the work honestly allows.

The highest possible standard is to fold into the rules every exception that recurs enough to earn one, so no bridge stands past its purpose, while leaving the genuinely rare handled rather than ruled, so the ruleset is not bloated with lines no case will use, keeping both exceptions and rules as few as the work allows.

Key Takeaway: Folding is a two-sided judgment. Leave a bridge standing too long and the temporary handling becomes permanent by neglect, a work-around turned into the way things are done, taxing the design for years, so a case that recurs enough to earn a rule should be folded. But fold the genuinely rare into a rule and you bloat the ruleset with a line no case will use, as poorly designed as a process thick with exceptions. So fold by weight: the recurring case earns its rule and closes its gap; the rare case keeps its cheap handling. The aim is as few exceptions as possible and as few rules as necessary.

Fold what recurs enough to earn a rule, and leave the genuinely rare handled, so both exceptions and rules stay as few as the work allows.

MarvinPro · PROCESS · Here is How to Build · Design · Exceptions · Discipline 7: Fold It Back · Section: Fold what earns a rule

MarvinPro | June 2026

marvinpro.com

A real example

Return to the software company, where the fold-back was built into the process from the start. The unknown issue was handled by a bridge: the escalation path carried it to those who could work it, and shaped updates held the customer meanwhile. That handling bought the time the permanent step needed, for the Technical Team to understand the trouble, and, where it lay in a supplier's software, for a fix to be negotiated and built with the vendor. None of that was fast. But once the step landed and the trouble was understood, its answer was folded back: the Owner turned the resolution into troubleshooting the Performer could follow and templates the customer would receive, and where the trouble was one that would keep arriving, its handling was written into the rules. The unknown became known, the bridge came down, and the next Performer to meet that trouble met not an exception but a case the rules now covered.

The opted-out customer folded the same way. Its handling began as a small pre-approved guide, a bridge, and as it became clear that such customers arrived often and the answer never varied, it was folded into the rules themselves: not messaging an opted-out customer became simply how the process worked, no guide to look up, no exception at all. A case that needed a partner's agreement took longer, its handling carrying the business across cycles until the alignment was reached, and then it too was folded. Each of these had recurred enough to earn its rule, and each, once folded, closed a gap for good.

But not everything was folded. A one-time request from a single customer, odd and unlikely to return, was left handled, met by an escalation on the rare occasion it recurred, and never written into the rules, because a rule for a case that almost never happens would have been a line every Performer read and none would use. So the design tightened where tightening helped and stayed clean where it did not: the recurring exceptions graduated into rules, the rare ones kept their light handling, and month by month the process met more of its cases with a rule that fit and fewer with a bridge that had to be built. That is the fold-back doing its work, the design, over time, closing the gaps its own exceptions revealed.

The recurring exceptions were folded into rules and their bridges taken down; the rare ones kept their handling; and the design closed its own gaps over time.

MarvinPro · PROCESS · Here is How to Build · Design · Exceptions · Discipline 7: Fold It Back · A real example

MarvinPro | June 2026

marvinpro.com

Fold It Back

Everything Part 1 built was meant to be temporary. The pre-approved guide, the work-around, the escalation path, each was a bridge, scoped in because the case needed a permanent step the designer could not take at once. The permanent step is to fix the case, negotiate the agreement it turns on, or implement the change it requires, and any of these takes time: resources to allocate, development to build, alignment across stakeholders and partners, or a new contract with an outside party. The business cannot wait through that, so the handling bridges the time, keeping the work moving while the permanent step is built. But a bridge is meant to be crossed and taken down. A recurring exception is a bridge still standing, and its recurrence is the signal, that the rules have a gap, and that a permanent step is still owed.

To fold the exception back is to reach the far side. When the permanent step lands, the case's answer is written into the rules, a rule changed or a new one added, so the case the rule once did not fit is now one it covers. From that moment the case is ordinary work, and the handling that carried it is retired. This is where Exceptions returns to the Rules: the answer graduates into the ruleset and is designed there as a proper rule, five decisions made as one. So the two volumes are a loop, the rules build the process, the process meets its exceptions, the recurring ones fold back into the rules, and the design closes its own gaps, one folded exception at a time.

But folding is a two-sided judgment. Leave a bridge standing too long and the temporary handling becomes permanent by neglect, a work-around that turns into the way things are done and taxes the design for years, so a case that recurs enough to earn a rule should be folded. Fold the genuinely rare into a rule, though, and the ruleset bloats with a line no case will use, as poorly made as a process thick with exceptions. So the designer folds by weight: the recurring case earns its rule and closes its gap; the rare case keeps its cheap handling. The aim is as few exceptions as possible and as few rules as necessary.

So the discipline is this: remember that every handling was a bridge, scoped in because the permanent step was slow, and meant to be crossed and taken down. Watch which exceptions recur, and finish the permanent steps they mark, in order of how much each bridge is used. Fold each recurring case into the rules once its step has landed, designing it as a proper rule, so the case becomes ordinary and the bridge comes down. Leave the genuinely rare handled, so the ruleset stays clean. Where the permanent answer is buried, investigation may be needed to find it, and the deeper reading of what exceptions reveal belongs to another domain, but the act here is plain: end the recurring exception by folding it into the design that should have held it, until the process meets almost every case with a rule that fits, and needs almost no bridges at all.

Fold each recurring exception into the rules once its permanent step lands, so the bridge comes down and the design, over time, needs almost no bridges at all.

MarvinPro · PROCESS · Here is How to Build · Design · Exceptions · Discipline 7: Fold It Back · Chapter Outcome

MarvinPro | June 2026

marvinpro.com

Think Simple.