If unhandled_exception is the inverse of expected_failure, it might be more intuitive to track it as unexpected_failure.

Let me give more details about these status:

• expected_failure: the module explicitly declared failure via fail_with. It is an error the module author has anticipated with a proper failure_reason.
• unhandled_exception: a Ruby exception that escaped the module's rescue chain (NoMethodError, Rex::ConnectionError outside a rescue, etc.). The author did not anticipate this; there's an exception_class and backtrace.

So, unhandled_exception and expected_failure aren't strict inverses. For example, unhandled_exception will help answer question like "which modules are buggy?"

I'd suggest adding 'module' as an originator to account for modules running other modules. Additionally since some of these aren't exactly user-interfaces, it may be better to use a slightly more generic name like ORIGINATORS vs ORIGINATING_UIS.

You're right it's not accurate. I would prefer using ORIGINATING_INTERFACES, which is more programmatic. ORIGINATORS sounds like a user, which seems slighly wrong with things like autocheck. I'm also fine if you disagree, I'll change it to ORIGINATORS, no problem.