What does the diagram leave out?

A diagram is an argument about what matters, drawn by someone with a position. This is not a criticism; abstraction is the job. The review's job is different: to ask what the abstraction spent, and whether anyone approved the purchase.

Which omissions repeat?

After enough reviews the missing arrows sort into a taxonomy. The operational arrows: DNS, certificate issuance, the identity provider, the package registry, the CI system that can, in fact, push to production. Most diagrams omit the entire control plane, though it fails as memorably as any data plane. The humble dependencies: the NTP assumption, the SMTP relay, the license server, the S3 bucket of fonts. The bidirectional truths drawn as one-way: the "read-only" analytics store that something writes back to; the downstream that retries hard enough to be an upstream. And the human arrows: the vendor support contract, the person who approves the deploy, the spreadsheet that is secretly an integration.

Each omission is a bet that the thing omitted cannot hurt you. Some of those bets are excellent. The review exists to find the ones placed by forgetting rather than by judgment.

How do we find the missing arrows?

Evidence over recollection, always. Network flow logs against the drawn edges: every observed flow with no corresponding arrow is a finding, and there are always findings. The billing export against the drawn nodes: line items with no box attached are shadow architecture, paid for monthly. The incident folder against the diagram: incidents cluster on undrawn arrows at a rate that stops being funny. Where tooling exists we generate the as-built picture and diff; the C4 crowd's diagrams-as-code discipline (c4model.com) makes the diff cheap enough to run quarterly rather than at acquisition time.

What should a diagram declare?

Its scale and its date, like any honest map. "Context view, March 2026, control plane excluded" is a professional artifact; an undated, unscoped box-and-arrow field is folklore with a legend. We ask teams to keep few diagrams, generated where possible, each with a stated purpose, rather than the SharePoint stratigraphy of seventeen versions, where the only reliable information is which era each author joined in.

And one structural suggestion that pays immediately: draw the failure view once. Same boxes, but the arrows are "what happens when this is absent": what times out, what degrades, what lies. Most teams have never drawn it, and the first attempt reliably surfaces a dependency whose loss nobody has priced.

The diagram that leaves things out is doing its job. The diagram that has forgotten what it left out is doing someone else's. The difference is a dated caption and an owner, which is to say: the difference is whether anyone is still looking.