Last year’s three is not this year’s three

In 2025 the company rated on four points and averaged 2.49. In 2026 it rates on five and averages 3.29. Nothing improved by 0.8 overnight: the ruler changed, and every chart that ignores that is telling a story about scales, not people.

RuleVersion the scale like any dimension: each rating row keeps its scale, and trends across a change compare percent of scale, never raw averages.

Neverchart raw averages across a scale change. A four-point 2.49 and a five-point 3.29 are not a trend; they are two different rulers.

◆ The break, worked2025 on four points, 2026 on five.

Cycle	Rated	Raw average	Percent of scale
2025, four-point scale	302	2.49	62.3
2026, five-point scale	296	3.29	65.9

The raw averages say performance jumped 0.8 overnight; the scale-normalized view says the real move was 3.6 points of scale. Neither number is on the chart most companies show, because that chart plots the raw averages and calls the jump a great year. Sample values are illustrative, never client data.

◆ The 2025 distribution, on its own rulerwhat the four-point cycle actually said.

Rating, 2025 scale	Workers
4, outstanding	21
3, strong	118
2, solid	152
1, needs improvement	11
Completed reviews, 2025	302

The 2026 distribution lives on the distribution page with its own five bands. Mapping tables that force old fours onto new fives create false precision; the honest join is at percent of scale, with the mapping documented as a choice.

◆ The owned answerthe scale as a versioned dimension.

Every rating row keeps its scale key, and the scale dimension carries each version’s point count and labels. Cross-scale trends normalize explicitly in the query, so the break is visible in the model instead of hidden in a chart.

-- the honest trend across the scale change
SELECT r.cycle_id, s.scale_name,
  COUNT(*)                                   AS rated,
  ROUND(AVG(r.final_rating), 2)              AS raw_avg,
  ROUND(AVG(r.final_rating * 100.0 / s.max_points), 1)
                                             AS pct_of_scale
FROM fct_rating r
JOIN dim_rating_scale s ON s.scale_key = r.scale_key
WHERE r.status = 'Completed'
GROUP BY 1, 2
ORDER BY 1

Use case

Problem

A scale change breaks every rating trend: raw averages jump, old cycles get force-mapped onto the new scale, and history quietly stops being comparable.

What we build

Ratings kept on a versioned scale dimension, trends normalized to percent of scale in the query, and any mapping documented as an explicit choice.

What you get

Trends that survive the redesign: the break visible and labeled, the honest normalized view beside the raw one, and no false precision from forced mappings.

Did a scale change eat your rating history?

We build the versioned scale model that keeps every cycle comparable.

Talk to us

Terms on this page

rating scale: The versioned ruler: point count, labels, validity dates.
scale change: A new scale version; the trend break this page names.
percent of scale: Rating over the scale maximum; the cross-scale unit.
forced mapping: Old ratings recoded onto a new scale; false precision.
versioned dimension: The scale kept with dates, like grades and orgs.