The arithmetic was correct. The grain was wrong.

One region in an application showed 534. The source dashboard showed 975.

The app added a plus marker, as if 534+ made the disagreement honest. It did not. The product label said the number represented the published regional total. The published number was 975.

The code had no addition bug. It summed every exact detailed row it could see. The problem was that many detailed cells were censored as <20, while the source published an exact total at a coarser grain.

The arithmetic was correct. The grain was wrong.

Grain is part of the meaning

Suppose detailed rows exist at this grain:

month x region x status x category

Some cells are exact and some are censored:

06/2026 | SOUTH | INVITED | A | 210
06/2026 | SOUTH | INVITED | B | <20
06/2026 | SOUTH | INVITED | C | 324
06/2026 | SOUTH | INVITED | D | <20

Summing exact rows gives 534. That is a lower bound on the detailed total. It is not the exact regional total.

The source separately publishes:

06/2026 | SOUTH | INVITED | 975

at this grain:

month x region x status

The coarse row carries information the detailed export intentionally removed. Once cells are censored, aggregation is no longer reversible.

A plus marker cannot repair a false label

If the product claim is “sum of visible exact category rows,” then 534+ is defensible. If the claim is “published regional total,” and the source publishes 975 at regional grain, then 534+ is the wrong metric with an honest qualifier.

This distinction belongs in the model:

type PublishedCount =
  | { kind: 'exact'; value: number }
  | { kind: 'censored'; source: `<${number}` }
  | { kind: 'floor'; value: number; omittedCells: number }

type RegionalStanding = {
  detailedFloor: PublishedCount
  publishedTotal: PublishedCount | null
}

The regional headline uses the coarse exact total. The category board keeps the detailed floor. One must not overwrite the other.

Store the grains separately

The original pipeline ingested only the detailed export. The source made the coarser table visible when one dimension was removed, but the scraper never captured that view. No seed could load rows that did not exist in the parsed artifact.

The repair used a separate table keyed at its real grain:

create table regional_totals (
  as_at_month text not null,
  population text not null,
  status text not null,
  region text not null,
  item_count integer,
  masked boolean not null default false,
  unique (as_at_month, population, status, region)
);

Putting both grains in one table with a nullable category would require every query to remember that category is null changes the semantic level. Separate tables make the illegal aggregation harder to express.

Validate across grains

The datasets should not be forced to equal. They do have one useful invariant:

coarse exact total >= detailed exact-only floor

function assertCoarseTotalCoversDetail(coarseExact: number, detailedFloor: number) {
  if (coarseExact < detailedFloor) {
    throw new Error(`Coarse total ${coarseExact} is below detailed floor ${detailedFloor}`)
  }
}

This catches mismatched months, populations, statuses, duplicates, and many parser mistakes without pretending censored rows can be recovered.

The runnable aggregation-grain data contract models censored cells as intervals and tests the cross-grain invariant.

The ETL test is also a product test

Once the grains were explicit, the pipeline gained product-level checks:

• coarse input is not empty
• keys are present and unique at the declared grain
• exact counts are non-negative integers
• masked rows do not carry invented values
• coarse exact totals cover detailed floors
• the newest period exists after loading

The original code answered, “What is the sum of exact category cells available to me?” The card claimed, “What exact total did this region publish?”

Those are different questions. No amount of correct arithmetic can make them the same. When two dashboards disagree, compare dimensions before values.