WORKED CASE

One sharing rule, three questions

Separate what exists, what happens, and what the permission rule decides.

The facts stay the same

  • A workspace has a reader, a web application, an authorization service, and a document store.
  • The application asks authorization before reading a document.
  • A current team member may read the team document. A non-member is denied.
  • After membership is revoked, a new request is denied. In-flight requests and caches are outside this example.

One sharing rule, three questions

ONE CASE · DIFFERENT QUESTIONS

Open case →

What exists and what connects?

The reader uses the web application. The application depends on authorization and the document store. This compact teaching view illustrates C4-style responsibilities; it is not a full deployment model.

Reader to Web application to Authorization + storeReader. uses: Web application. checks, then reads: Authorization + storeReaderusesWeb applicationchecks, then readsAuthorization + store

Reader · uses → Web application · checks, then reads → Authorization + store

Makes visible: Participants, responsibilities, and dependencies.
Leaves out: Boxes do not establish call order or prove authorization enforcement.

What happens during a read?

Each new request checks current membership. Only an allow response leads to a store read. The deny branch returns no document.

Reader → Application: read(document)
Application → Authorization: current_member(reader, team)?
[allow] Application → Store: fetch(document)
[allow] Application → Reader: document
[deny] Application → Reader: access denied

Makes visible: Order, participants, and the allow/deny branch.
Leaves out: The sequence does not explain why membership is the chosen policy.

Which outcomes are intended?

This bounded decision table uses current membership. It does not model public links, folder inheritance, ownership, or concurrent revocation.

New requestCurrent membershipOutcome
Team documentMemberAllow
Team documentNon-memberDeny
After revocationNon-memberDeny

Makes visible: A small policy and its explicitly excluded cases.
Leaves out: A rule model does not prove that the deployed code follows it.

Check your understanding

The store is shown inside the architecture boundary. Does that prove former members cannot read documents?

Open the explained answer

No. A structural boundary does not establish a permission decision. Check the rule and its enforcement path, including the stated scope exclusions.

These are prepared representations of a bounded example. Changing views does not generate new facts or simulate unmodeled behavior.