Aggregation Bias Audit¶
Checklist — instantiates Aggregation Function Design and Weighting
A structured checklist that interrogates a finished aggregate for named failure patterns — masking, ecological fallacy, Simpson-style reversals, subgroup erasure, accidental weights, and scale artifacts.
An Aggregation Bias Audit is a fixed list of questions you run against an aggregate someone else already built, each question targeting a specific, named way that summaries mislead. What sets it apart from every sibling here is that it is diagnostic and qualitative: it does not construct a score, choose a statistic, or perturb weights numerically — it inspects a finished number for known pathologies and either clears it or flags exactly which one it exhibits. The checklist looks for the same recurring culprits every time: an average that masks a suffering subgroup, an aggregate whose direction reverses when you split it by a lurking variable, a scale choice that smuggled in an accidental weight, a group whose data was quietly erased. It verifies that the aggregate did not hide what it should have preserved; it does not decide what to preserve or how to weight.
Example¶
A hospital system reports a single "quality score" per facility and celebrates that the network average rose this year. Before publishing, an analyst runs the aggregation bias audit. One item — does the aggregate reverse under a relevant split? — asks her to disaggregate risk-adjusted mortality by patient severity. It does reverse: the flagship hospital looks worse than a community clinic on the raw pooled rate, but within every severity tier it does better — a Simpson-style reversal[n1] driven by the flagship taking the sickest patients. The raw pooled score was punishing it for its case mix.
A second item — did the normalization create an accidental weight? — catches that "patient satisfaction," recorded on a 0–100 scale, was averaged in beside 1–5 measures without rescaling, so it silently dominated the index. A third — does the average mask a subgroup? — surfaces one facility whose overall score is fine while its maternity unit is failing. None of these is visible in the headline number; the audit's whole value is that it forced the look underneath.
How it works¶
- Run the named-pattern list, not intuition. Each item names one failure — masking, ecological fallacy, Simpson-style reversal, subgroup erasure, accidental weight, scale artifact — so the review is systematic rather than dependent on who happens to be suspicious.
- Disaggregate on purpose. For the reversal and masking items, split the aggregate by the subgroups and lurking variables that could flip or hide it, and compare within-group to pooled.
- Interrogate the scale map. Check every input's range and coding for a normalization that handed one variable outsized influence by accident.
- Record a verdict per item. Clear, flag, or "needs rework," with the specific evidence — an audit produces findings, not a fixed number.
Tuning parameters¶
- Checklist scope — how many failure patterns are on the list. A longer list catches more but slows every review and can breed check-the-box compliance.
- Subgroup cut depth — how finely the aggregate is split for the reversal and masking items. Finer cuts expose more hidden variation but hit small-sample noise and can invent false alarms.
- Severity gate — how large a discrepancy must be before an item is flagged rather than noted. A strict gate keeps the audit actionable; a loose one buries the real problems among trivia.
- Cadence — one-time sign-off vs. recurring re-audit. Repeated audits catch drift as inputs change but cost standing effort.
When it helps, and when it misleads¶
Its strength is that it converts a set of well-known but easily-forgotten failure modes into a repeatable gate: because the patterns are named, a reviewer who has never personally been burned by Simpson's paradox still checks for it, and a masked subgroup gets found before the number is published rather than after it does harm. It is the natural last step before an aggregate becomes a public score.
Its failure mode is the checklist's perennial one: it can degrade into ritual, ticked without genuinely disaggregating, giving false assurance precisely because "the audit passed." It is also only as good as its list — a bias pattern not on the checklist is a bias the audit is blind to — and finely-cut subgroups can manufacture spurious "reversals" from noise. The classic misuse is running the audit to certify a number already decided on, cutting subgroups only until one clears. The guarding discipline is to keep the audit adversarial: disaggregate before looking at the headline, treat a passed audit as "no known pattern found" rather than "correct," and revise the checklist as new failure modes are learned.
How it implements the components¶
scale_normalization_map— the audit interrogates the normalization for accidental weights and scale artifacts, verifying that no variable's range or coding silently dominates.tail_visibility_guardrail— its masking and subgroup-erasure items check that the aggregate did not bury a suffering minority or a tail behind an acceptable average.drill_down_path— its reversal and ecological-fallacy items require disaggregating the aggregate into subgroups, comparing within-group to pooled.
It does not implement sensitivity_check — the quantitative perturbation of weights to test ranking fragility is Weight-Sweep Sensitivity Table's core, whereas this audit checks for named qualitative patterns. Nor does it implement weight_assignment_scheme: it inspects an aggregate for hidden weights rather than assigning any, which is Weighted Scoring Rubric's and Ensemble Weighting Table's work.
Related¶
- Instantiates: Aggregation Function Design and Weighting — the audit is the pattern's bias-checking gate on a finished aggregate.
- Consumes: Weighted Scoring Rubric and Dashboard Rollup Formula — it takes their finished aggregates as the object it inspects.
- Sibling mechanisms: Weighted Scoring Rubric · Weight-Sweep Sensitivity Table · Median, Trimmed-Mean, or Quantile Rule · Ranked-Choice or Approval Voting Rule · Ensemble Weighting Table · Dashboard Rollup Formula
Editorial Notes¶
Form Classification¶
Form family: Assessment, Review & Assurance
Rationale: A structured checklist that interrogates a finished aggregate for named failure patterns — masking, ecological fallacy, Simpson-style reversals, subgroup erasure, accidental weights, and scale artifacts, making its operative form a bounded evaluation of existing evidence or work that produces a finding or disposition.
Independent corroboration: The frozen evidence defines Aggregation Bias Audit as 'A structured checklist that interrogates a finished aggregate for named failure patterns — masking, ecological fallacy, Simpson-style reversals, subgroup erasure, accidental weights, and scale artifacts', so its operative form is Assessment, Review & Assurance.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Statistics & Experimental Design
Origin pattern: Single lineage
Present-day reach: Multi-domain
Rationale: The named failures it tests—Simpson reversals, ecological fallacy, masking, weighting, and subgroup erasure—are canonical problems of statistical aggregation and inference.
Related originating lineages:
- Data Science & Analytics — Data-quality and model-audit practice operationalizes these checks over production scores and dashboards.
- Sociology & Anthropology — Social research developed ecological-inference cautions and attention to how pooled statistics erase consequential groups.
Review resolution: Both reviewers agree on statistics as primary and on data science and sociology as formative alternates. The named audit checks are established statistical pathologies applied across domains, so single lineage and no encyclopedia synthesis are the more conservative classifications.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
[n1] Simpson's paradox is the reversal in which a trend that holds within every subgroup disappears or flips when the subgroups are pooled, usually because a lurking variable (here, patient severity) is distributed unevenly across the groups. It is the archetypal reason an aggregate must be checked against its own disaggregation before it is trusted. ↩