Custody is not visibility

Somebody has to hold the room. When a group has a shared container, a therapeutic space, a cohort, a family archive, one party carries the duties that only make sense at the level of the whole thing. Concluding it. Suspending it. Answering when a member leaves and something has to be done about what they left behind. Initiating erasure when erasure is owed. That party is the custodian, and the question almost every schema answers wrongly is what else the role comes with.

European data law has held the two powers apart for years without anyone calling it an architecture. Article 29 of the General Data Protection Regulation says that a processor, and any person acting under the authority of a controller or processor who has access to personal data, shall not process those data except on instructions from the controller. Access and entitlement are treated as different facts about the same person. Holding the material is a position; reading it is an act that needs its own authorization, and the law declines to let the first imply the second.

Software collapses them constantly, and usually by accident rather than by decision. There is no column for the custodial container, so the product fakes one by giving the container to a member and adding an exception list on top, and now the party carrying the duties also carries a read path they were never separately granted. The mechanism of the failure is that custody answers who owes duties when the container has to be concluded and visibility answers who may read what is inside it, so a schema that derives reading from responsibility has folded two independent questions into one column and can no longer answer either of them on its own terms. What makes this worse than an ordinary permissions bug is that it never surfaces as one. Nobody filed a ticket asking for the custodian to be able to read the room. The read path arrived attached to the duty, and it is invisible precisely because it was never requested.

The correction we adopted is dull to describe and load-bearing to have. Custody became its own column, and the rule written next to it is that the column grants zero read access and no read policy may reference the custodian. Not that the custodian is denied by default and may be permitted later. That the read policies are forbidden from mentioning the role at all, which removes the shortcut rather than closing it. Downstream, where visibility is actually decided, the custodian is one audience key among many, and absent an explicit rule naming it, a custodian is refused exactly like a stranger. The duties still transfer when they have to, including the case where the custodian deletes their account and the container would otherwise be left with nobody answering for it. What does not transfer with them is a view inside.

The reason to hold this line has nothing to do with distrusting custodians, most of whom would never look. It is that a role which quietly includes reading cannot be given to anyone the group has not already decided to expose themselves to, which means the duties end up concentrated in whoever is most trusted rather than whoever is best placed to carry them. Separate the axes and custody becomes a job instead of a privilege, delegable to a person, an institution, or eventually a process, without anyone having to weigh whether that party deserves to read the room in order to keep it. A group that can name a keeper without naming a reader has more ways to be safe together than one that cannot.