AEROSPACE & DEFENCE

Make mission-critical learned models understandable from within.

Consequential aerospace and defence models must be diagnosed, qualified and evolved, not only trusted. Xpdeep makes their learned structure readable and their domain of validity explicit, so the customer can decide which roles a model may carry and under which conditions.

THE SURROUNDING SYSTEM STAYS IN CONTROL

01 UNDERSTANDABLE BEHAVIOUR

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.

KNOWN MISSION STATE
INSIDE KNOWN CONDITIONS
GRADED DOMAIN DISTANCE
BOUNDARY APPROACH
APPROACHING DOMAIN EDGE
GRADED DOMAIN DISTANCE
Attributed to: one variable, last temporal window
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

On signals, the learned structure can show what the model relies on.

02 SIGNALS · WHAT STRUCTURAL ACCESS ENABLES

STRUCTURAL DIAGNOSIS: Read which variables, signal segments and time windows the learned model relies on, and where its structure diverges from engineering expectations.
TEMPORAL UNDERSTANDING: Locate the temporal patterns behind a classification or platform-state estimate, instead of inferring them from outside the model.
MODEL ENGINEERING: Use that evidence to direct dataset, architecture and input decisions during design, and to scope corrections later.

XPDEEP OPERATES DOWNSTREAM OF THE DIGITIZED SIGNAL

Illustrative signal, not programme data. Xpdeep does not supply radar or RF front ends, sensor hardware or the signal-acquisition chain.

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

03 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. Novel-class detection applies to classification tasks. Domain awareness does not authorize mission action.

04 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.

05 BOUNDED DECISIONS

Where a model carries a decision, it should do so only while the conditions remain explicit.

Where customer engineering justifies it, a learned function can carry a bounded mission or platform decision. Model-level evidence is one input; the customer defines mission policy, permitted actions, fallback and system-level safety requirements.

CONDITIONAL AUTHORITY

CUSTOMER-DEFINED PERMITTED AUTHORITY
The mission system sets which decisions may be delegated, and the limits.
CONDITIONAL USE WITHIN THAT AUTHORITY
The model output is used only while its attributed domain state meets the customer’s conditions.
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.

Domain awareness does not set mission policy or authorize action, and Xpdeep does not define system-level safety.

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

The customer may measure exception-handling workload, expert attention and response time against its own baseline. These are potential operational outcomes, not established Xpdeep results.

CONDITIONAL MISSION AUTHORITY

Authority can expand or contract with the mission state.

CONDITIONAL AUTHORITY

STATIC AUTHORITY LIMIT
→
MISSION STATE + DOMAIN STATE
→
CONDITIONAL AUTHORITY
→
ACT / HOLD / ESCALATE
→
FALLBACK PRESERVED

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

06 EVOLUTION

NATIVE MODE.

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

OPERATIONAL FEEDBACK
→
STRUCTURAL DIAGNOSIS
→
TARGETED CORRECTION · REST FROZEN
→
VALIDATION
→
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.

07 QUALIFICATION AND OPERATIONAL EVALUATION

What the customer qualifies, and what is publicly stated.

RELEVANT DATA AND MODEL TYPES

Digitized RF and other signals downstream of acquisition
Multivariate temporal and platform-state data
Mission and platform-system data
Learned perception models where applicable

WHAT THE CUSTOMER MEASURES OR VALIDATES

Model behaviour against its own technical and mission criteria
Domain coverage and handling of unfamiliar or novel conditions
Any change to margins, intervals, redundancy or delegation, through its qualification and airworthiness processes
Operational evaluation of the surrounding mission system

PUBLISHABLE EVIDENCE AND MATURITY

DEFENCE: Xpdeep is engaged in defence programmes. Specific applications and results are confidential.
AEROSPACE RESEARCH: Xpdeep has taken part in aerospace-related work within the Confiance.AI programme.
MODEL-LEVEL CAPABILITIES: Structural explanation, attributed domain awareness and novel-class detection for classification tasks are available model-level capabilities. Core engines and single-model MCP / API access are live.
NOT CLAIMED: Mission autonomy, operational effectiveness, system safety or qualification established by Xpdeep.

Deployment on embedded platform compute or on-premises, customer-controlled infrastructure. Access restricted to EU, EFTA, NATO member and other compatible countries.

See platform status →

Mission-critical engineering boundaries.

EXPAND

Xpdeep does not supply radar front ends, sensors, avionics stacks or tactical command systems.
The customer defines mission policy, permitted actions, fallback and system-level safety requirements.
Model-level evidence supports, but does not constitute, system-level qualification or operational evaluation.
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 FUNDED PROBLEM

Start with one funded learned-model problem and an agreed success criterion.

LEARNED MODEL
A model whose behaviour must be diagnosed or understood before it can progress
SIGNAL ANALYSIS
A signal-classification or temporal-analysis problem with an agreed technical criterion
DOMAIN VALIDITY
A model that needs explicit, attributed awareness of when conditions have changed
PLATFORM STATE
A platform-state estimate that engineering must characterize and qualify
PERCEPTION
A learned perception model that needs domain analysis
MISSION FUNCTION
A mission function with an agreed technical, operational or mission-related success criterion

Operational delegation is not an entry condition.

Phase 1 is a funded engagement, typically three to six months, on a consequential model, decision, function or programme you have prioritized. Agree the economic, operational, quality, mission, product or assurance success criterion at scoping; work on your data within your engineering environment and constraints.

Xpdeep supplies model-level technology and repeatable software deployment, not a replacement engineering lifecycle. Your teams and implementation partners can integrate and validate the model using your own tools and test processes.

01 →
One funded problem
A model, engineering problem, product function, subsystem or decision the business already owns.
02 →
Agreed criterion
Data, duration, success criterion and validation method defined at scoping.
03 →
Evidence on your application
Results assessed through the customer’s validation process; a side-by-side model comparison is one possible method.
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 →