What AI Model Evidence Can Support in Governance, Compliance and Insurance Reviews

When an AI model contributes to a consequential decision, such as adjusting a process, derating an asset, gating a perception output or supporting a medical device function, other people need to understand the system before it is used. Internal assurance teams, regulators, certification bodies and insurers each ask, in their own terms, a version of the same question: what does the system do, under which conditions, and how is that known?

A prediction alone answers little of that. Reviewers usually need to know what carried an output, whether the model was operating within the conditions it was assessed on, and how its behaviour is controlled over time. When the model cannot state those things, the answers have to be reconstructed from outside it, often at significant engineering cost.

Xpdeep changes what the AI model itself returns. Because the evidence comes from the learned structure rather than from a separate approximation, it describes the model that actually produced the output.

STRUCTURE · What contributed to an output

The model structure that produced the output: which inputs, with what weight and, on temporal data, through which time windows. Returned in the same forward pass as prediction when explanations are retained.

DOMAIN · Whether the model is within what it learned

A graded relation of the current input to the trained domain, with the departure attributed to variables and time windows where the modality supports it.

PRESCRIPTION · How a constrained intervention was derived

Where the modality and application support it (time series and tabular data), a separate inference returns a minimal feasible intervention with its structural justification. There is no image-level prescription.

LIFECYCLE · How model behaviour is examined and updated

Records from the design, production and controlled evolution loops: what was inspected, what was corrected, and how a correction was validated before the model returned to use.

What is available depends on the mode and deployed configuration. Runtime explanation generation may be omitted; the complete decision object is then unavailable, and domain state, prescription and structural justification must be assessed against the capabilities actually retained. Native supports the full three-loop lifecycle, including targeted correction. Retrofit analyses the structure of a frozen PyTorch model; it does not edit, optimize or correct it. See Native vs Retrofit and the Technology page.

Model-level evidence can become one input to the customer's existing processes. In an engineering review, structural explanation can show which inputs carried a class of outputs, and help separate a model issue from a measurement issue. In an assurance case, domain state can support the argument about the conditions under which the model is used, and how departures are handled. In discussions with a regulator, certification body or insurer, lifecycle records can help show how the model was designed, examined and changed.

In each case the evidence informs the discussion; it does not conclude it. The customer decides how the evidence is used, how it is combined with system-level testing and monitoring, and what it is asked to support.

Xpdeep can provide model-level evidence that supports the customer's processes. The customer remains responsible for system-level safety, validation, regulatory compliance, certification and all other required justifications. Xpdeep does not certify the system, guarantee regulatory acceptance or determine whether an insurer will provide cover.

Structural explanation describes what the model used; it does not demonstrate physical causality. An in-domain input is not automatically safe to act on, and an unusual one is not automatically invalid. A prescription is a constrained, justified proposal, not a global optimum and not an authorization to act.

Model evidence does not establish system safety, and it does not by itself satisfy any particular regulatory requirement. Inputs removed during input reduction sit outside the model's domain view and, where safety-relevant, need monitoring at system level. The customer's system rules decide ACT, HOLD or ESCALATE, with people handling exceptions where required.

For the underlying capabilities, read The integrated decision object and Knowing when the model has left what it learned.

A practical assessment of an AI-enabled system can start with these questions:

1. Which decision does the AI model contribute to, and what does the surrounding system do with its output?
2. Which conditions did the evaluation cover, and how does the system respond when domain state indicates a departure from them?
3. Which model-level evidence is retained for each output, and for how long?
4. Who reviews structural explanations, and what would prompt an escalation?
5. If prescription is used, which physical and engineering constraints bound it, and who validates an intervention before operational use?
6. How is a model correction diagnosed, validated and approved before it returns to use?
7. Which system-level checks, monitoring and justifications remain necessary regardless of the model evidence?
8. Is the model trained with Xpdeep (Native) or analysed after training (Retrofit), and what does that mode make available?

The answers will differ by sector and application. The aim is a review that can state what the model evidence shows, what other evidence the system relies on, and what remains to be validated by the customer.