Three loops only the model can close

Native structural explainability is the foundational technology; these three technical loops are its first product architecture. Each loop needs something only the AI model can provide: its learned structure. Conventional workflows often require another training cycle when model behaviour needs to change. Reading the structure lets engineers work on the part of the model that matters.

These loops operate on the model. Requirements, system rules, verification, qualification and system-level authority stay with the customer's wider lifecycle. The Three Loops section on the Technology page gives the full overview.

Engineers read the structure the model has learned, locate the area where it behaves poorly and make a targeted local edit while the rest of the model stays frozen. This is a Native capability; Retrofit reads a frozen model but does not edit it.

The work starts with a defined problem in model behaviour. An aggregate score may identify that there is a problem without showing where it sits. Structural analysis lets the team examine the learned structure associated with the output, then decide whether a local change is relevant. Reading precedes editing: a visible dependency is something to investigate, not an instruction to change it.

In Native mode, the explanation is learned with the prediction. Engineers can use that structure to diagnose a problem area and target an edit while leaving the rest frozen. On time-series data, accuracy is at least equivalent to standard deep learning and frequently superior.

Up to 4× faster model development. Source: Client evaluation. Up to 82% fewer input variables; 105 reduced to 19 at equal or better accuracy. Source: Independent programme evaluation. These figures come from different programmes.

Assessment still follows the edit. Check the behaviour that motivated the change and the behaviour the application needs to preserve, using the customer's tools and constraints. A localized correction may make the scope of model changes easier to identify. Whether this reduces customer revalidation or requalification effort remains application-specific and has not yet been established. Requalification is not eliminated.

Retrofit can support inspection of an existing frozen PyTorch model, provided architecture and weights are available. That can inform diagnosis, but it does not close the editing step. To choose between the two modes, read Native vs Retrofit.

Primary inference returns prediction with explanation and attributed domain state where retained and configured; prediction and explanation share a forward pass when retained. Runtime explanation generation may be omitted for application needs or frugality, so the full decision object is not universal. A separate optional prescriptive inference adds a minimal feasible intervention, with structural justification where supported and retained. The full output is described in The integrated decision object.

The engineer's question changes in production: not just whether a model is accurate overall, but what information accompanies this output. Structural explanation concerns the learned structure carrying it. Attributed domain state concerns the input's relation to what was learned. These are distinct pieces of evidence, not interchangeable measures of confidence.

The sequence is model output, assessment under customer rules, then the customer's system response. Those rules determine ACT, HOLD or ESCALATE. A model-level loop does not mean the model owns the system's authority. People handle exceptions where the customer requires them; Xpdeep supplies the model-level information used in that arrangement.

Prescription is conditional, not an obligatory extra step for every output. On supported time-series and tabular uses, a separate inference can provide a minimal feasible intervention under stated constraints with structural justification. It is not a causal conclusion or a global optimum. For image and video, the scope is structural explanation, attributed domain state and design-loop capabilities; there is no image-level prescription.

To assess this loop, ask whether the surrounding system has defined how it will use each output and what it will do when the conditions for action are not met. The availability of a richer model output does not itself settle those rules or prove the application's performance and economics.

Operational evidence is used to diagnose the structure, make a targeted correction, validate it under the customer's constraints and redeploy between operating periods.

This loop starts when evidence from use gives the team a reason to examine behaviour. The first task is diagnosis: which part of the learned structure is implicated, and what problem is the proposed correction intended to address? Operational feedback is evidence for an engineering review, not an automatic command to update the model.

Native supports the targeted correction. The rest of the model remains frozen during the local edit, and the correction is then validated before redeployment. Engineers must decide whether the evidence supports the intended change and whether the corrected model meets the application's constraints. Retrofit can read a frozen model structurally but cannot correct it.

Controlled evolution is not continuous or online learning. The model does not change itself in operation.

The practical review separates three questions: what was observed, what model change is justified, and what evidence is required before the change can be used. Keeping those questions separate makes the correction a controlled engineering decision between operating periods. The customer's wider lifecycle still owns requirements, system integration, verification, qualification and authority.