System Context Boundary
The line separating what a project owns and can change from what it must integrate with and accept as given.
The context diagram's real work is not showing external systems — it is establishing what is inside scope and what is not, which is a project decision as much as a technical one.
Drawing that line makes several things explicit that are otherwise assumed differently by different people: what the team can change versus what it must adapt to; who the external owners are and therefore whose agreement is needed; and which integrations are constraints rather than design choices.
It is also the fastest way to surface a scope disagreement. Stakeholders who nod through a written scope statement will object immediately to a box being on the wrong side of a line.
What belongs on it: the system as a single box, the user types with what they use it for, and every external system with the direction and purpose of the interaction. Nothing internal — the moment internal structure appears, it stops being a context diagram and stops serving its audience.
Its most valuable property is that it is understandable by people who cannot read any other architecture diagram, which makes it the right artefact for a steering group, a new joiner, a security reviewer and a procurement conversation. It is also the cheapest diagram to produce and the most frequently skipped.