Xpdeep
Talk to us

TECHNOLOGY

The barrier is inside the model.

Xpdeep changes what the learned model itself returns.

From model design to production and controlled evolution.

Structural control of the learned model enables three things: richer inputs for bounded decisions, targeted model engineering instead of retraining by trial and error, and controlled evolution of the model in service.

STANDARD DEEP MODEL

INPUT

LEARNED MODEL

PREDICTION

XPDEEP MODEL

ONE MODEL ARTEFACT

INPUT

XPDEEP MODEL

A · PRIMARY INFERENCE

Prediction + structural explanation

Attributed domain state

Prediction and explanation share one forward pass.

B · PRESCRIPTION

Minimal feasible intervention

Structural justification

Separate inference, invoked when useful. Temporal and tabular stages; Native and Retrofit.

CUSTOMER SYSTEM · OUTSIDE THE MODEL

Act / Hold / Escalate under customer-defined rules

Standard deep model: input, learned model, prediction. Xpdeep model: one model artefact inside a model boundary producing group A, a primary inference with prediction plus structural explanation and attributed domain state in one forward pass, and group B, a separate prescriptive inference with a minimal feasible intervention and its structural justification, invoked when useful on temporal and tabular stages. Both feed a separate customer system outside the model, which acts, holds or escalates under customer-defined rules.

A different model output.

Prediction and structural explanation share one forward pass, with attributed domain state. Prescription is a separate inference, invoked when useful and supported.

  1. 01

    STRUCTURAL EXPLANATION

    What drove this output?

    Read from the model structure itself: which input variables, with what weight, through which temporal dependencies.

  2. 02

    ATTRIBUTED DOMAIN AWARENESS

    Is the model still valid here?

    A graded distance to the trained domain, with the responsible variables and time windows attributed, plus novel-class detection for an output belonging to no learned class.

    Domain state is reported separately from prediction confidence.

  3. 03

    CONSTRAINED MINIMAL INTERVENTION

    What is a minimal feasible move?

    A feasible input change, optimized for minimality, that improves the target outcome under operational 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

    Variables, weights, temporal windows

  3. CHECK DOMAIN

    Graded domain state, attributed by variable and time window

  4. PRESCRIBE

    Minimal feasible intervention under constraints

  5. JUSTIFY

    Structural justification of the intervention

  6. ACT / HOLD / ESCALATE

    Within defined conditions, with fallback

SAME FORWARD PASS
Prediction and explanation together.
SEPARATE INFERENCE
Run only when an intervention is useful.

The surrounding system stays in control.

Xpdeep supplies model-level evidence. Execution, validation and system safety remain the customer’s responsibility. Domain awareness alone does not authorize action.

ONE MODEL. THREE LOOPS.

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

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

  1. Predict + explain
  2. Read attributed domain state
  3. Prescribe when usefulSeparate inference · temporal and tabular
  4. Structurally justify the intervention

→ 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 edit, rest of the model frozen
  5. 5Verify the effect

Training stops being trial and error and becomes design.

CONSEQUENCEKPI alignment, fewer unnecessary inputs, controlled complexity and deployment footprint.

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

EXISTING PYTORCH MODEL

WHAT HAPPENS

  • Predictive model stays frozen
  • Architecture and weights remain unchanged
  • Structural explanations are learned from the model structure
  • Prediction and explanation run together in the same artefact
  • Full decision object available in production
  • No targeted structural edit or correction
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

WHAT HAPPENS

  • Prediction and explanation learned jointly
  • New model version produced
  • Editable learned structure
  • KPI alignment
  • Input reduction and frugality
  • Targeted local editing
  • Controlled evolution
  • Full three-loop architecture
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

  • Full decision object.
  • All three loops.
  • Signal-level localization: beyond identifying relevant variables, structural explanation localizes the segments and morphology within the signals that drove the model’s output.
  • Deepest scientific edge.
TIME SERIES & SIGNALSILLUSTRATIVE
1Input variables2Relevant time windows3Signal morphology4Segments that drove the predictionA highlighted segment is not necessarily a physical fault.

02

Tabular

  • Full decision object.
  • Structural advantage is weaker on pure static tabular data.
TABULARILLUSTRATIVE
Contributions to the model output.

03

Image

  • Structural explanation.
  • Attributed domain state.
  • Error breakdown.
  • Design loop.
IMAGEILLUSTRATIVE
AStructural explanationBAttributed domain stateCNovel-class detection

04

Video

  • Spatio-temporal structural explanation.
  • Attributed domain state.
  • Design loop.
VIDEOILLUSTRATIVE
Spatio-temporal structural explanation.

