Glossary

A context diagram draws the boundary, not the insides.

One box for everything you own. The value is entirely in what surrounds it.

Download for macOS
v0.1.33 · .dmg · Apple Silicon & Intel
Signed & notarized by Apple · opens without a Gatekeeper warning
sha256 698955a0187bc039f4c74f5d05a9f10fbb27376a45788a0a241d1326b73873c7
Download for Windows instead
$curl -fsSL https://lucidtrain.com/install.sh | sh

A system context diagram is C4 level 1. Your entire system is a single box with no internal detail at all. Around it are the people who use it and the external systems it talks to, with each relationship labelled. The whole purpose is to establish scope: what is ours, what is somebody else's, and where the boundary between them runs. It is the one architecture diagram a non-technical stakeholder can read without explanation, which is what it is for.

Resisting the urge to open the box

The instinct is always to show a little of the inside, and it always makes the diagram worse. The moment your system is three boxes rather than one, the reader starts asking about internals and stops attending to the boundary, which is the only thing this level exists to communicate. Discipline about the single box is what makes it work.

Dependencies you did not choose

Drawing every external system honestly, the payment provider, the identity provider, the legacy system nobody wants to touch, the third-party API with an unclear owner, tends to surface uncomfortable facts. Teams frequently discover during this exercise that they depend on something nobody is responsible for. That discovery is worth more than the picture.

Who it is for

Unusually for an architecture diagram, the audience includes people who do not write code: product managers, security reviewers, procurement, anyone assessing risk. That means no unexplained acronyms and no internal shorthand, and it means the labels on the arrows should say what happens in plain words rather than naming a protocol.

When it changes

Rarely, which is why it is worth maintaining. A context diagram changes when the business changes: a new integration, a retired dependency, a new class of user. That slow rate is exactly what makes it one of the two C4 levels worth keeping by hand, alongside containers.

FAQ

Questions

Should the context diagram show any internal detail?

No. One box for your whole system. Showing internals moves the reader's attention off the boundary, which is the only thing this level communicates.

Who is the audience?

Anyone assessing the system from outside, including non-technical stakeholders. That is why it avoids acronyms and describes relationships in plain language.

How is it different from a container diagram?

Context shows your system as one box among its neighbours. A container diagram opens that box into the separately deployable things inside it.

Related

Last updated