Three loops only the model can close

Each loop needs something only the learned model can provide: its own 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.

Across selected validated results from Confiance.AI and client programmes, the Design loop has delivered up to 4× faster model development. In one selected validated result, input variables were reduced from 105 to 19 at equal or better accuracy. 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. Because the change is local, the requalification perimeter can be more bounded; how this affects requalification in practice is still being established with customers. 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.

Prediction and structural explanation come from the same forward pass, together with an attributed domain state. When useful and supported, a separate, constrained prescriptive inference adds a minimal feasible intervention with its structural justification. 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.