The Different Types of Explanations in Hybrid Intelligence

One prediction, several legitimate questions

Suppose a model declines an application. A developer may ask how the score was calculated. The applicant may ask why the decision occurred. A case manager may ask what would need to change. A reviewer may ask why the expected approval did not happen. Each question requires a different analytical operation.

Hybrid Intelligence organises these needs into seven explanation types. Each type can draw on the model-native record produced by an Explainable Neural Network (XNN).

1. How explanations

A how explanation describes the internal path used to construct the output. It can include feature transformations, active modules, partition conditions, rule expressions, attributions and the final output function.

Use it when the question is computational: "How did these inputs become this score?"

2. Why explanations

A why explanation identifies the factors responsible for the observed result. In an XNN, those factors include signed attributions and active rules. Where an explicit causal model is present, the explanation can also follow the causal relationships represented there.

Attribution alone should not be described as proof of real-world causation. The explanation must distinguish model contribution from causal knowledge supplied or validated separately.

3. Why-not explanations

A why-not explanation compares the actual path with an expected alternative. It identifies conditions that were absent, contradictory or associated with a different rule branch.

For example, high income may have supported approval, but insufficient history may have activated a different partition. The explanation focuses on why the expected outcome did not follow.

4. What-if explanations

A what-if explanation changes one or more inputs and reruns the same model logic. It shows the resulting prediction, active rules and attribution differences.

This is useful for sensitivity analysis and scenario testing. The user specifies the change; the model reports its consequences.

5. How-to explanations

A how-to explanation begins with a desired outcome and searches for a feasible change that could produce it. It is a counterfactual question: "What is the smallest permitted change that reaches the target?"

Constraints matter. Some fields are immutable, some changes are implausible and some recommendations may be prohibited. The counterfactual search should operate within explicit domain and policy boundaries.

6. What-else explanations

A what-else explanation uses examples or groups for comparison. The reference may be the nearest similar query, an adjacent case within the same partition, a proximate case in another partition or a user-selected example.

Comparisons can be single-to-single, single-to-group or group-to-group. Their value depends on making both similarity and difference explicit.

7. Assistance explanations

An assistance explanation connects a result to a process or workflow. It may show the next permitted step, required evidence or available review path. This layer should be separated from the predictive model so that the user can distinguish what the XNN predicted from what the operational procedure recommends.

Analytical methods used across the types

Comparative analysis places the current result beside another query, a group or an alternative path.

Contrastive feature relevance identifies which differences matter most between the compared outcomes.

Control swaps change one feature, a minimal feature set or a structural condition while holding other inputs constant. Like a controlled experiment within the model, the swap isolates how the prediction changes under the specified modification.

These methods can be combined. A why-not explanation may compare the current case with a similar approved case and then perform a control swap on the feature that differs.

Choosing the right explanation

Start with the verb in the user's question:

• "How" calls for an execution trace.
• "Why" calls for contributing factors and supported dependencies.
• "Why not" calls for contrast with an expected path.
• "What if" calls for a user-specified scenario.
• "How can" calls for a constrained counterfactual.
• "What else is similar" calls for examples.
• "What happens next" calls for process assistance.

The Explanation Structure Model (ESM) can then select the relevant underlying objects and present them at the appropriate detail level.

Why it matters

Explanation quality depends on answering the right question. A taxonomy of explanation types prevents feature importance from being treated as a universal answer and helps product teams design interfaces that support understanding, challenge and action.