Known limitations.
Routescore is useful only if it shows what it does not know. This page is the public checklist for score states, unsupported coverage, source freshness, calibration limits, and non-execution boundaries.
A weak link should change the state
Inputs are supported and fresh enough to show normally.
One or more sources are delayed, missing, or partial.
Output is useful, but some components are unavailable.
Freshness threshold was exceeded; do not treat as current.
The route, asset, chain, or protocol is outside coverage.
A critical dependency failed; no score should be inferred.
What the product should not overclaim
Scores are point-in-time
Quotes, detector signals, and freshness checks can change after a response is generated. A score is evidence for a decision record, not a standing guarantee.
Unsupported coverage stays unsupported
Unsupported tokens, chains, bridges, routes, or wallet assets are not inferred. Routescore should return unsupported, partial, degraded, stale, or unavailable states instead of hiding gaps.
Risk categories stay separate
Execution quality, bridge risk, oracle risk, contract risk, yield risk, and alert risk are different problems. A single score must not hide a separate critical risk.
Calibration needs live evidence
Internal Brier, ECE, and model-quality reports are not public performance claims until enough reviewed labels, live quote samples, and methodology checks exist.
APIs and MCP do not execute
The REST API and MCP server return decision-support evidence. They do not custody assets, route funds, broadcast transactions, or recommend financial actions.
Commercial influence is disclosed
Paid placement, protocol influence, partner-provided data, or score overrides must be disclosed and kept separate from scoring methodology.