Prescription applies to temporal and tabular stages.

Image and video use structural explanation, domain awareness and the design loop. Image-level prescription: not available; under study.

At the model.Not around it.

Xpdeep operates at model level.
It changes what the learned model itself returns.

COMPLEMENTARY TO

  • Sensors
  • Perception
  • MLOps
  • Monitoring / guardrails
  • Process optimization
  • Orchestration
  1. PHYSICAL WORLD
  2. DIGITIZED SIGNAL / IMAGE / VIDEO
  3. LEARNED MODELXPDEEP
  4. APPLICATION / CONTROLLER / ORCHESTRATOR

The explanation travels with the prediction.

THE SAME MODEL ARTEFACT · THREE LOCATIONS

SCHEMATIC

Cloud

XPDEEP MODEL ARTEFACT

INPUT → LOCAL INFERENCE

  • Prediction + structural explanation
  • Attributed domain state

Prescription where applicable and within the target’s resource budget.

On-premises

XPDEEP MODEL ARTEFACT

INPUT → LOCAL INFERENCE

  • Prediction + structural explanation
  • Attributed domain state

Prescription where applicable and within the target’s resource budget.

Embedded target

ECU / MICROCONTROLLER

CUSTOMER CONTROLLER BOUNDARY

XPDEEP MODEL ARTEFACT

INPUT → LOCAL INFERENCE

  • Prediction + structural explanation
  • Attributed domain state

Prescription where applicable and within the target’s resource budget.

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

The same Xpdeep model artefact runs in the cloud, on-premises, or on an embedded ECU or microcontroller inside the customer's controller boundary, each producing prediction with structural explanation and attributed domain state locally, with prescription where applicable. 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.
ON-BOARD

Prediction

Structural explanation

Validity-domain check

Prescription where appropriate

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

    The explanation comes out of the same forward pass as the prediction: no second model. In Native mode only the memory of the explanation layer is budgeted; in Retrofit the overhead is measured on the target. The domain state is read in the model's latent space. Prescription is a separate inference, run only when an intervention is useful. Post-hoc methods re-evaluate the model dozens of times per explained prediction.

  • 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. Xpdeep attaches at the digitized signal. This is set at scoping for a first phase.

Adjacent layers you may already buy

They work after the fact, around the deployed model or on the process. Xpdeep changes what the model itself returns.

Adjacent layers compared with Xpdeep
LAYEREXAMPLESWHAT IT DOESWHAT XPDEEP ADDS
Traditional XAI and model testingSHAP, LIME, integrated gradients, Grad-CAM, saliency mapsApproximates a black box after inference.Structure read from the model itself, in the same forward pass.
Monitoring and guardrailsModel monitoring platformsObserves deployed systems; detects drift once it has happened.Domain departure attributed to variables and time windows at each inference, plus prescription.
Industrial optimization and APCProcess optimizers, APC and MPC vendorsOptimizes the process, taking the model as given.A minimal feasible intervention with its structural justification and attributed domain state, emitted by the model.
Interpretable-by-design architecturesConcept bottlenecks, prototype networks, TFT-type forecastersMakes one property of the model readable by construction.The integrated decision object and three loops on one model, readable across very many simultaneous signals.
Time-series foundation modelsChronos, TimesFM, MoiraiPretrained general forecasters adapted to a domain.A model trained on your signals and KPI that returns the decision object and closes the three loops.

Explainability does not trade off against performance.

On time-series data, Xpdeep models are at minimum equivalent to standard deep learning and frequently superior.

INPUT VARIABLES

105 → 19

Up to 82% fewer input variables, at equal or better accuracy.

Selected validated results across Confiance.AI and client programs.

UP TO 4×

FASTER MODEL DEVELOPMENT

Selected validated results across Confiance.AI and client programs.

UP TO 35×

FASTER INFERENCE

Independent programme evaluation.

UP TO 50%

SMALLER MODELS

Independent programme evaluation.

8% vs 12%

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

Virtual temperature sensor: Xpdeep model 8% of ROM; state-of-the-art comparison model 12%.

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 to: prediction, prescription, domain state, structural explanation

IN DEVELOPMENT

  • XpComplyAutomated compliance documentation and audit artefacts
  • XpProcessMaterial and energy optimization under physical and engineering constraints. Each change is returned as a minimal feasible intervention with structural justification and attributed domain state.In development. First phase completed and shown to domain specialists; first industrial engagement in design.
  • Image-level prescriptionNot available; under study
  • Xpdeep Agentic Server (XAS)Typed decision-object infrastructure for agentic stacks
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 one decision you already fund. One agreed KPI. Evidence on your data and constraints.

Talk to us Technical resources