Level 1 — Understand
NOT (user_is_admin OR user_is_owner)NOT (request_is_valid AND session_is_active AND rate_not_exceeded)NOT (NOT a AND NOT b)P = True and Q = False, evaluate:
P AND QP OR QNOT P OR QNOT (P AND NOT Q)P XOR QLevel 2 — Apply
A rate limiter has this condition:
def should_allow(request_count: int, limit: int, has_premium: bool, is_admin: bool) -> bool:
return (request_count < limit or has_premium) and not is_adminThe developer meant: “allow if under limit or premium, but always
block admins (they use a separate endpoint).” Is the code correct?
Evaluate for request_count=100, limit=50,
has_premium=False, is_admin=False.
A new requirement: “never block if admin.” The developer changes
not is_admin to is_admin. Evaluate the same
inputs. What changed?
The actual requirement is: “allow if under limit OR has_premium, regardless of admin status — admin is handled elsewhere.” Rewrite the function to match this intent and remove the admin check entirely. Name the AT3 tradeoff involved.
Level 3 — Design
An e-commerce platform has this access rule, stated in English:
“A user can modify an order if they placed the order and the order is not yet shipped, OR if they are a support agent and the order has an open dispute, OR if they are an admin.”
Identify every atomic statement in this rule.
Write a Python function
can_modify_order(user, order) -> bool using named
boolean variables for each atomic statement.
Write the De Morgan’s-equivalent formulation of the first clause only: “(placed the order) AND (not yet shipped)”. What does the De Morgan’s form express in plain language? Is it useful?
Suppose the rule is enforced on both the frontend (React) and backend (Python API). Identify two specific ways FM4 (Data Consistency Failure) can occur, and propose a mitigation that uses the AT8 (Coupling vs. Cohesion) tradeoff explicitly.