Not Every Problem Is a Process

Some problems are decisions. They take inputs and produce an outcome. Given the same inputs, the result should always be the same. There is no progression over time, no intermediate state, and no need to model transitions.

When these problems are treated as workflows, complexity is introduced unnecessarily. State has to be stored and managed. Failures now have to account for partial progress. Retries become harder because the system must resume rather than re-evaluate.

This usually does not happen because of intent. It happens because the problem was not clearly defined. When there is uncertainty, engineers reach for tools that feel expressive. Workflows and state machines create the impression of handling complexity even when the underlying problem is simple.

The cost shows up later. Logic becomes harder to follow. Changes require touching multiple parts of the system. What should have been obvious becomes something that requires tracing through steps to understand.

If the outcome can be determined entirely from the inputs, it is not a process. It is a decision.