Which Threat Modeling Manifesto anti-pattern is a six-week, 200-element diagram with no threats enumerated yet?

### What the anti-pattern actually says **Perfect Representation** is the fourth of the Threat Modeling Manifesto's anti-patterns. It is easy to misquote, so get its content exactly right: it is better to create *multiple* threat modeling representations, because **there is no single ideal view**, and additional representations may illuminate different problems. Notice what that is not. It is not a rule about how much detail belongs in a drawing, and it is not a claim that sloppy diagrams are fine. It is a claim about the **existence of an ideal**. If no one view is complete, then `finish the model first` is not a coherent plan, and any programme whose first milestone is a finished representation has planned for a milestone it cannot reach. ### How it shows up An insurance broker portal: a team spends six weeks growing a diagram to two hundred elements. Every queue is drawn, every sidecar, every configuration store. It is genuinely impressive. Not one threat has been written down. Three things have gone wrong: 1. **The effort bought precision in a dimension that yields nothing.** Findings come from asking what can go wrong at a boundary, not from the count of boxes. 2. **The value pair is inverted.** `Doing threat modeling over talking about it` — six weeks of drawing is preparation for the exercise, not the exercise. 3. **The diagram is stale on arrival.** A portal under active development moved during those six weeks, so the completeness the team was chasing was never achievable in the first place. ### Multiple views, not one better view The constructive half of the anti-pattern is the interesting half. Different representations surface different threat classes, so the answer to `which view is right` is `draw another one`: - A **coarse flow view** shows where data crosses a boundary between things with different levels of trust — where most tampering and disclosure threats live. - A **data-lifecycle view** follows one class of data from collection to deletion, which is what surfaces retention, copying and third-party sharing problems that a flow view hides. - A **privileged-path view** draws only the administrative and support routes into the system, which is where the paths nobody diagrams tend to be. - A **sequence view** of one important transaction exposes ordering and state problems — the double-submits and replays that no static box diagram shows. None of these is complete. Each is cheap. Together they find more than one perfected drawing does, which is precisely the Manifesto's argument. ### The objection worth answering `Surely an accurate diagram is a precondition for finding real threats?` The direction of causation is backwards. Enumerating threats is one of the most reliable ways to *discover* that the drawing is wrong — someone says `what about the support console` and a whole undrawn path appears. The drawing gets fixed by the analysis; waiting for it to be right first means waiting on something the analysis was supposed to produce. That said, the anti-pattern is not a licence for a misleading picture. A view that shows a boundary where none exists sends the analysis somewhere false. The failure being named is treating **completeness as the gate on starting**, not caring about accuracy in the parts you drew. ### How to say this in an interview The strong answer names the anti-pattern, states its actual claim (`no single ideal view`, so prefer several representations), and then makes the practical move: start enumerating against what exists now and let the analysis extend the drawing. A weak answer paraphrases it as `do not over-engineer your diagrams`, which sounds close and misses the point — it turns a claim about the plurality of views into a vague plea for moderation.