Definition
A score band is a named interval that converts a numeric assessment result into an interpretation and action. Score band validation checks that those intervals and their recommendations behave consistently across normal, extreme, and borderline cases.
Method and evidence
Checklist created and executed on August 24, 2026 against a four-band 0 to 100 model. Test values included 0, 39, 40, 64, 65, 79, 80, and 100, plus conflicting weighted profiles and missing data.
Evidence type: Twelve-case threshold stress test with worked scores. See the publication methodology and correction path.
Start with unambiguous band notation
Use intervals that state exactly where a boundary score goes. One reliable convention is lower bound inclusive and upper bound exclusive, except the final band includes the maximum. In shorthand: [0,40), [40,65), [65,80), and [80,101).
In visible copy, write 0 to 39, 40 to 64, 65 to 79, and 80 to 100. In platform rules, confirm whether an upper value is inclusive. Rule engines use different conventions.
Sources: SAP score-band range example
The 12-test validation checklist
Record the input, expected output, observed output, and pass or fail result for every case. Repeat the set after changing a weight, question, threshold, or override.
| Test | Input | Expected result |
|---|---|---|
| 1. Minimum | All lowest answers | Lowest band, no negative score |
| 2. Maximum | All highest answers | Highest band, score does not exceed 100 |
| 3. Lower edge | 39 | Final value in the first band |
| 4. First threshold | 40 | First value in the second band |
| 5. Middle edge | 64 | Final value in the second band |
| 6. Middle threshold | 65 | First value in the third band |
| 7. Upper edge | 79 | Final value in the third band |
| 8. Upper threshold | 80 | First value in the fourth band |
| 9. Missing answer | One blank required value | Declared error or documented fallback |
| 10. Conflicting dimensions | High total, one critical low | Override or limitation behaves as designed |
| 11. Rounding | 64.5 and 79.5 | Rounding occurs at the declared stage |
| 12. Recommendation | One case in each band | Different, appropriate next action for every band |
Worked formula test with weighted dimensions
Use five dimension weights of 25, 20, 20, 20, and 15. A response profile of 3, 4, 2, 3, and 2 on a 0 to 4 scale produces 18.75 + 20 + 10 + 15 + 7.5 = 71.25. That maps to the 65 to 79 band.
Now lower the second value from 4 to 3. The result falls by 5 points to 66.25 and stays in the same band. Lower it to 2 and the total becomes 61.25, crossing into the prior band. The recommendation should change at the threshold and still make sense for the underlying profile.
Test rounding before band assignment
Choose whether the rule engine assigns a band from the raw score or a displayed rounded score. A raw 64.5 can display as 65 while still landing in the 40 to 64 band if assignment happens first. That looks like an error to the respondent.
The safer pattern is to keep sufficient precision during calculation, apply the documented band rule, and display a value that cannot contradict the band. If whole numbers are required, define the rounding stage and test values ending in .49 and .50 near each boundary.
How do you stress-test critical-gap overrides?
Create a profile with the highest possible values everywhere except the critical dimension. Confirm that the cap or alternative routing applies. Then test the exact value that removes the cap.
The result page should explain the critical gap instead of displaying a lower band with no reason. The stored contact record, email branch, booking rule, and exported score should all use the same final band.
Review borderline cases as a separate sample
Thresholds deserve more attention than scores in the middle of a band because a small arithmetic change can alter the recommendation. Review real or expert-created cases within one or two points of each boundary. Ask whether the two neighboring interpretations are both defensible.
LSE guidance for assessment sampling identifies marks around band boundaries for additional review. A client-facing diagnostic is not an exam, but the same quality-control principle is useful: examine the cases where the decision changes.
Sources: LSE guidance on borderline band sampling · How we test assessment tools
What to record for future maintenance
Keep a validation log with the model version, question set, weights, formulas, ranges, overrides, test inputs, observed outputs, and reviewer notes. Re-run the log after any scoring change. When enough suitable real cases exist, compare band assignments with expert judgment and revise unstable thresholds.
Do not refresh a validation date unless the tests were actually repeated. A visible date should describe a real review, not a publishing ritual.
- Model and question version
- Weight and formula definitions
- Inclusive and exclusive boundary rules
- Override order
- Twelve test inputs and outputs
- Borderline review notes
- Date and scope of the last rerun
Practical next step
Copy the framework or checklist into a draft, run every stated test case, and record the observed result before publishing. Recheck changing product capabilities and plan limits against the linked vendor page.