Your catalogue labels columns Public, Internal, Confidential and Restricted, and propagation takes the maximum label of all inputs. A team joins a Restricted table of health claims to an Internal table of postcodes and publishes weekly counts by postcode and condition. What does the label say, what should it say, and what goes wrong with the rule?

What the rule produces

Maximum propagation labels the output Restricted, and the aggregate is now handled with the controls of raw claims data. That is defensible and it is where the trouble starts.

Every derivative of a Restricted table is Restricted, so within a year most of the estate carries the highest label. The controls that attach to it — approval to query, no export, restricted tooling — are then applied to data that mostly does not need them, and people respond predictably: they copy data into somewhere unlabelled, because the legitimate path has become unusable. Over-classification produces less control, not more.

What the label should say, and why it is not simpler

An aggregate is genuinely less sensitive than its inputs, but not automatically safe. Weekly counts by postcode and condition can identify individuals directly: a postcode with one case of a rare condition is a disclosure, and differencing two weeks' releases can recover an individual even when each release looks harmless.

So the honest label depends on a measurable property, not on lineage: what is the minimum cell count in the published output, and can successive releases be differenced? A rule of thumb used across statistical disclosure control is to suppress any cell covering fewer than 5 users, and to fix the geography so the same cells are published each period. Differencing between releases was formalised in the differential privacy literature from 2006 onward, and the practical defence is older than that: publish the same cells every period or none.

What a working rule looks like

1. Propagate maximum by default, because a default must be safe.
2. Allow an explicit, reviewed downgrade when the output passes a stated test: minimum cell size, no free-text column, suppression applied to small cells, geography fixed between releases.
3. Record the downgrade with its evidence and an owner, so it is auditable and revisitable.
4. Alert on the aggregate metric, not on the label: if the minimum cell count in a published table drops below the threshold after a data change, the downgrade is no longer valid and the table should stop publishing.

When not to build a downgrade path

Small estates with few Restricted sources, where almost nothing is derived from them: the downgrade process would cost more than the friction it removes. It is also right where the regulator has said so — some health and financial regimes do not accept derived-data downgrades without formal disclosure control sign-off, and there the correct answer is to route the release through that process rather than to design a rule of your own.

Common weak answers

• "Label by table, not by column." Coarser labels accelerate over-classification.
• "Anonymise it." An aggregate is not anonymous by construction; the claim needs a test, a threshold and a suppression rule.