How to Query XNNs and Receive Explanations

Before the first query

An XNN is created through the Hybrid Intelligence induction process and packaged within, or connected to, an Explanation Structure Model (ESM). The ESM provides the preprocessing pipeline, symbolic relationships and metadata needed to interpret the model correctly.

Before querying, a system should resolve the intended ESM and model version, validate the input schema and establish the explanation mode required by the application. A customer-facing decision may need a concise local explanation, while a validation workflow may request detailed rules and module data.

Step 1: submit a single row or batch

The query input can be one record or a batch. A single query supports immediate decisioning and case-level explanation. A batch supports analysis across a population, comparison of activation patterns and construction of global views.

Inputs should use the external schema expected by the ESM. The explainable preprocessing pipeline performs the same transformations defined during induction, including categorical encoding, time decomposition or vector encoding where applicable.

Step 2: choose the execution mode

The framework distinguishes live inference from a data-interface mode. Live inference executes the XNN for an immediate result. A data interface can retrieve cached or precomputed results for analytical workloads.

Whichever mode is used, the response should identify whether the result was newly calculated or retrieved and should retain the relevant model and data references.

Step 3: run the XNN

For each module, the query follows the same sequence:

1. Select the transformed values relevant to the module.
2. Evaluate the partition conditions.
3. Activate one non-overlapping partition.
4. Execute the active rule's THEN expression.
5. Return the module attribution.

The module attributions are combined with the background value and passed through the task-specific output function. The result may be a regression value, a binary score and class, or a vector of multi-class outputs.

Step 4: assemble the Query Result

A useful Query Result can contain three layers.

Core result

• submitted input or secure reference to it;
• contextual information supplied with the query;
• prediction values and selected class or threshold result.

Attribution and reasoning

• module and feature attributions;
• decomposed interaction contributions;
• active partitions and rules;
• activation path;
• activation and impactful-activation information.

Audit and verification

• model and dataset references;
• time and environment metadata;
• row or output hashes;
• Query Unique Verification Code (UVC) where configured.

Not every user should receive every field. Access control and data minimisation should be applied without breaking the retained lineage.

Step 5: render the right view

A local feature-attribution view answers which original inputs mattered for one case. A module-attribution view preserves interactions and shows how each module contributed. A rule view exposes the IF conditions and THEN expressions. A dependency view follows the linked reasoning structure and can support root-cause investigation.

Context-aware explainers can also run comparisons, control swaps, what-if scenarios and constrained counterfactuals. Global explainers aggregate behaviour across many queries.

Step 6: validate and record

Applications should check that the response uses the expected model version and output schema. For high-impact decisions, the prediction should be reconcilable with the displayed background and attributions. The system should also record whether any post-model policy, override or human action changed the operational outcome.

The Query UVC can support later integrity checking of selected query components. Store the inputs used to calculate the code, or secure references that allow authorised recomputation, according to the organisation's audit and privacy design.

Prediction, explanation and decision

These three terms should remain distinct. The prediction is the model output. The explanation describes its computation and relevant context. The final decision may additionally apply policy rules, evidence requirements, human review or downstream optimisation.

Maintaining that separation makes it possible to answer whether the model produced an output correctly, whether the explanation accurately described it and whether the organisation acted appropriately.

Why it matters

A well-designed query contract makes explainability operational. It defines which model was used, how the input was transformed, what the output means, which explanation views are available and what evidence is retained for later challenge.