The two pieces before this one covered the model and its enforcement — what the rules are and where they’re applied. This last one is about a property that’s easy to leave out of both: whether anyone can inspect the result. “Who can see this record, and why?” is asked constantly in practice — by a support engineer investigating a complaint, by a customer’s admin reviewing their own configuration, by an auditor, by whoever is trying to figure out how the wrong person got access. A system that can enforce correctly but not explain itself makes every one of those interactions an investigation.

The inspection question is a different one from the enforcement question. Enforcement asks: given this person and this resource, allow or deny? Inspection asks the reverse: given this resource, who reaches it, and through which grant? The second is harder, because permissions usually compose — a role, plus membership in a team, plus something inherited from a parent object, plus one exception someone added for a customer. Any single check is easy to evaluate. Reconstructing the whole picture from the outside, without running the code in your head, often isn’t possible at all unless somebody designed for it.

The cost of skipping it shows up in slow, avoidable ways. Support can’t confirm whether a customer’s complaint is a bug or their own configuration, so it escalates. Nobody can safely remove an old permission because nobody can tell what currently depends on it, so exceptions accumulate permanently. And a customer’s own admin — the person who’s supposed to manage this — can’t verify what they’ve set up, which converts a self-serve task into a ticket. That last one is worth noticing: inspectability isn’t only an internal debugging concern, it’s part of whether the feature works for the people who administer it.

The other half of after-the-fact answerability is history. Current state tells you who can access something now; the harder questions during an incident are when access was granted, by whom, and what changed. Permission changes are exactly the kind of event worth recording permanently — they’re low-volume, high-consequence, and effectively impossible to reconstruct later from anything else. It’s the same argument the schema thread made about writing down what data means: the information is cheap to capture at the moment it exists and unrecoverable afterward.

So the thread closes where it started, on the claim that this is product surface rather than plumbing. A permission system is judged on three things: whether the model can express how customers actually work, whether the rules hold on every path rather than the ones someone remembered, and whether a human can find out what the answer is and how it got that way. The first two failures cause incidents. The third one causes a slow tax on everyone who touches the system — which is easier to ignore and, over a long enough period, probably costs more.