Quality Bands
Tune the cutoffs that classify Risk Score, Documentation Coverage, and Test Case Health for a product, so the Quality dashboard reflects your product's tolerance rather than a generic default.
Why change the bands
The defaults are tuned for a typical business application. A payments ledger, a medical device portal, or an authentication service is not typical. On those products a risk score of 30 is not "low" — anything above 15 warrants review — and 70% documentation coverage is a gap, not a pass.
Bands change how a number is classified and coloured. They never change how the number is calculated, so scores stay comparable against a product's own history after you retune.
Where to set them
Go to Configurations → Quality Bands and pick the product from the filter at the top of the page. Each metric is one row, pre-filled with the value currently in effect.
- A row shows default 30 / 60 while it is untouched, meaning it is tracking the framework default and will follow if that default ever changes.
- Once you save, the row is marked Overridden and a Reset to Default button appears.
- Each row prints the bands your two numbers produce — for example
Low ≤ 15 · Medium ≤ 40 · High > 40— so you can see the full classification before leaving the page.
Setting bands is an admin action. Non-admin users see a note that bands are administrator-managed rather than the values themselves.
The three metrics
You set two cutoffs per metric. The third band is whatever falls outside them, which is why there is no way to configure a range that no value can land in.
| Metric | Direction | Cutoffs you set | Defaults |
|---|---|---|---|
| Risk Score | Lower is better | Low, Medium | Low ≤ 30 · Medium ≤ 60 · High > 60 |
| Documentation Coverage | Higher is better | Green, Amber | Green ≥ 70 · Amber ≥ 40 · Red < 40 |
| Test Case Health | Higher is better | Green, Amber | Green ≥ 70 · Amber ≥ 45 · Red < 45 |
Boundaries are inclusive. With Low set to 15, a risk score of exactly 15 is Low and 16 is Medium. With Green set to 85, coverage of exactly 85% is Green and 84% is Amber.
Worked example
A team shipping a critical product wants low risk to mean 15 or under, and coverage to be green only at 85% or above. In Configurations → Quality Bands they set:
| Metric | First cutoff | Second cutoff |
|---|---|---|
| Risk Score | Low = 15 | Medium = 40 |
| Documentation Coverage | Green = 85 | Amber = 60 |
A scenario scoring 22 that previously displayed as Low risk now displays as Medium, and a suite at 78% coverage that previously showed green now shows amber. Every other product is unaffected — bands are per product, and a product you have not configured behaves exactly as it did before.
What the validator rejects
Because the two cutoffs are related, they are saved together and checked as a pair. An invalid pair is rejected with an inline error rather than being quietly adjusted:
- Cutoffs outside 0–100.
- Values that are not whole numbers.
- Cutoffs in the wrong order — Low must be below Medium; Green must be above Amber. Saving
Low 50 / Medium 20is refused, because it would describe a band nothing can fall into.
Effect on release gates
The Documentation Coverage release gate takes its floor from the same band you configure here, so the Quality dashboard and the release gate cannot disagree about what "good coverage" means for a product.
An explicit gate value always wins. If a release gate's Documentation Coverage floor has been set directly on the Release page, that stored value is kept and the band does not override it. Note that saving the release gate form stores every field, so after one save the floor becomes explicit and stops following the band. Clear it there if you want it to track the band again.
Storage
Overrides are written to the product's configuration file under run_config.quality_bands. Only metrics you actually changed are stored, so an untouched metric keeps tracking the framework default.
run_config:
quality_bands:
risk_score:
low: 15
medium: 40
doc_coverage:
green: 85
amber: 60
Editing this file by hand is not the supported path — the dashboard validates a pair before writing it, and a hand-edited invalid pair is ignored in favour of the defaults rather than applied.
Limits
- Bands are per product. There is no per-environment or per-domain scoping.
- Band names and colours are fixed. Low/Medium/High and Green/Amber/Red cannot be renamed or recoloured.
- The weighting inside the risk score is not configurable — only the cutoffs that classify the result. Reweighting would change what the number means and break comparison against a product's own history.
- The Quality page with no product filter aggregates every product, and falls back to the framework defaults for that combined view.
Related
- Config Reference — all other configuration fields
- Environments — per-environment run settings