# Error Messages

This page describes the structural format Tensormorph diagnostics follow; it is not an exhaustive catalog of every message the app can produce.

Errors, warnings, and informational diagnostics all surface in the same place - the **Problems panel** - using the same anatomy regardless of which subsystem produced them, so learning to read one diagnostic teaches you to read all of them.

## Anatomy of a diagnostic

-   **Severity** - Error, Warning, or Info, distinguished visually and filterable in the Problems panel.
-   **Source** - which subsystem raised it (the importer, a `ModelAdapter`, a plugin, the Compute scheduler).
-   **Message** - a plain-language description of what went wrong.
-   **Location** - where applicable, a jump-to-node link into the address space (a specific tensor, tile, or module), so clicking the diagnostic takes you directly to the affected region the same way `F8` steps between flagged anomalies.

## Common categories

-   **Import/parse errors** - a checkpoint file is malformed, or references external data that can't be found (see [Working with Models](/docs/working-with-models/safetensors)).
-   **Adapter warnings** - an architecture wasn't recognized by a specific `ModelAdapter` and fell back to the generic adapter (see [Model, Architecture, Layer and Module](/docs/core-concepts/model-architecture-layer-module)); not an error, since the model still opens, but worth knowing about.
-   **Data-quality flags** - NaN/Inf detections and statistical outliers (see [NaN and Inf Detection](/docs/inspect-and-analyze/nan-and-inf-detection)), which use the Problems panel as their home even though they aren't errors in the traditional sense.
-   **Backend/compute errors** - a requested operation isn't supported on the currently selected backend and had to fall back (see [GPU Backend Compatibility](/docs/reference/gpu-backend-compatibility)).
-   **Plugin errors** - an exception raised inside a plugin's sandboxed execution, attributed to that plugin rather than to Tensormorph's core.

## Diagnostics as CI signal

The same diagnostics produced interactively are what [CI Validation](/docs/cli-and-automation/ci-validation) checks for when run headlessly - a non-zero exit code from a validation run corresponds to one or more Error-severity diagnostics, so a CI failure always has a matching entry you can reproduce by opening the same checkpoint locally.

## Related resources

-   [NaN and Inf Detection](/docs/inspect-and-analyze/nan-and-inf-detection) - the most common data-quality diagnostic category.
-   [CI Validation](/docs/cli-and-automation/ci-validation) - running diagnostics headlessly as a pipeline gate.
-   [GPU Backend Compatibility](/docs/reference/gpu-backend-compatibility) - backend-related fallback diagnostics.