What belongs on a context diagram that most teams leave off?

What is being tested

Whether you can turn a scope artefact into a resilience one at almost no extra cost.

The omissions

1. Failure behaviour per dependency. One line each: "if the payment provider is unavailable, checkout fails and we queue the order for retry." This is the highest-value addition and it takes minutes.

Without it, the diagram says what the system talks to. With it, the diagram says what happens when each of those things breaks — which is the question an incident responder and an architecture reviewer both have.

2. The dependencies that do not feel like dependencies. The identity provider. The secrets store. The deployment pipeline. The scheduled job that runs from somewhere else. A shared library owned by another team. These are omitted because they are infrastructure, and they are exactly what makes a regional failover plan inoperable when they turn out to be single-region.

3. The direction and initiator. "We call them" and "they call us" have entirely different security, availability and scaling implications, and an undirected line conveys neither.

4. The nature of the interaction. Synchronous API, nightly batch file, event stream, human process. A nightly file transfer and a synchronous call look identical as arrows and behave nothing alike.

5. Human actors and manual processes. Someone rekeying data between two systems is a dependency with a failure mode, and it is invisible on any technical diagram.

6. A date and an owner.

The test for whether the diagram is doing its job

Give it to someone who has never seen the system and ask: what breaks if each of these goes down? If they can answer, the diagram is complete. If they cannot, the failure behaviour is missing.

Why it matters more than the internal diagrams

The interesting failures live at the boundaries you do not control. Internal structure can be read from the code; external dependency behaviour cannot be read from anywhere.