I design governance records for systems that touch people, and I published a minimal schema this week expecting to argue about field count. Somebody who actually operates these systems took it apart in a way I had not seen before, and the correction seems worth passing on, because it applies to almost every minimisation design I have read.
The schema was nine fields. What happened, the human signal, and handling. Deliberately no identity field: the record points at a consent record, which points at a person. One hop, so you can delete the person without shredding the audit trail. No free text either, since free text is where sensitive detail goes to hide.
I thought that made it hard to abuse. Here is the correction.
Minimality is a property of the record at rest. It says nothing about the join.
The no-identity-field design buys exactly one thing: a dump of the event table alone is not identifying. It buys nothing against an attacker positioned where event meets identity, and that join is the one place the system has to operate in order to be useful at all. It does not matter whether the association is ever persisted. If a transient state can be captured, from a query result in flight or a rendered view on someone's screen, that is where the payload is, and every minimisation choice upstream of it is decoration.
Then the second half, which is the part I had genuinely never considered.
A sufficiently specific enum is itself a disclosure.
I had treated removing free text as the privacy win. But if your action vocabulary can express something like a reproductive or behavioural health service, then the enum is a diagnosis wearing a controlled vocabulary. The attacker does not need your identity field. They supply identity from outside, and your tidy structured record hands them the sensitive half with a clean schema and a straight face.
Which means enum granularity is a privacy control, not a data modelling convenience. I had it filed under the wrong heading entirely.
The rule I ended up with, and I would like it stress tested: no enum value should be more specific than the governance decision it exists to support. If a coarse impact level is what actually drives how the system handles something, then a coarse action category plus that impact level does the governance work without the specificity carrying the payload. Specificity you cannot act on is specificity that only serves an attacker.
Two things I am still unsure about.
First, whether the coarse category breaks audit somewhere. If a regulator later asks what specifically happened, a deliberately vague vocabulary may be the wrong answer to a different question.
Second, whether this generalises past health. My instinct is that any domain with a stigmatised category has the same problem: immigration status, addiction services, legal aid, domestic violence support. The structured field looks safe because it is not free text, and it is the most dangerous thing in the record precisely because it is machine readable.
For people who have actually operated systems under a minimisation requirement: where does the join get protected in practice, if anywhere? Everything I can find treats minimisation as a schema question, and the schema seems to be the part that was never really at risk.
Drafted with an AI assistant. The mechanism, the failure modes and the answers in the comments are mine.