Xpdeep
Talk to us

TECHNOLOGY

Native Structural Explainability for Deep Learning

Xpdeep makes the learned structure of deep learning models readable from within. In Native mode, engineers can inspect and locally edit that structure, while preserving the predictive power of deep learning. The same foundation supports structural evidence and domain awareness in production, and controlled model evolution.

Design, Production and Controlled Evolution are the first three model loops built on this foundational technology.

STANDARD DEEP MODEL

INPUT

LEARNED MODEL

STANDARD DEEP ARCHITECTURE

PREDICTION

XPDEEP MODEL — MODEL-LEVEL CAPABILITIES

ONE MODEL ARTEFACT

INPUT

LEARNED MODEL

XPDEEP ARCHITECTURE

PREDICT · PRIMARY INFERENCE

Prediction · Structural explanation · Attributed domain awareness

PRESCRIBE · SEPARATE, OPTIONAL INFERENCE

Separate constrained prescription, where applicable.

CUSTOMER SYSTEM · OUTSIDE THE MODEL

Act / Hold / Escalate under customer-defined rules

Both are learned models. The Xpdeep architecture can return additional model-level outputs, defined in the next section.

Standard deep model: input, learned model with a standard deep architecture, prediction. Xpdeep model: one model artefact inside a model boundary containing a learned model with the Xpdeep architecture. Model-level capabilities: prediction, structural explanation and attributed domain awareness through primary inference, and separate constrained prescription, where applicable, through a separate inference. Both feed a separate customer system outside the model, which acts, holds or escalates under customer-defined rules.

A different model output.

Four model-level capabilities, defined once here and referred to by name elsewhere on this page.

  1. 01

    STRUCTURAL EXPLANATION

    What drove this output?

    The learned structural drivers of a prediction: relevant variables, their contributions and temporal dependencies. Learned structurally, not reconstructed through an external surrogate.

  2. 02

    ATTRIBUTED DOMAIN AWARENESS

    Is the model still valid here?

    A graded characterization of whether the input remains within the trained domain, attributed to relevant variables and temporal windows. For classification tasks, novel-class detection identifies outputs that belong to none of the learned classes.

    Not a generic prediction-confidence score.

  3. 03

    CONSTRAINED MINIMAL FEASIBLE INTERVENTION

    What is a minimal feasible move?

    When useful and supported, a separate prescriptive inference computes an input intervention that improves the target outcome under specified constraints.

  4. 04

    STRUCTURAL JUSTIFICATION

    Why does this move change the predicted outcome?

    The learned structural dependencies that explain why the proposed intervention changes the model output.

From prediction to a decision the system can carry.

  1. PREDICT

    Estimate the outcome

  2. EXPLAIN

    When retained

  3. CHECK DOMAIN

    Attributed domain state

  4. PRESCRIBE

    Separate, optional

  5. JUSTIFY

    Structural justification

  6. ACT / HOLD / ESCALATE

    Customer system decides, within defined conditions

SAME FORWARD PASS
Primary inference.
SEPARATE INFERENCE
Optional prescription.

The surrounding system stays in control.

ENGINEERING RESPONSIBILITY

Xpdeep can provide model-level evidence to support engineering, validation and assurance work. The customer system determines ACT / HOLD / ESCALATE and remains responsible for system safety, system-level validation, compliance, certification and other required justifications. Xpdeep does not itself establish system safety, and domain awareness alone does not authorize action.

ONE MODEL. THREE LOOPS.

Build it.Let it carry decisions.Evolve it under control.

Design, production and controlled evolution, attached to your existing lifecycle.

YOUR AI ENGINEERING LIFECYCLE. UNCHANGED.

  1. Requirements & ODD
  2. Data & Training
  3. Verification & Qualification
  4. Embedded SW / HW
  5. Model Monitoring
  6. Maintenance in Service

YOUR ENGINEERING LIFECYCLE · SURROUNDING CONTEXT

01 DESIGN

  1. Initial training
  2. Read the learned structure
  3. Diagnose the problem zone
  4. Local edit, rest frozen
  5. Verify the effect

02 PRODUCTION — USE MODEL-LEVEL DECISION CAPABILITIES

  1. Predict and assess domain
  2. Explain where required
  3. Prescribe where applicable, through separate inference

→ CUSTOMER SYSTEM: ACT / HOLD / ESCALATE

