A FAULT is the target REFUSING. An ERROR is the flow BREAKING. The distinction decides where your handler goes.
A fault comes back from something you called: the service returned an error, the target rejected the record, the adapter reported a problem with the request. It is a response, and it is CATCHABLE — you can wrap the invoke, catch the fault, read what it said, and decide.
An error is your flow failing: a null in an expression, a variable read before assignment, a payload too large, a mapping that could not produce valid output. Some of these the platform catches and some end the instance where it stands.
WHY THE DISTINCTION DECIDES WHERE THE HANDLER GOES. A fault handler wrapped around one invoke catches that target's refusals and knows exactly which call failed and why. A handler at the top of the flow catches everything and knows almost nothing — by the time the failure reaches it, the context that would tell you which record and which step is gone.
So: wrap the invokes, handle the faults where they happen, and keep a top-level handler as a backstop rather than as the design. Lesson 3.
AND THE PRACTICAL CONSEQUENCE FOR ERRORS: prevent rather than catch. A null guard before an expression, an initialised variable, a bounded payload — those remove a whole class of failure that no handler can usefully report on. An error caught at the top of a flow gives you a stack, not a diagnosis, and that is why the mapping module spends a lesson on null.