Native vs Retrofit

Both modes return the decision object in production. The difference is what you can do with the model afterwards. Native is Xpdeep's recommended path for deployments that need all three loops. Retrofit is an entry point for structurally inspecting an existing frozen PyTorch model; its usual next step is Native when editing or controlled correction is required. For the comparison with post-hoc methods, read Post-hoc explanation vs structural model control.

Retrofit structurally analyses an existing PyTorch model that stays frozen. It requires read access to the architecture and weights; input/output-only analysis is not offered. It is the relevant mode when a validated model exists and the first question is what it has learned and how it behaves.

Retrofit does not edit, optimize or correct the frozen model. It adds a small compute and memory overhead, measured on the target.

Start by identifying what must remain fixed. A team with an existing, validated model may want to understand its learned structure without reopening model development. Retrofit is relevant to that inspection need. It preserves the frozen model distinction: opening the structure does not mean changing the architecture or weights to improve a particular behaviour.

The access requirement is an early selection criterion. The team needs read access to the PyTorch architecture and weights; access only to inputs and outputs is not enough, and input/output-only analysis is not offered. Resolve that requirement before planning an evaluation. It is a prerequisite for structural analysis, not an optional integration detail.

Next, distinguish an investigation from a modification. If the question is what the model learned, how its structure carries an output or how an input relates to its learned domain, Retrofit can be an entry point. If the question becomes how to edit that structure, optimize the model or perform controlled correction, Retrofit is no longer the mode that supplies those capabilities.

A previously validated model also remains part of a customer system. Its prior status does not establish the acceptability of every new use of its decision object. The customer assesses the output within its existing rules and processes; Retrofit does not replace that assessment.

Native learns the explanation together with the prediction. That makes structural editing, optimization and controlled evolution possible on one model. It is the relevant mode when a model is being built or rebuilt, or when targeted correction over time matters.

Native adds no extra compute or latency for the explanation; the memory footprint of its explanation layer must be budgeted.

A new or rebuilt model gives the team the opportunity to learn structural explanation together with prediction. Native is therefore relevant when development needs include reading and changing learned structure, rather than only inspecting a model that must stay frozen. It supports targeted structural editing and optimization, as well as validated correction between operating periods.

Think beyond the first inspection. A team may need to diagnose behaviour today and correct it later. If targeted correction is part of the intended work, plan for Native when choosing the mode. Native needs training data and target metrics, as for developing a standard PyTorch model for the same task.

Supplier-owned models are handled with the supplier's cooperation and access to its PyTorch model. An OEM does not structurally modify a supplier's model around the supplier.

On time-series data, accuracy is at least equivalent to standard deep learning and frequently superior. Native models are frequently smaller and faster than the models they replace; actual performance is assessed side by side on identical data and conditions, against customer-defined metrics.

Separate compute, latency and memory in the evaluation. For Native, no extra compute or latency is added for the explanation, but the explanation layer has a memory footprint to budget. For Retrofit, the small compute and memory overhead is measured on the target. Neither statement supplies a universal footprint for a customer's model.

Measure the mode in the configuration the team intends to use, against the target's constraints. Do not treat the cost of structural explanation as a claim that every possible use of the decision object has no cost: prescription, when useful and supported, is a separate inference. Its distinction from the shared prediction and explanation forward pass is explained in The integrated decision object.

A concise selection review asks four questions: must the current model remain frozen; are architecture and weights accessible; is inspection enough or is structural change required; and what compute, latency and memory constraints must be assessed? A frozen-model inspection points toward Retrofit. Work requiring targeted editing, optimization or controlled correction points toward Native.

Whichever mode you choose, the customer's system rules decide how the decision object is used. To see what structural access changes compared with analysis from outside the model, read the post-hoc comparison.