A 200-element data-flow diagram and a two-box 'monolith to database' one both fail review — why?

## Both failures are the same failure A diagram is not an inventory. It is the input to a walk: a reviewer moves across the page, stops at each element and each crossing, and asks what an adversary standing there could do. Anything that makes that walk impossible is a diagramming defect, and there are two ways to make it impossible — bury the walk in elements, or collapse it into one box. ## Too much: the unreviewable page A logistics platform is drawn for a peak-season availability review with roughly 200 elements printed on A0. The asset in question is service availability: if dispatch stops during peak, deliveries stop. Three things go wrong. **Attention is spread evenly.** Human review is a scarce resource, and a page with 200 boxes offers no ranking. The handful of crossings where an outside party can influence load — a public tracking API, a partner carrier callback, a bulk import — sit beside dozens of internal calls between components that share one credential and one trust level. The signal is present but not findable. **Review degrades to spot-checking.** Given a page they cannot hold in their head, reviewers sample. Sampling is fine for testing and fatal for enumeration, because the value of enumeration is coverage: the threat you never looked at is the one nobody handles. **Detail is mistaken for rigour.** A big diagram feels thorough and is often defended on that basis. It is worth naming this directly in the review: completeness of *components* is not completeness of *analysis*, and the two are frequently inversely related. The repair is aggregation with a rule, not arbitrary shrinking. Neighbouring elements that share a trust level, a credential and an exposure can be collapsed into one process without losing a single threat, because nothing an adversary could do to one differs from what they could do to the other. Elements that own a crossing stay distinct. For the logistics review that typically collapses a dozen internal services into two or three, and leaves the externally-reachable ingress points, the queue that absorbs peak load and the shared dispatch store standing alone. ## Too little: the box that hides the transition The other extreme is a refund-flow design review that arrives as 'the monolith' with one arrow to 'the database'. It is not wrong — that is genuinely the deployment — and it is useless. What matters about a refund is a **privilege change**: a support agent, whose day job is reading orders and answering customers, triggers an action that moves money out. Somewhere inside that single box, a low-privilege identity causes a funds-out effect. That transition is the whole design review. Drawn as one box, it is invisible: the support agent is not on the page as a principal, the approval or limit check is not on the page as a process, and the ledger is not distinguished from any other table in 'the database'. The symptom is unmistakable in the output. Every threat reads 'spoof the monolith', 'tamper with the monolith', 'the database could be disclosed'. Those sentences are true of every system ever built, which is another way of saying they carry no information. When threat statements are interchangeable between systems, the diagram is too coarse — that is the most reliable detector available, because it needs no judgment about box counts. ## The calibration rule Two moves, applied repeatedly: - **Collapse** adjacent elements that share a trust level, a credential and an exposure. Nothing is lost, because no threat distinguishes them. - **Split** any element inside which the trust level changes, an authorisation decision is made, or an asset changes hands. Applied to the refund page, the second rule alone produces something reviewable: support console, refund request handler, approval or limit check, ledger write, payment rail — with a boundary between the agent and the handler, and another between the approval decision and the funds-out effect. Applied to the logistics page, the first rule alone brings 200 elements down to something a room can walk in an hour. ## What the reviewer should say For the oversized page, avoid the unhelpful 'this is too detailed'. Say what the detail costs — that you cannot rank the crossings, and therefore cannot promise coverage — and propose the specific collapses. For the two-box page, do not ask for 'more detail' either; ask for the one thing that is missing, which is the point where privilege changes. A team that hears 'draw more' will produce a bigger picture of the same shape; a team that hears 'show me where a support agent's authority becomes a money movement' will draw the right five boxes. ## A note on the middle There is no universal correct size, and 'about a dozen elements' is a rule of thumb rather than a law. The honest formulation is that the right diagram is the smallest one in which every trust boundary that exists is visible and every element left standing is one an adversary could plausibly occupy or influence.