Every value in an inspect.software report — components rolled into metrics, metrics rolled into categories, and the overall health index — lives on one standardized 1–100 scale, higher is better. To make those numbers readable at a glance, each value maps to one of five standardized bands, used consistently across health, security, and quality measurements.
What each band means
| Band | Range | Meaning |
|---|---|---|
| Excellent | 85–100 | Exemplary; meets essentially all checked criteria |
| Good | 70–84 | Healthy; minor gaps |
| Moderate | 50–69 | Acceptable with notable gaps; review recommended |
| At risk | 30–49 | Significant weaknesses; adoption warrants caution |
| Critical | 1–29 | Severe problems — e.g. abandoned, single-maintainer, no hygiene |
How bands should be read
- Bands are coarse on purpose. The difference between 71 and 74 is noise; the difference between good and at risk is information. Procurement and review decisions should key on bands and on the category profile, not on single-point differences. The comparison view is built around this: it states the spread between the records on screen in index points, so a three-point gap can be recognized as one and set aside.
- Bands apply at every level. A repository can sit in the good band overall while one category sits in critical — the per-category bands exist precisely so that strength in one area cannot silently mask risk in another.
- Thresholds are versioned. Band boundaries are part of the methodology and only change with a version bump recorded in every report — see methodology versions.
Where the bands appear
The bands drive the color coding across the whole record: catalogue cards, the report gauge, category headers, individual metric cards, and the GitHub badge. A repository with no completed inspection yet shows a neutral pending state rather than a band.
Related: the health index explains how the underlying 1–100 values are computed; signals, not warranties explains what they do and do not claim.