Xpdeep
Talk to us

AEROSPACE & DEFENCE

Let learned systems carry more mission decisions inside explicit operating boundaries.

Xpdeep gives learned models structural understanding of their own decisions, operating domain and limits of authority.

THE SURROUNDING SYSTEM STAYS IN CONTROL

01 MISSION STATE

A mission system should know when the situation it learned is no longer the situation it faces.

A learned model can remain technically confident while operating outside the conditions represented in its training data.

Xpdeep adds an attributed domain state: not only whether the model has left known conditions, but which variables and temporal patterns are responsible.

  1. KNOWN MISSION STATE

    INSIDE KNOWN CONDITIONS

    GRADED DOMAIN DISTANCE

  2. BOUNDARY APPROACH

    APPROACHING DOMAIN EDGE

    GRADED DOMAIN DISTANCE

    Attributed to: one variable, last temporal window

  3. DOMAIN DEPARTURE

    OUTSIDE KNOWN CONDITIONS

    GRADED DOMAIN DISTANCE

    Attributed to: two variables, sustained temporal pattern

ATTRIBUTED DEPARTURE: NOT A GENERIC CONFIDENCE SCORE

Domain awareness is necessary for bounded delegation. It is not sufficient for system safety.

SIGNALS

When a model fails on signals, the structure can show why.

ANONYMIZED PROGRAMME EXAMPLE

PROBLEM

A defence signal-classification problem the customer’s teams had not resolved.

STRUCTURAL DIAGNOSIS

Reading the learned model exposed the blocker during the programme, in front of the customer’s technical team.

FOLLOW-ON

Follow-on projects in preparation.

XPDEEP OPERATES DOWNSTREAM OF THE DIGITIZED SIGNAL

Xpdeep does not supply the RF front end, sensor hardware or signal-acquisition chain.

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

02 DOMAIN

The problem is not only drift. Sometimes the model is seeing something it never learned.

GRADED DOMAIN VALIDITY

How far is the current state from the trained domain?

NOVEL-CLASS DETECTION

Does this output belong to any class the model actually learned?

WHERE IT SHOWS UP

  • Unseen signal class
  • Unseen defect
  • Unfamiliar operating state
  • Novel target class
  • Changed mission condition

ATTRIBUTED DOMAIN STATE = which variable, time window or factor drove the departure.

Not generic anomaly detection. Not a confidence score.

03 AUTHORITY

The model should carry the decision only while the conditions remain explicit.

PRIMARY INFERENCE

MISSION STATE

ESTIMATESTRUCTURAL EXPLANATIONCHECK DOMAIN

WHEN AN INTERVENTION IS USEFUL

PRESCRIBE WHERE APPLICABLEJUSTIFY

SYSTEM RULE

ACTHOLDESCALATE

Prediction and structural explanation share one forward pass. Prescription is a separate inference, invoked when useful on temporal and tabular stages.

CONDITIONAL AUTHORITY

  1. CUSTOMER-DEFINED PERMITTED AUTHORITY

    The mission system sets which decisions may be delegated, and the limits.

  2. CONDITIONAL USE WITHIN THAT AUTHORITY

    The model output is used only while its attributed domain state meets the customer’s conditions.

  3. CONTRACTION · HAND-BACK · FALLBACK

    Under customer rules, authority contracts, the decision is handed back, or the fallback applies.

Application opportunity: evaluate mission capability and expert workload under customer-defined authority and fallback rules.

THE SURROUNDING SYSTEM STAYS IN CONTROL.

Xpdeep closes the model-constrained part of the loop. Domain awareness does not set mission policy, and Xpdeep does not define system-level safety.

PERCEPTION

A perception model should know when its view of the world has left its learned domain.

Xpdeep connects to the customer’s or supplier’s learned perception model.

Xpdeep does not supply camera systems, EO/IR sensors, optronics hardware or perception models.

Structural integration requires read access to the PyTorch architecture and weights. Supplier-owned models require the supplier’s cooperation.

LEARNED PERCEPTION MODELS FOR MISSION AND PLATFORM SYSTEMS.

DOMAIN STATE · INSIDE KNOWN DOMAIN

STRUCTURAL EXPLANATION · ATTRIBUTED

TECHNICAL BOUNDARY: Image-level prescription: not available; under study.