03 CONTROLLED EVOLUTION

  1. Operational feedback
  2. Structural diagnosis
  3. Targeted correction, rest frozen
  4. Validate
  5. Redeploy between operating periods

↺ BACK TO THE MODEL ONLY AFTER VALIDATION

XPDEEP-NATIVE MODEL

The same model artefact in all three loops

Native closes all three loops.

Controlled evolution is validated change between operating periods.

Three loop panels, Design, Production and Controlled Evolution, each connected to one shared Xpdeep-native model, inside the customer's surrounding engineering lifecycle. Production outputs feed a separate customer system that acts, holds or escalates. Controlled evolution returns to the model only after validation, with redeployment between operating periods.

Train once. Then edit.

  1. 1Initial training
  2. 2Read the learned structure
  3. 3Structural diagnosis of the problem zone
  4. 4Targeted local correction, rest of the model frozen
  5. 5Verify the effect

Conventional full retraining is not required for a targeted local correction.

CONSEQUENCEKPI alignment, input reduction and controlled model complexity.

Native mode. Customer validation and qualification still apply.

ILLUSTRATIVE LEARNED STRUCTURE

ILLUSTRATIVE

BEFORE CORRECTION

AFTER TARGETED CORRECTION

  1. STRUCTURAL DIAGNOSIS
  2. LOCAL EDIT
  3. VERIFICATION
  • Targeted region
  • Rest of model frozen
  • Verify the effect
Illustrative before-and-after view of a learned structure. One region is highlighted before correction; after targeted correction only that region is modified and every other node and connection is unchanged. Sequence: STRUCTURAL DIAGNOSIS, LOCAL EDIT, VERIFICATION.

Two ways in.Native goes further.

Retrofit preserves the predictive model and opens it structurally.
Native enables targeted editing and controlled correction.

Retrofit covers structural diagnosis and production use. Native carries all three loops. Deployment-output configurations and overhead are covered under Runtime.

RETROFIT

EXISTING PYTORCH MODEL

ROLE

Understand and assess an existing PyTorch AI model while preserving its predictive architecture, weights, predictions and original performance. Explanations are learned structurally from the model, and supported structural and production capabilities are incorporated into the resulting artefact.

WHAT HAPPENS

  • Predictive model stays frozen
  • Architecture, weights, predictions and original predictive performance remain unchanged
  • Structural explanations are learned from the model
  • Supported structural and production capabilities incorporated into the artefact
  • Structural analysis only: no targeted editing or optimization
  • Retrofit structural analysis is not Native ante-hoc model design

LIMITS

No targeted editing, predictive optimization or controlled structural correction: the frozen model can be read, not corrected. A change to its behaviour is made by the model's owner or supplier.

ACCESS REQUIRED
Read access to PyTorch architecture and weights + representative inputs.
BEST FIT
Existing or supplier model that cannot yet be replaced.
DEPLOYED FOOTPRINT
A Retrofit artefact is larger than the original model. Its compute and memory overhead are measured on the target.

NATIVE

XPDEEP-NATIVE MODEL

ROLE

Build an AI model with native structural explainability. Engineers can inspect and edit its learned structure for model design, KPI alignment, input reduction, optimization and frugality.

WHAT HAPPENS

  • Ante-hoc: predictive and explanatory structures learned jointly
  • Inspectable, locally editable learned structure
  • KPI alignment
  • Input reduction
  • Model optimization and frugality
  • Targeted local correction
  • Full three-loop architecture
  • Customer validates the resulting model version

LIMITS

Requires training data and target metrics, and produces a new model version that the customer validates and deploys through its own chain.

ACCESS REQUIRED
Training data + target metrics.
BEST FIT
Recommended path for deployment and embedded targets.
DEPLOYED FOOTPRINT
A Native model is frequently smaller and faster than the model it replaces. The deployed footprint is measured on the customer’s target.

No structural analysis is possible without read access to the model architecture and weights, or a native model.

Supplier-owned models require supplier cooperation and read access to the PyTorch architecture and weights.

One architecture.Different modalities.

01

Time series & signals

  • Xpdeep’s strongest scientific specialization: multivariate temporal data.
  • Signal-level localization: relevant variables, relevant temporal windows, and the signal segments and morphology supporting the model output.
  • All four model-level capabilities; all three loops.
  • Model-level attribution, not identification of a physical fault.
