PA027

Greater Automation Resilience to Exceptions vs. Simpler Bot Logic

Business Context. Building automation to handle every conceivable exception makes the bot more resilient, but the resulting logic becomes so complex that it is difficult to understand, test, and maintain.

Process TRIZ Resolution. Rather than embedding every exception case into the bot's core logic, organizations should keep the bot's primary logic simple and route unhandled exceptions to a flexible fallback mechanism that can absorb new exception types without requiring core logic changes.

Applicable TRIZ Principles

Principle 1 (Segmentation) separates simple core logic from a flexible fallback mechanism for exceptions.

Principle 2 (Taking Out) removes rare exception handling from the bot's core logic entirely.

Principle 24 (Intermediary) uses a fallback layer to absorb new exception types without modifying core logic.

Expected Outcome

Resilience to a wide range of exceptions

Simple, maintainable core logic

Faster bot testing and updates

Reduced logic-related defects

Decision Indicators

Bot logic has grown too complex for engineers to confidently modify.

Every new exception type requires changing the bot's core code.

Testing the bot takes disproportionately long due to logic complexity.

Defects increase each time a new exception rule is added.

No fallback mechanism exists for unanticipated exception types.

If several of these indicators are present, the contradiction is likely active and the Process TRIZ resolution above should be evaluated.