OPERATIONAL SCALE

The objective is not maximum autonomy. It is fewer unnecessary hand-backs.

MANY ROUTINE STATES → MODEL HANDLES INSIDE CONDITIONS

TRUE EXCEPTIONS → HOLD / ESCALATE → HUMAN

When the model can identify the states it understands, human attention can concentrate on genuine exceptions instead of reviewing every routine case.

POTENTIAL OPERATIONAL CONSEQUENCES

  • Fewer unnecessary escalations
  • More systems per expert
  • Faster response
  • Reduced decision bottlenecks

04 EVOLUTION

NATIVE MODE.

When the environment changes, correct what changed. Keep the rest fixed.

  1. OPERATIONAL FEEDBACK
  2. STRUCTURAL DIAGNOSIS
  3. TARGETED CORRECTION · REST FROZEN
  4. VALIDATION
  5. REDEPLOYMENT BETWEEN OPERATING PERIODS

REST OF MODEL FROZEN

Controlled evolution is a validated change between operational periods, not continuous learning.

POTENTIAL VALUE

  • Faster diagnosis
  • Targeted correction
  • Preserved model regions
  • Clearer validation scope

Reduced qualification scope is not automatic; it requires application-specific evidence and acceptance.

CONDITIONAL MISSION AUTHORITY

Authority can expand or contract with the mission state.

CONDITIONAL AUTHORITY

  1. STATIC AUTHORITY LIMIT
  2. MISSION STATE + DOMAIN STATE
  3. CONDITIONAL AUTHORITY
  4. ACT / HOLD / ESCALATE
  5. FALLBACK PRESERVED

Illustrative transformation pattern. Mission authority and operating rules remain defined by the customer and the surrounding system.

Aerospace & defence work already exists.

  1. PROGRAMME EXPERIENCE

    Defence signal classification: reading the learned model exposed a blocker the customer’s teams had not resolved. Follow-on projects in preparation.

  2. CONFIANCE.AI

    Structural explanations surfaced a dataset weakness that existing tooling had missed on one aerospace programme within the Confiance.AI framework.

  3. PLATFORM

    Core engines and single-model MCP / API access are live.

Deployment on embedded platform compute or on-prem / sovereign infrastructure. Access restricted to NATO member and compatible countries.

See platform status →

Mission-critical engineering boundaries.

EXPAND

  • Xpdeep does not provide sensors or RF front-end systems.
  • Structural integration requires read access to the PyTorch architecture and weights, or a Native model.
  • Controlled evolution is not online learning.
  • Perception models: image-level prescription not available; under study.
  • The customer’s surrounding system defines and authorizes actions.
  • Attributed domain state covers the retained model inputs; alone, it does not authorize action or establish system safety.
  • Structural justification does not automatically establish physical causality.
  • Minimal means minimal feasible under the stated constraints and optimization procedure.
  • Targeted editing and controlled correction require Native mode.
  • System validation and certification remain with the customer and relevant authority.
  • Reduced requalification scope requires application-specific evidence and acceptance.

START WITH ONE MISSION DECISION

Start where black-box output still forces a human or a fixed fallback.

  • SIGNAL CLASSIFICATION

    A learned classification that cannot explain the blocker

  • DOMAIN VALIDITY

    A model that needs explicit awareness of when conditions have changed

  • PERCEPTION DOMAIN

    A perception stack that needs attributed domain gating

  • MISSION DECISION

    A learned function that still hands every consequential decision back

  • CONTROLLED EVOLUTION

    A model that must adapt to operational change without rebuilding everything

Run an Xpdeep model alongside your existing model for an agreed number of weeks. Compare performance on the same data against agreed KPIs, using your own validation chain.

An Xpdeep model is a PyTorch model with a different architecture. Customers can validate it using their own tools and test processes.

  1. 01 →

    One funded decision

    A model or decision loop the business already owns.

  2. 02 →

    Agreed comparison

    Data, duration and KPIs defined at scoping.

  3. 03 →

    Evidence on your application

    Side-by-side results using the customer’s validation process.

  4. 04

    Define the extension

    Identify the possible Phase 2 scope at the start; use Phase 1 evidence to determine its scope.

Talk to us →Explore Technology →Back to Industries →