TIME SERIES & SIGNALSILLUSTRATIVE
1Input variables2Relevant time windows3Signal morphology4Segments that drove the predictionA highlighted segment is not necessarily a physical fault.

02

Tabular

  • All four model-level capabilities.
  • The architectural advantage over strong conventional methods is weaker on purely static tabular data.
TABULARILLUSTRATIVE
Contributions to the model output.

03

Image

  • Structural explanation.
  • Attributed domain awareness, with novel-class detection.
  • Error breakdown.
  • Design loop.
IMAGEILLUSTRATIVE
AStructural explanationBAttributed domain stateCNovel-class detection

04

Video

  • Spatio-temporal structural explanation.
  • Attributed domain awareness, with novel-class detection where applicable.
  • Design loop.
VIDEOILLUSTRATIVE
Spatio-temporal structural explanation.

Constrained prescription is supported for temporal and tabular data. Image-level prescription is not currently available and remains under study.

Not every deployed configuration exposes every supported capability; see Runtime.

At the model.Not around it.

Xpdeep works at the level of the learned AI model. It is not an external control layer between the model and your execution stack, and it replaces none of the systems around it.

DOES NOT REPLACE

  • Sensors and acquisition hardware
  • Perception hardware and front-end
  • MLOps
  • Monitoring and guardrails
  • Industrial process control
  • Orchestrators
  • Customer engineering and validation systems
  1. PHYSICAL WORLD
  2. DIGITIZED SIGNAL / IMAGE / VIDEO
  3. LEARNED MODELXPDEEP
  4. APPLICATION / CONTROLLER / ORCHESTRATOR

Explainability in design.
Runtime outputs by configuration.

Native structural explainability remains foundational during model development. A deployed model does not necessarily have to generate structural explanations. When runtime explanations are unnecessary, their generation can be omitted, including to reduce the deployed model’s resource footprint.

The capabilities actually available in production depend on the chosen deployment configuration. Removing runtime explanations does not imply that every other model-level capability remains present. Attributed domain awareness, prescription and structural justification must be assessed according to the supported and retained configuration. Prescription remains a separate, optional inference from primary prediction. No universal numerical resource saving is claimed.

ONE MODEL ARCHITECTURE. MULTIPLE DEPLOYMENT ENVIRONMENTS.

SCHEMATIC

SHARED OUTPUT LEGENDPrediction · structural explanation and attributed domain state when retained · separate optional prescription when supported. Compiled artefact, retained features and memory footprint may differ by environment.

Cloud

XPDEEP MODEL · LOCAL INFERENCE

Broadest compute and memory budget.

On-premises

XPDEEP MODEL · LOCAL INFERENCE

Customer infrastructure; configuration set by its resources.

Embedded target

ECU / MICROCONTROLLER

CUSTOMER CONTROLLER BOUNDARY

XPDEEP MODEL · LOCAL INFERENCE

Tight resource budget; outputs retained to fit the target.

LOCAL INFERENCE · NO CLOUD CONNECTION REQUIRED

OPTIONAL LOG UPLOAD ↓

Separate from the inference path. Inference does not depend on it.

DESIGN & CONTROLLED EVOLUTION

Cloud or on-premises

↑ VALIDATED MODEL VERSION → REDEPLOYMENT

One Xpdeep model architecture can be deployed in the cloud, on-premises, or on an embedded ECU or microcontroller inside the customer's controller boundary, with local inference in each. The compiled artefact, retained outputs and memory footprint may differ by environment. Shared output legend: prediction, structural explanation and attributed domain state when retained, separate optional prescription when supported. A separate optional log-upload path goes to design and controlled evolution in the cloud or on-premises; a validated model version returns for redeployment. Inference does not depend on the log-upload path.
CONNECTIVITY

None required for the production inference loop.

DESIGN / EVOLUTION

Cloud or on-premises over uploaded logs.

INTERFACES

C / C++

Python

OUTPUTS

JSON

Parquet

No proprietary transport or logging framework imposed.

The customer owns the models built for it.
Xpdeep retains rights to the underlying technology.

ENGINEERING FACTS

