A Model or Binding Isn't Running
A model that won't run almost always fails because of something feeding it, not the model itself. The fastest path to the root cause is to work down the chain: model, then bindings, then the tags each binding reads, then the devices those tags live on. This page follows that order.
Koios records three diagnostic fields (error code, error message, error detail) at both the model level and the binding level. For how those fields behave, how errors auto-clear, and the full status and quality legend, see Reading Status, Quality & Errors. This page focuses on what the model and binding error codes mean and how to act on them.
Start with the Bindings Tab
When a model fails, the model-level error is often generic — it tells you the model couldn't run but not which input caused it. The binding-level errors tell you the actual cause: a disabled tag, a missing range, stale history, an on-demand read timeout.
Where each error appears:
- Model detail, Overview tab — the status hero shows the current state. When the model is Failed, a red strip below the status shows the model error message and detail.
- Model list — each model shows a colored status icon. Hover the red icon to read the error message.
- Bindings tab — every input and output binding is a card with a colored left border. A failed binding turns red and expands to show its error message and detail inline. This is the diagnostic view that points at the specific binding that broke the model.
How the Inference Pipeline Runs
Reading the pipeline order helps you read error codes: the code tells you which stage failed. Each inference cycle runs these steps, stopping at the first failure:
- Validate bindings — each input tag is assigned, enabled, and running
- Query history — fetch historical data from the time-series database
- Preprocess — interpolate, check ranges, normalize, assemble the input tensor
- Run inference — execute the ONNX or TFLite model
- Write results — de-normalize predictions, check output ranges, write to output tags
For the exact tensor shapes, input depth, and normalization rules the preprocess and inference steps depend on, see Model Inference Requirements.
Model Error Codes
These apply to the model as a whole. When you see one, check the bindings for the more specific cause. An error code of 0 (None) means no active error.
File errors
Load / binding errors
Inference errors
System errors
Binding Error Codes
These apply to individual input or output bindings and are the most actionable diagnostics. A binding can fail at any pipeline stage; the groups below follow the chain from tag state outward. Code 0 (None) means the binding is healthy.
Tag-state errors — fix at the tag or device, not the model
On-demand read timeout
Historical-depth and staleness errors — the tag works, the history doesn't
If a binding shows Stale History Data but the tag itself looks live, the gap is in historization, not collection. See Data Is Stale, Frozen, or Has Gaps.
Range, normalization, and calibration errors
Rate-of-change error
Data-structuring errors
Output and write errors — after inference
Other
Common Scenarios
All inputs show "Tag Disabled"
Every input binding is code 11. The model depends on tags that have been stopped, individually or because their parent device was disabled. Re-enable the tags or the device.
All inputs show "Not Enough Historical Depth"
Normal right after enabling a model or restarting a device. Wait for the device to complete enough scan cycles to fill the window (depth × sample rate). No action needed.
One input shows "Upstream Model Failure"
That binding reads a tag written by another model's output, and the upstream model is failing. Fix the upstream model; this binding recovers on its own.
Running, but an output shows "Value Out of Range"
Inference produced a prediction that exceeded the output's failure bounds. Likely causes:
- Input data has drifted outside the range the model was trained on
- Failure bounds are set too tightly for the expected output
- The normalization range doesn't match the training data's range
Review the output binding's failure range on its Configuration tab.
"On-Demand Read Failed"
The model or its scan group is on-demand, but the device didn't answer in time. Confirm the device is powered and reachable (see Troubleshoot a Connection), then confirm the On-Demand Timeout covers the batch window plus device read time. See On-Demand Scanning.
"Input tensor shape mismatch"
The number of input bindings doesn't match what the model file expects, usually after uploading a file with a different architecture. Reconcile the bindings on the Bindings tab to match the new input/output structure. See Model Inference Requirements.
A scan group fails and every model in it shows "On-Demand Read Failed"
When a scan group's shared on-demand read fails, all models in the group fail together. The group-level error (On-Demand Read Failed, scan-group code 2) appears on the scan group's detail page. Fix the shared device connection; every model in the group recovers on the next cycle. For scan-group health more broadly, see Service Health & Resource Alarms.
If a Model Stays Stuck
Errors clear automatically once the next inference cycle succeeds — no manual acknowledgment. If a model won't recover:
- Read the Bindings tab for per-binding errors; they are more actionable than the model-level error.
- Set the model's log level to Debug on the Logs tab and watch each pipeline stage.
- Confirm every input tag is enabled and running — one disabled or failed tag blocks the whole model.
- Check the tag devices — a down device fails all its tags, which cascades to every model using them.
- Toggle the model off and on with the Enabled switch.
If none of that clears it, gather logs before opening a ticket. See Collecting Diagnostics for Support.
What's Next
- Reading Status, Quality & Errors — the shared error-field reference, status/quality legend, and stuck-error checklist
- Model Inference Requirements — input/output tensor shapes, input depth, normalization
- On-Demand Inference — model-side on-demand cycle and timeout
- On-Demand Scanning — device-side freshness and batch-window latency
- Bad, Missing, or Frozen Tag Values — when a binding's tag is the problem
- Data Is Stale, Frozen, or Has Gaps — when history is stale but the tag is live
- Troubleshoot a Connection — when the device feeding a tag is unreachable
- Service Health & Resource Alarms — scan-group and predict-engine health
- Licensing Problems — the Unlicensed (999) code
- Collecting Diagnostics for Support — what to gather before a ticket
