01
Build a role-by-collection matrix
Use roles Reader, Editor and Reviewer, with collections Drafts and Released. Reader has no access to Drafts and read access to Released. Editor has edit access to Drafts and read access to Released. Reviewer has read access to both. Define edit as including read for this worksheet. There are six role-collection cells, five with some access and one with none. Only one cell permits editing. These counts describe the stated matrix; they do not count individual people or prove anything about access outside the two collections.
02
Inspect inherited and exceptional access
Now add a temporary exception allowing the Reader role to read Drafts. The matrix has six accessible cells instead of five, while the editing count remains one. Record the exception separately with its reason and intended end condition. If the exception is removed, the original five-cell pattern returns. This demonstrates why a review must consider exceptions as well as the base policy. A role label alone is not enough to explain access when a second rule changes what that role can see within a particular collection.
03
Record a change before calling it complete
Use a change record containing the collection, role, previous permission, proposed permission, reason, reviewer and verification status. Keep proposed, configured and checked as distinct states. In the worksheet, removing the temporary exception is only a proposal until the relevant record is updated and checked. For a real implementation, the corresponding enforcement would also need verification through its own process. The reusable lesson is to preserve the difference between what people intend, what a configuration says and what has actually been observed.