Knowing when the model has left what it learned

A confidence score says how strongly the model favours an output. Attributed domain state addresses another question: how does this input relate to what the model learned? A model can be confident on an input it has never seen anything like.

Domain state is reported separately from prediction confidence. How it fits into the full output is described in The integrated decision object.

The distinction matters when an engineer is investigating changed behaviour. A strong preference for an output does not explain whether the input resembles the conditions represented in the learned domain. Looking only at confidence can therefore leave the change in input unexamined. Domain state supplies another view of that input, rather than a replacement confidence score.

It is also different from the structural explanation of the prediction. Explanation concerns the learned structure carrying an output; domain state concerns the input's relation to what was learned. An engineer can examine both without treating either as a verdict on the system's action.

A graded indication describes how far an input has moved from the learned domain, rather than reducing every input to the same binary label. On temporal data, that is a graded distance to the trained domain. Domain awareness also covers novel-class detection: recognising an input that belongs to none of the classes the model learned.

Attribution adds a second dimension to the investigation: where is the departure carried? Instead of only observing an overall indication, engineers can examine the responsible variables and time windows on temporal data. The usefulness lies in focusing the review, not in declaring that a changed input must be rejected.

Domain awareness covers the model's input variables. Variables removed by input reduction are outside that model-level view and, where safety-relevant, must be monitored at system level.

Where a coverage guarantee is required, conformal prediction can be composed on top. It assumes deployment data resemble calibration data, an assumption that may fail outside the defined operating domain.

On temporal data, Xpdeep returns a graded distance to the trained domain and attributes the departure to the variables and time windows responsible. Engineers see where the input moved, not only that it moved.

A practical review starts by locating the attributed windows and variables in the recorded input. Compare those portions with the operating context and with the data used to assess the model. The question is what changed and whether the customer's evaluation covers it, not whether one number can settle the case.

That review can direct attention toward measurement issues or a changed operating condition. These are investigation questions, not diagnoses delivered by domain state. The engineer needs other evidence to distinguish a data problem from a meaningful change in the physical system. Attribution does not establish causality.

Keep the temporal context. A variable can depart in one window without making every occurrence of that variable problematic. Conversely, reviewing a whole-record average can conceal the part that deserves attention. What signal-level explanation means develops the complementary question of which temporal structure carried a particular output.

For image and video, the scope is structural explanation, attributed domain state and design-loop capabilities. There is no image-level prescription.

The engineering distinction still applies: the structure associated with an output and the input's relation to the learned domain answer different questions. Use that distinction when reviewing a vision case rather than assuming a visually plausible output establishes that the input is represented by what the model learned.

For the difference between a visual saliency check and structural model inspection, read Why a heatmap is not a model explanation.

An unusual condition is not automatically invalid, and an in-domain input is not automatically safe to act on. The customer's system rules decide what happens: act, hold or escalate.

Domain state is not an authorization to act or a system-safety guarantee. A customer may need to investigate an unusual but legitimate condition, and may need to hold an apparently familiar input for reasons outside the model. Engineering constraints and other system evidence remain relevant.

To assess the capability, identify what evidence a departure would prompt the team to review, which conditions the evaluation covers and how the system handles exceptions. The goal is a clearer investigation and an explicit customer decision, not a universal rule that domain state can supply on the customer's behalf.