Case study: review a document-access policy

The River archive is preparing a document-sharing feature. You are its reviewer. Everything below is invented and supplied for an offline exercise. Your job is to decide whether the design and evidence support the stated policy, not to discover how an unknown service behaves.

A permission decision combines an identified subject, a requested action, the particular resource, and the conditions required by policy. Keep those pieces visible as you read. “The user is an editor” is only one fact; it does not identify whose document that editor may change.

Artifact A: the agreed policy

Current project members may read that project’s ordinary documents. Current editors may also edit and export its ordinary documents. A restricted document additionally requires an explicit document-specific grant for reading; nobody in this exercise has one. Other actions on restricted documents are outside this release and denied. Removed members lose future service access. These rules apply when data is delivered or a change is committed, including a delayed export.

The service must determine identity from an accepted session and obtain membership and document classification from trustworthy stored state. A denied read returns no protected document content; a denied edit leaves the stored document unchanged. This policy concerns service access and cannot retract copies people previously saved.

Artifact B: people and documents

The supplied membership record is complete: Ada is a current River editor and Bo a current River viewer, each with membership only in River. Cy was removed from River yesterday and has no current project membership. Dee is a current editor with membership only in Hill. All four accounts can authenticate. R17 is an ordinary River document, R18 is restricted within River, and H12 is an ordinary Hill document. The names are labels, not secrets or permission evidence.

An access matrix records the permitted or denied actions for each person and resource. Start with Ada’s worked row:

Ada may read and edit ordinary R17 because she is a current River editor. Restricted R18 adds a grant she lacks. H12 belongs to Hill, where she has no membership. Her role answers only part of the decision; the resource and its conditions still matter.

PredictOn paper, make the same four decisions for Bo, Cy, and Dee: read R17, edit R17, read R18, and read H12. Give the policy reason for each row before comparing your matrix.

Person	Read R17	Edit R17	Read R18	Read H12
Bo	Permit	Deny	Deny	Deny
Cy	Deny	Deny	Deny	Deny
Dee	Deny	Deny	Deny	Permit

Bo’s viewer membership permits the ordinary River read, but not editing, restricted reading, or Hill access. Cy’s account still existing does not restore yesterday’s membership. Dee has useful permissions on Hill, not River. Each denial follows a missing policy condition, not a judgment about whether someone seems trustworthy.

Artifact C: the proposed enforcement

The supplied read design passes the current account, action, document, membership, classification, and document-specific grant state into a shared policy component before releasing content. Membership, classification, and grant state come from trustworthy stored records; no person has a document-specific grant here. Its edit design checks that the account is an editor somewhere, but does not relate that role to the document’s project. Its export worker checks permission when the job is scheduled and records no permission check at delivery.

PredictWhich of the three supplied designs includes the policy’s required inputs and decision boundary? For each other design, identify the missing relationship or timing check. Write the smallest correction that preserves Artifact A’s approved permissions.

The read design supplies identity, action, resource, membership, classification, and document-specific grant state at the decision point before disclosure. That is useful design evidence; correct rule evaluation and implementation results still need review.

The edit decision lacks the caller’s current editor relationship to the requested document’s project. The export worker lacks evidence of current permission at delivery. Add those checks at their required boundaries. A helper named “authorize” does not settle its inputs, rules, or enforcement point.

Giving every editor access to every project would change the requirement instead of implementing it. A broader collaboration model could be proposed separately, but requires explicit product approval and review of the added disclosure and modification rights.

Artifact D: evidence and the acceptance decision

The evidence packet records Bo reading R17 successfully and Cy being denied a read of R17 with no document content returned. It contains no edit results and no scenario where membership changes during an export. Those two observations support two matrix cells, not the whole feature. Do not describe an unobserved edit outcome as a confirmed incident.

A defensible decision is to hold acceptance of editing and delayed exports until their design gaps are corrected and evidence covers the required boundaries. Preserve the useful read evidence, but also review restricted and other-project reads. For edits, ask for an allowed result and a denial that leaves data unchanged. For exports, include an initially authorized requester who loses the required relationship before delivery.

An alternative is a genuinely narrower release that disables both incomplete capabilities at the service boundary. Hiding their buttons is insufficient evidence of that scope reduction. Record what remains enabled, who verifies the narrowed behavior, and which requirements still apply. A good review explains the smallest justified decision without claiming that two passing examples prove every permission correct.