When is a single process box on a data-flow diagram actually hiding several processes?

## What a single process box promises When you draw one circle and give it a name, you are asserting several things at once: this runs as one identity, its parts trust each other, there are no edges inside it that carry data anyone would want, and a control placed on it covers everything it contains. Those assertions are usually fine. When they are false, they are false invisibly, which is the worst way for an assumption to be wrong. ## The signals that a box is lying Four signals, in rough order of how often they matter. **Different privilege.** Parts of the box hold materially different power. One part can only read a queue; another can sign artefacts, write to production, or issue credentials. Merging them on the diagram means the highest privilege inside the box quietly becomes the privilege of the whole box, and nobody asks whether the low-privilege part could reach the high-privilege one. **Different exposure.** Different parts are reachable by different callers. If one component of the box accepts connections from anything on a local network and another is only reachable from an internal admin path, they do not share a threat profile, and the diagram should not imply they do. **Different data classes.** One part handles bulk low-value telemetry, another handles signing keys or personal data. The asset at stake differs, so the cost of a compromise differs. **Different lifecycle and operator.** One part is deployed weekly by a product team, another is a vendor component updated rarely by whoever remembers. Different change rates mean different assumptions rot at different speeds. A useful heuristic: if you cannot describe the box's *single* identity and *single* set of inbound callers in one sentence, it is more than one process. ## A worked case: the fleet controller A warehouse runs a fleet of autonomous robots, and the design shows one box called `fleet controller`. Ask what runs inside it and you get three answers: - a **route scheduler** that computes paths and sends movement instructions to robots, - an **over-the-air firmware updater** that builds, signs and pushes firmware images to those robots, - a **telemetry sink** that ingests position, battery and fault streams from every unit on the floor. These fail every test above. The updater holds signing material and can change what physical machines do; the scheduler can move machines but not change their code; the sink holds nothing precious and accepts input from every device on the floor, including any device an attacker has managed to get onto the network. Yet the box implies they share an identity and a blast radius. Redraw it as three processes with the flows between them made explicit, and the interesting questions appear immediately. Does the telemetry sink write into a store the scheduler reads, so that fabricated telemetry can steer routing decisions? Does the updater pull build artefacts from a pipeline whose inputs include third-party dependencies, so that a compromised dependency becomes signed firmware on a moving machine? Can something that reaches the sink reach the updater's signing path because they run under one identity on one host? Note what is at stake here, because it is not a database of customers. The asset is the **safety of a physical process**, and the adversary who matters most is not a person typing at a browser but a compromised component in the update path. ## The notation for it Classic DFD notation has an answer that is neither pretending the box is atomic nor exploding everything. A **complex or multi-process element**, conventionally drawn as two concentric circles, marks a process that is known to contain several processes and has its own diagram beneath it. The marker is honest bookkeeping: it says on the face of the diagram that this box has not been analysed internally, so a reader does not mistake absence of internal threats for evidence there are none. Use it when the internals genuinely do not affect the decision in front of you — say, a mature component whose parts share an identity and an exposure anyway. Split the box when any of the four signals above applies, because then the internal edges *are* the analysis. ## The opposite failure Splitting everything is its own defect. A diagram with forty processes because someone enumerated every class in the codebase is unreadable, and unreadable diagrams do not get argued with. The discipline is not maximum resolution. It is that every box you leave whole is a box whose internals you have consciously decided are uniform in identity, exposure and data class — and that you can say so out loud when someone asks. ## In an interview The tell of a strong answer is that the candidate treats a suspiciously well-named box as a prompt rather than a fact. `Fleet controller`, `platform service`, `integration layer` are product names, not processes. Ask what identity it runs as and who can reach it. If there is more than one answer, the box needs splitting or marking.