A settlement flow is drawn as one page with 14 lifelines and 61 messages. Three consecutive reviews have stalled on it without reaching a decision. You get one edit before the next review. Which edit makes the drawing usable?

What is being tested

Whether you treat an unreadable diagram as a formatting problem or as a signal that the diagram is modelling two interactions at once. Reviewers stalling three times is data: they cannot hold the picture, so they ask local questions and never reach the decision.

The arithmetic

A reader following a sequence diagram tracks the state of every lifeline at every step. At 14 lifelines and 61 messages, the number of (participant, step) cells is over 850, and the number of ordered pairs that could interact is 14 × 13 = 182. Comprehension collapses somewhere around five or six lifelines, which is why almost every sequence diagram worth reading in practice has four to six and under fifteen messages.

The edit, and why that cut line

Split at the first boundary the team does not own: the point where the flow leaves your services for a payment processor, a bank file, a partner API. That line is the right one for three reasons.

• It is where the failure semantics change. Inside your estate you control timeouts and retries. Outside, you get someone else's error taxonomy and someone else's latency, so the two halves need different annotations anyway.
• It is where the audiences split. The internal page is read by the implementing engineers; the external page is read by whoever negotiates the integration and whoever is on call when the partner is slow.
• It is stable. Ownership boundaries change yearly. Internal component structure changes every sprint, so a cut along internal lines produces pages that go stale at different rates.

Each page then carries what makes a sequence diagram worth the maintenance: a timeout on every arrow, the retry policy and whether the receiver is idempotent, and the failure branch for the one step most likely to be slow. A page of five lifelines has room for those labels. A page of fourteen does not, which is the real reason they are missing.

Why the other options fail

• Redraw the arrows as asynchronous. This changes what the diagram claims, not how readable it is. If the calls are synchronous in the code, the diagram now lies, and the lie hides the thread-blocking behaviour that matters most under load.
• Larger canvas and bigger font. Treats a comprehension limit as a resolution limit. The reader's working memory does not grow with the paper. This is the edit most teams actually make, and the next review stalls in the same place.
• Collapse the retry loops. The retry behaviour is the highest-value content on a settlement diagram — it is where duplicate charges come from. Collapsing it removes the one thing the diagram was worth drawing for, in exchange for a modest reduction in arrows.

When this is the wrong answer

If the diagram exists as a one-off artefact for a single conversation — a whiteboard photograph to settle an argument about ordering — do not split it and do not maintain it. Date it, attach it to the decision record, and let it expire. The five-lifeline discipline is for diagrams that will be read again by people who were not in the room.