APPLICATIONS
Where can better model evidencechange industrial decisions and design?
Industrial uncertainty can constrain decisions, usable performance, material requirements and product functions. Xpdeep makes the learned structure of AI models readable from within and helps characterize their learned domain, giving engineering teams new ways to examine what can change.
Explore six application patterns, from capabilities already demonstrated on real models to industrial opportunities that still require customer validation.
The industrial consequence of uncertainty differs by application. Each pattern below identifies a constraint, a possible change and the evidence needed to assess it.
01 BOUNDED OPERATIONAL DECISIONS
Move routine decisions toward the model.Keep experts for exceptions.
When a model provides structural evidence about its predictions and learned domain, the customer can examine which routine decisions might be handled under defined system rules, and which cases still require expert review.
ESCALATE →
EXPERT REVIEWA HOLD CAN RESOLVE UNDER SYSTEM RULES · EXPERT ATTENTION → ESCALATED EXCEPTIONS
- 01 WHAT IS BEING HELD BACK?
- Routine decisions wait for expert confirmation. As the installed base grows, routine reviews can consume increasing expert capacity and delay decisions.
- 02 WHAT BECOMES POSSIBLE WITH XPDEEP?
- Structural evidence and attributed domain awareness let the customer examine which routine cases could be handled under its system rules, and which still need an expert. Not every in-domain prediction becomes automatable, and prescription is not required for every bounded decision.
- 03 WHAT NEEDS TO BE DEMONSTRATED?
- The operational effect, measured on the customer’s application against the measures listed below.
EVIDENCE STATUS
Technical capabilities live; operational delegation gains require application-specific validation.
APPLICATION EXAMPLE · MEASUREMENT CORRECTION
An example of structural diagnosis and constrained correction: trace a model error to a recoverable input distortion, then compute a signal correction with structural justification.
Demonstrated capability: Measurement correction and signal-level localization are live and demonstrable.
Operational effect to establish: Reduced expert reviews, faster decisions or more assets per expert require measurement and customer validation.
MEASURES THE CUSTOMER ESTABLISHES
- Decisions handled without review
- Escalation and false-hold rates
- Expert attention required
- Decision response time
ACT / HOLD / ESCALATE RUN UNDER THE CUSTOMER’S SYSTEM RULES.
See the decision chain →02 MATERIAL AND RESOURCE ECONOMICS
Reduce the material and resourcesthat pay for uncertainty.
Some product and process margins compensate for uncertainty about state, loads or distance to a quality limit. Better estimation, structural explanation and attributed domain awareness can help engineering determine which part of that margin can be recovered within physical and engineering constraints.
MARGIN COMPOSITION
ILLUSTRATIVE · NOT TO SCALE
- Physical and engineering requirements, retained
- Additional margin held for uncertainty
- Portion to evaluate for recovery
- 01 WHAT IS BEING HELD BACK?
- Some products carry additional material, and some processes consume additional resources, because actual state, load, temperature or distance to a quality limit cannot be characterized precisely enough. Physical and safety margins remain necessary.
- 02 WHAT BECOMES POSSIBLE WITH XPDEEP?
- A sufficiently accurate model with structural evidence and attributed domain awareness can support engineering examination of whether part of a design margin can be recovered. In processes, constrained prescription with structural justification may help examine resource use or settings within approved constraints.
- 03 WHAT NEEDS TO BE DEMONSTRATED?
- Estimation accuracy, domain coverage and the engineering basis for any recovered margin. Redesign and operational changes follow the customer’s own validation; Xpdeep does not remove sensors or material.
A · PRODUCT DESIGN AND MATERIAL MARGINS
Conservative assumptions about state, load or temperature can lead engineering teams to retain additional material or design margin. Customer engineering retains responsibility for redesign and validation.
EVIDENCE STATUS
Engineering-validated material opportunity; no quantified savings claimed.Design and material opportunities identified and qualitatively validated by customer engineering on two programmes. No series deployment.
B · PROCESS OPERATIONS AND RESOURCE INTENSITY
A process may retain additional operating margin because its state, or its distance from quality and physical constraints, is insufficiently characterized.
EVIDENCE STATUS
Simulated feasibility demonstrated; XpProcess in development.Phase 1 produced a TRL 4 prototype on a simulated, physically constrained CSTR process. No validated industrial plant performance, autonomous plant operation or observed customer energy savings are established.
Material and resource economics concern the customer’s product or process. Model frugality concerns compute and memory on the deployment target.
03 OPERATING HEADROOM
Recover performance currently left unusedbecause uncertainty forces conservative limits.
Where the actual state and learned domain can be characterized sufficiently, an equipment manufacturer or operator may be able to examine additional usable performance within the existing approved operating limits. When uncertainty increases, the customer’s system returns toward its conservative baseline.
ILLUSTRATIVE
BASELINE WITHOUT XPDEEP · FIXED OPERATING LIMIT
WITH XPDEEP · CONDITION-AWARE OPERATING ENVELOPE
Expands conditionally within the approved range when state and validity are characterized.
Contracts toward the static baseline as uncertainty increases.
SAME APPROVED HARD LIMIT · CUSTOMER FALLBACK RULES PRESERVED
- 01 WHAT IS BEING HELD BACK?
- Static limits are set conservatively because asset state, history, degradation and model validity cannot be characterized precisely enough. Part of the margin covers uncertainty, not physics or regulation.
- 02 WHAT BECOMES POSSIBLE WITH XPDEEP?
- State estimation with structural explanation and attributed domain awareness could support a condition-aware envelope inside the customer-approved hard limits, with the static envelope kept as fallback. Xpdeep does not set new safety limits.
- 03 WHAT NEEDS TO BE DEMONSTRATED?
- How much headroom is usable, under which conditions, whether it holds in the field, and how the fallback behaves, all under the customer’s engineering and system authority.
EVIDENCE STATUS
Hypothesis under exploration; no delivered operating-headroom result.
The full lifecycle version, including targeted correction and product-variant evolution, requires Native mode.
OPPORTUNITIES TO EVALUATE
- Capacity
- Power
- Throughput
- Efficiency
- Availability
- Performance services
04 MODEL FAMILY EVOLUTION
When the product changes,the intelligence should not always have to start over.
Moving from product variant N to N+1, through new sensors, supplier-component changes, hardware revisions, new variants or different operating environments, can force costly model rework.
NATIVE MODE
01 PRODUCT VARIANT N
02 STRUCTURAL DIAGNOSIS
03 TARGETED LOCAL CORRECTION
04 VALIDATE BEFORE RELEASE
05 PRODUCT VARIANT N+1
UNCHANGED REGIONS PRESERVED · REST OF MODEL FROZEN
ILLUSTRATIVE
- 01 WHAT IS BEING HELD BACK?
- Each new variant can require additional model engineering, testing and validation, particularly when sensors, components or operating conditions change.
- 02 WHAT BECOMES POSSIBLE WITH XPDEEP?
- Native structural diagnosis and targeted editing can identify and modify a specific learned region while the rest of the model stays frozen. The hypothesis is that this may reduce the engineering effort of adapting intelligence across variants.
- 03 WHAT NEEDS TO BE DEMONSTRATED?
- Measured by the customer for the application. Local correction does not automatically reduce regression testing, revalidation or certification requirements.
EVIDENCE STATUS
Potential engineering benefit remains a hypothesis to prove.
WHAT THE CUSTOMER MEASURES
- Diagnosis and engineering time
- Accuracy on the new variant
- Scope of model changes
- Regression-testing effort
- Revalidation work required
05 PERCEPTION DOMAIN GATE
A perception model should knowwhen the world has moved beyond what it learned.
How can a perception system identify situations that differ from what its learned models were trained to recognize? Xpdeep can provide structural explanations and attributed domain awareness for learned perception models, helping engineering teams examine unfamiliar visual conditions, novel classes and the factors associated with domain departure.
ILLUSTRATIVE. Whether a visual change moves an input outside the learned domain depends on the model and its training data.
CURRENT STATE · NORMAL-CONDITION EXAMPLE
Inside learned domain
ATTRIBUTED DOMAIN STATE
The model remains in the domain it learned. Structural explanation shows what drove the detection.
PERCEPTION MODEL
→DOMAIN VALIDITY GATE
→DOWNSTREAM SYSTEM
Xpdeep works at the level of each accessible learned model, with read access to its PyTorch architecture and weights; supplier-owned models require supplier cooperation. It does not supply perception models or the surrounding perception or control stack, and image-level prescription is not available.
The domain state feeds downstream system decisions, slow down, fall back, request review. Domain state alone does not grant authority; the downstream system applies the customer’s rules.
- 01 WHAT IS BEING HELD BACK?
- A perception model may produce unreliable outputs in conditions insufficiently represented during training, without making the departure explicit in its own output, for example under new lighting, weather, sensor drift or unseen object classes. Functions may stay undeployed, or extra sensing and checks are added.
- 02 WHAT BECOMES POSSIBLE WITH XPDEEP?
- Attributed domain awareness reports when an input departs from the learned domain and which factors are associated with the departure; for classification tasks, novel-class detection flags outputs outside the learned classes.
- 03 WHAT NEEDS TO BE DEMONSTRATED?
- Gate detection quality on representative conditions, false-gate rates, and how downstream rules use the signal. The customer validates the application and any resulting system decision.
EVIDENCE STATUS
Model-level capabilities demonstrated; application-level gate performance requires validation. Structural explanation and domain awareness have been demonstrated on image, detection, fusion and video model types; this is not an operationally validated safety gate.
ADAS / AUTONOMY · ROBOTICS
See vision capabilities →06 AGENTIC DECISION OBJECTS
Orchestrators can route tasks.They still depend on what each model returns.
Orchestrators increasingly depend on outputs from specialized learned models. Xpdeep can supply model-level structural evidence and supported decision capabilities to help the surrounding orchestrator evaluate individual model outputs.
ORCHESTRATOR
STANDARD SPECIALIZED MODEL
PREDICTION
XPDEEP SPECIALIZED MODEL
DECISION OBJECT
- PREDICTION
- STRUCTURAL EXPLANATION
- ATTRIBUTED DOMAIN AWARENESS
- SUPPORTED DECISION CAPABILITIES
Xpdeep supplies specialized decision objects to the orchestration layer. It does not orchestrate.
- 01 WHAT IS BEING HELD BACK?
- An opaque prediction from a specialized model does not explain itself or report domain departure, so experts may re-check outputs inside agentic workflows.
- 02 WHAT BECOMES POSSIBLE WITH XPDEEP?
- MCP / API queries one Xpdeep AI model at a time and returns the model-level evidence supported in its configuration, for the orchestrator to use under the customer’s rules.
- 03 WHAT NEEDS TO BE DEMONSTRATED?
- How the orchestrator uses the evidence, which actions it may take, and hold and escalation rules. Effects on expert review or decision latency are application-specific.
EVIDENCE STATUS
Single-model MCP / API live; XAS in development.
START WITH ONE FUNDED PROBLEM
Start with one consequential problemyou already fund.
A model or engineering problem, a consequential operational decision, a product function, a subsystem programme, a material, resource or performance constraint, or a perception or signal-analysis problem. Phase 1 is funded, typically three to six months, with a success criterion agreed at scoping.
WHICH DECISION, ENGINEERING CONSTRAINT OR PRODUCT POSSIBILITY SHOULD WE EXAMINE FIRST?
EVALUATE MATERIAL OR RESOURCE MARGINS
A product or process carrying margin for uncertainty
Discuss this application →EVALUATE MODEL-FAMILY EVOLUTION
A product or asset variant that forces model rework
Discuss the evidence needed →SUPPLY AN ORCHESTRATOR
A specialized model used inside an agentic workflow
Discuss this application →