Auditing XNN Outputs

Audit begins with a defined question

An audit may ask whether a recorded result has changed, whether the expected model version was used, whether the explanation reconciles with the prediction, whether a sensitive feature was influential or whether a downstream decision followed policy.

These are different questions. The audit record should contain enough structured evidence to answer them without treating one check as proof of everything.

The core query record

A useful record can include:

• input data or a governed reference;
• contextual information supplied with the query;
• prediction values and selected class;
• threshold or decision configuration;
• background value and module attributions;
• decomposed interaction contributions;
• active modules, partitions and rules;
• activation path;
• model, Explanation Structure Model (ESM) and dataset references;
• time and environment information; and
• downstream policy, override or human action.

The exact contents depend on the use case and privacy design. The principle is to preserve the line between input, model execution, explanation and operational action.

Reconstructing the prediction

For regression, the background value and raw module attributions should reproduce the prediction within the stated rounding policy.

For classification, the audit should reconstruct the pre-activation score, apply the correct sigmoid or softmax and confirm the decision threshold or selected class.

This verifies internal consistency. It does not establish that the input was accurate or that the model should have been used for the decision.

Inspecting the rule path

The rule view identifies the active partition in each module. The reviewer can check:

• whether the input met the IF conditions;
• whether the correct transformed values were used;
• whether the THEN expression produced the reported attribution;
• whether the rule belongs to the recorded model version; and
• whether neighbouring or rare partitions indicate an edge case.

Stable identifiers make it possible to compare the same component across queries and versions.

For batch or portfolio audits, aggregate the same fields across a defined population. This can reveal rules with unusual coverage, modules that dominate one subgroup, recurrent reconciliation failures or clusters of cases sent to manual override. Any aggregate finding should remain linked to the individual records from which it was calculated.

Reviewing contribution and sensitivity

Attributions show which modules and features drove the result. A reviewer can examine direct and interaction contributions, rollups, normalisation scope and activation frequency.

For sensitive or disputed factors, a controlled what-if-not query can test how the model output changes when the factor is replaced or masked under the permitted audit protocol. The original and comparison records should remain linked but distinct.

Integrity verification

A Query Unique Verification Code (UVC) can be calculated over selected inputs, predictions, explanation metadata, active-component references, time information and the Model UVC. Recomputing the hash and comparing it with the stored reference provides a tamper-evident integrity check.

A match supports the conclusion that the checked components are unchanged relative to the reference. A mismatch indicates a discrepancy that requires diagnosis; possible causes include data change, corruption, a different model, altered metadata or implementation inconsistency.

Audit independence

The Hybrid Intelligence framework allows the UVC algorithm to be implemented outside the runtime library, provided the same canonical data representation, ordering and hash procedure are used. This can support independent verification.

The canonicalisation specification is critical. Equivalent data encoded differently can produce different hashes. A production audit design therefore needs explicit field definitions, serialisation, ordering, time format, algorithm version and key-handling decisions where applicable.

From evidence to conclusion

An audit conclusion should state its scope:

• integrity check passed;
• prediction reconstruction passed;
• model-version check passed;
• explanation lineage reviewed;
• policy compliance assessed; or
• fairness analysis completed.

These conclusions build on each other but are not interchangeable.

Key technical concepts explained

• Prediction reconstruction: reproducing the output from the recorded background, attributions and output function.
• Canonicalisation: converting data into a stable representation before hashing.
• Audit scope: the specific question and evidence covered by a review.
• Query lineage: the links among input, execution, explanation and downstream action.
• Independent verification: recomputing an integrity reference outside the originating runtime.

Simplified scenario

A disputed credit decision is reviewed six months later. The auditor resolves the deployed model and ESM, recomputes the prediction from the retained contributions, checks the active rules, confirms the decision threshold and validates the Query UVC. The integrity and reconstruction checks pass. A separate review then evaluates whether the policy threshold and data use were appropriate.

Why it matters

Structured output auditing replaces a vague request to "explain the AI" with testable checks. It helps organisations distinguish computational integrity, model behaviour and operational governance.

It also creates a repeatable review method: the same evidence fields and scoped conclusions can be applied across cases, model versions and independent assurance exercises.