What it costs, how you validate it, where it sits.

  • COST AT INFERENCE

    Native explanations are produced in the predictive forward pass when retained, without a separate explanation model. The explanation layer’s memory footprint remains relevant. Retrofit adds an explanation layer whose compute and memory overhead must be measured on the target. Production configurations may omit runtime explanation generation when unnecessary; no generic numerical saving is claimed.

  • VALIDATION WITH YOUR OWN CHAIN

    An Xpdeep model is a standard deep model. Your teams validate and qualify it with their own tools, processes and metrics, as they would any PyTorch model.

  • FEED THE NATIVE STREAM

    Pre-aggregated features degrade results: information is lost upstream before the model sees it. Feed native temporal streams rather than unnecessarily pre-aggregated features; this is set at scoping.

Adjacent layers you may already buy

Each has a distinct primary function, and some capabilities overlap. Xpdeep’s distinction is native structural explainability and what it enables across model design, domain awareness, constrained intervention and controlled evolution.

Adjacent layers compared with Xpdeep
LAYEREXAMPLESWHAT IT DOESWHAT XPDEEP ADDS
Traditional XAI and model testingSHAP, LIME, integrated gradients, Grad-CAM, saliency mapsAnalyses a trained model through gradient, perturbation or surrogate procedures, depending on the method.Explanation learned structurally within the model rather than reconstructed afterwards.
Monitoring and guardrailsModel monitoring platformsProvides system-level safeguards, drift detection and checks on deployed systems.Attributed domain awareness returned by the model itself, at variable and time-window level.
Industrial optimization and APCProcess optimizers, APC and MPC vendorsPredictive optimization of the process under constraints.A constrained intervention computed by the learned model, with its structural justification.
Interpretable-by-design architecturesConcept bottlenecks, prototype networks, TFT-type forecastersGenuine model-level interpretability by construction.Local editing of the learned structure and controlled evolution, across many simultaneous signals.
Time-series foundation modelsChronos, TimesFM, MoiraiPretrained forecasters adaptable to downstream tasks.A model designed on your signals and KPI, with native structural explainability across the three loops.

Explainability does not trade off against performance.

On time-series data, Xpdeep models achieve accuracy at least equivalent to standard deep learning and frequently superior.

INPUT VARIABLES

105 → 19

Up to 82% fewer input variables; 105 reduced to 19 at equal or better accuracy.

Independent programme evaluation.

UP TO 4×

FASTER MODEL DEVELOPMENT

Client evaluation.

UP TO 35×

FASTER INFERENCE

Selected validated results across Confiance.AI and client programmes.

UP TO 50%

MODELS UP TO 50% SMALLER

Selected validated results across Confiance.AI and client programmes.

8% vs 12%

ROM USED ON AN UNNAMED EUROPEAN TIER-1’S EMBEDDED TARGET

A European Tier-1 OEM’s own embedded target: 8% of ROM for the Xpdeep model vs 12% for its state-of-the-art model (virtual temperature sensors).

Unnamed European Tier-1.

Figures come from different programmes and are not all from one project.

What is live today.

LIVE

  • Core enginesTraining · Structural explanation · Optimization · Prescription
  • XpVizModel understanding and optimization workbench
  • XpActOperational interface for prescriptive control
  • Platform layerLineage · Versioning · Governance artefacts · Audit history
  • MCP / APISingle-model access

FUTURE OFFERING · NOT AVAILABLE

  • XpComplyNot available yet. Future compliance documentation and audit artefacts.Coming Soon
  • XpProcessPhysically constrained simulated CSTR process; TRL 4 prototype. Prediction and structural explanation evaluated on simulated data; proposed setpoint changes checked against simulator constraints. No real-plant performance or autonomous deployment claimed.In Development
  • Xpdeep Agentic Server (XAS)Future extension for agentic stacks; not a shipping orchestration platformIn Development
  • Image-level prescriptionNot currently availableUnder Study
Engineering boundaries matter.
  • Structural justification does not automatically establish physical causality.
  • “Minimal” means minimal feasible under the stated constraints and optimization procedure, not a unique global minimum.
  • Domain awareness covers the model’s retained input variables. Removed variables remain outside that coverage and must be monitored at system level where relevant to safety.
  • Xpdeep is not a safety-certified component. System safety, validation and certification remain with the customer and relevant authority.
  • Image-level prescription: not available; under study.
  • The effect of controlled evolution on requalification is still being established.
  • No structural analysis without model architecture / weights or a native model.
  • Static tabular is a weaker differentiation surface.

Bring us one model.Or one decision loop.

Start with a funded model, engineering problem or consequential decision. Agree what success means, then establish the evidence on your data and within your constraints.

Talk to us Technical resources