The first objection to “everything the system permits has to be acceptable” is that what a system permits is infinite. Retries, reorderings, half-finished states, combinations nobody designed.
It is infinite. Nobody should try to audit it.
Paths are the wrong unit. A multi-step flow with a few optional branches and a retry at each step already has more distinct routes than anyone will ever walk, and each route you do walk tells you about that route and nothing else.
Now look at where the routes end. A transactional flow terminates in an outcome: an order exists or it doesn’t, money moved or it didn’t, a record sits in some state. That set is small. A few dozen at most, often under ten.
→ Order placed, paid in full.
→ Order placed, payment pending, customer told.
→ Nothing happened, customer told why.
So you don’t declare the routes. You declare the codomain: the outcomes the company is willing to stand behind. Every route, including the ones nobody has imagined, gets classified at its end instead of along its length. It lands inside the set or it doesn’t.
That turns an exploratory task into a declarative one. Exploration needs people with time and imagination, and it never finishes. Declaration needs one person with the authority to say “we’d sign that”, and it fits on a page.
It also changes what a surprising path means. A route you never thought of that ends in a declared outcome is fine, and you never needed to know it existed. One that ends outside the set is a finding no test written around the happy path could have produced.
The expensive part isn’t technical. Someone has to decide what the company stands behind, and that is a business decision, not an engineering one. In most teams the first discovery is that nobody has ever been asked.
Next time someone says this can’t be done because the space is infinite, ask for the outcomes, not the paths. If the acceptable ones can’t be written on a single page, the problem sits upstream of the system.
Paths are infinite. Acceptable outcomes fit on one page.