Methodology
How the Proof Score is calculated
The full arithmetic behind the Proof Score: what each finding deducts, which WCAG and CIEDE2000 thresholds it is judged against, and where every number comes from.
6 min read
The Proof Score is a single number out of 100 describing how well a palette will hold up in a real interface. It exists to be quoted — pasted into a pull request, put on a slide, argued with in a design review. That only works if anyone can check it, so this page is the whole calculation.
Every number below is read directly from the code that computes the score. They are not transcribed into this page by hand. A published methodology that has drifted from the implementation is not a weaker claim than publishing nothing — it is a falsifiable one, and the entire value of the score is that it survives being checked.
It starts at 100, and findings deduct
There is no model and no scoring curve. Each rule that fails contributes a fixed deduction according to its severity, and what remains is the score:
| Severity | Meaning | Deducts |
|---|---|---|
critical | Someone will be unable to use this — unreadable text, an invisible control. | −22 |
warning | It works, but it will cost you — strain, ambiguity, or maintenance. | −9 |
info | Worth knowing about. Not a defect. | −3 |
So a palette with one critical and two warnings scores 100 − 22 − (9 × 2) = 60. The Palette Doctor shows this arithmetic line by line for your own palette, with each deduction named.
The score is floored at zero but the deductions are not. A palette can accumulate more than 100 points of problems, and if it has, fixing one finding will not move the number until the total drops back under 100. That is stated explicitly rather than left to look like a stuck tool — two palettes both showing 0 are not equally broken.
What counts as a problem
The thresholds are borrowed, not invented. Colour science already has published, defensible answers for “can this be read” and “are these the same colour”, and inventing new ones would mean asking you to trust us instead of the standards body:
| Threshold | Value | Source |
|---|---|---|
| Body text | 4.5:1 | WCAG 2.2 SC 1.4.3 (AA) |
| UI shapes and boundaries | 3:1 | WCAG 2.2 SC 1.4.11 |
| Same colour | ΔE < 2.3 | CIEDE2000 just-noticeable difference |
| Nearly the same colour | ΔE < 5 | CIEDE2000 |
Contrast is measured between the colours that are actually on screen together — the page against its body text, not the lightest swatch against the darkest. A checker that pairs two colours which never touch reports a ratio nobody will ever experience, and it will usually report a flattering one.
What the number means
| Score | Verdict |
|---|---|
90–100 | This palette is in good shape |
70–89 | Usable, with a few things worth fixing |
45–69 | Some real problems here |
0–44 | This palette will cause trouble in production |
What the score deliberately does not do
- The score starts at 100 and each finding deducts by severity. It is a sum of known checks, not a model's judgement.
- Repairs move lightness and chroma in OKLCH. Hue is never rotated, so a repaired palette keeps its identity.
- Every number here is reproducible offline: same palette in, same report out, with no request made.
It also does not judge taste. Nothing here has an opinion about whether your palette is attractive, on-brand, or fashionable — those are real questions and this is not a tool that can answer them. It answers the narrower question of whether the palette will work, which happens to be the one that has measurable answers.
Why this page is free
The arithmetic, the weights and the thresholds are free and always will be. A scoring formula behind a paywall is a black box to precisely the people whose trust the number needs before they will repeat it, and a number nobody repeats is worth nothing to us either. Pro buys the artefacts — the one-click repair, the semantic tokens, the committable audit report — never the right to check the maths.