Jay drew the permission chain on the whiteboard—not a whiteboard, actually, a shared Google Doc rendered through the Docs twin, which felt like an appropriate kind of recursion. Seven levels deep. He labeled each one.
Level one: the organization's domain-wide sharing policy. Level two: the shared drive's member list. Level three: the top-level folder's explicit permissions. Level four: a subfolder that inherited from its parent. Level five: another subfolder that did not inherit, because someone had broken inheritance to add a guest collaborator. Level six: a document inside that non-inheriting folder. Level seven: a specific permission on that document granting comment-only access to a service account.
"When an agent requests access to this document," Jay said, "the Drive twin has to evaluate all seven levels to determine the effective permission. And the answer isn't just yes or no. It's reader, commenter, writer, or owner, and each role has different capabilities."
Justin was reading over Jay's shoulder. "What happens at level five? When inheritance breaks?"
"That's the interesting part. In real Drive, breaking inheritance doesn't remove existing permissions. It stops new parent permissions from propagating down. But the permissions that were inherited before the break? They stay. Unless someone explicitly removes them." Jay highlighted a node in his diagram. "So this subfolder has permissions from two sources: the ones it inherited before the break, and the ones added directly after. The twin tracks both."
"And if someone changes the parent folder's permissions after the break?"
"Nothing happens to the child. That's the whole point of breaking inheritance. But here's the edge case that took us two days: if someone re-enables inheritance on the child folder, the parent's current permissions propagate down. Not the parent's permissions at the time of the original break. The current ones. Any changes that happened while inheritance was broken suddenly appear in the child."
Navan had been listening while running scenarios. "The permission evaluation also interacts with the sharing settings. Even if a user has write access through the permission chain, the shared drive settings might restrict external sharing. The twin checks both: the permission chain and the drive-level policy."
"How many permission states are there in total?" Justin asked.
Jay did the math in his head. "For a single file: four roles times three sharing scopes times two inheritance states times the binary on whether the drive-level policy allows or restricts. That's forty-eight possible states. For a folder tree seven levels deep, the combinatorial space is..." He paused. "Large."
"We don't enumerate all combinations," Navan said. "We test the paths that scenarios actually exercise. But we validate the permission resolution algorithm against every edge case we've discovered. There are thirty-seven documented edge cases so far."
"So far," Jay repeated. He added a question mark to the eighth level of his diagram. There was always another level. Google Drive permissions were fractal: every zoom revealed more detail, more exceptions, more edge cases nested inside edge cases.
The twin handled them all. Or it would, once they found them all. The finding was the hard part.
Seven levels deep and thirty-seven edge cases and counting. This is why I dread Drive permission audits. The twin sounds like it suffers so we don't have to.