In DFD leveling, what must a child diagram preserve from the process it decomposes?

## Balancing, in one sentence When you take a process from one diagram and expand it on its own page, the expansion must consume and produce exactly the flows the parent showed. This rule is inherited from structured analysis, where it is called *balancing*, and it is what makes a set of levelled diagrams a single model rather than a pile of sketches. ## Why a threat model cares A DFD threat model enumerates threats per element, and mitigations get filed against elements. Two things break if the levels do not line up: **Coverage becomes unprovable.** If the level-2 page shows a flow that level 1 never had, then an entry point exists that was never analysed at the level where its trust boundary was drawn. If level 2 drops a flow the parent had, an analysed flow now has nowhere to live and its threats are orphaned. **Findings lose their anchor.** Stable numbering — process 4 expands into 4.1, 4.2, 4.3 — lets a threat, a mitigation and a later verification all point at the same element across revisions. Renumber freely and last quarter's findings no longer resolve to anything. ## Worked example An airline crew-rostering platform. Level 1 has five processes: roster generation (1), bid and preference intake (2), publication (3), the fatigue-rule engine (4) and the audit log writer (5). Only process 4 is taken to level 2, because the decision on the table is a safety one. At level 1, process 4 has two flows: - in: *draft roster* from process 1 - out: *rule violations* to process 3 A balanced level-2 page for process 4 therefore has exactly those two arrows crossing its edge: ``` draft roster ──► 4.1 parse and normalise duty periods │ ▼ 4.2 evaluate fatigue rules ──► [4.D rule set store] │ ▼ 4.3 format findings ──► rule violations (out) ``` Sub-processes 4.1 to 4.3 and the internal rule-set store 4.D are new; the boundary flows are not. Now suppose while drawing it, an engineer adds a fourth arrow: *manual override* arriving at 4.2 from a scheduler's console. That arrow is a genuine finding. An insider scheduler can inject a value that suppresses a fatigue violation, and the asset at risk is flight safety plus the availability of a roster the airline can legally fly. The correct response is: 1. Add the flow to the **parent** diagram, where it crosses whatever boundary separates operator tooling from the engine. 2. Re-run threat analysis for that crossing — tampering with rule inputs, and repudiation if the override is not attributed in the audit log written by process 5. 3. Only then keep it in the child. Silently deleting the arrow to preserve balance is the failure mode. Balancing is a *detector*: the discrepancy is telling you the higher-level model is wrong. ## One diagram per level The companion discipline is that each page holds elements of a single depth. A page showing four level-1 boxes plus the three internals of a fifth is unreadable in a specific way: a reviewer cannot say whether the level-1 boxes were analysed as whole subsystems or whether their internals were simply not drawn yet. Threat coverage per element becomes ambiguous, and per-element analysis silently skips the boxes that were never opened. This does **not** mean every process must be decomposed to the same depth. Levelling is deliberately uneven — most level-1 boxes on the rostering platform stay closed. It means the *drawing* does not mix depths on one page. ## Practical rules - Number children from the parent: 4 becomes 4.1, 4.2, 4.3; stores inside process 4 get an id that keeps the lineage. - Reuse the parent's flow names on the child's edge so a reader can match them by eye. - Aggregate rather than invent: if the parent shows one *draft roster* flow and the child needs it split into header and duty rows, that is a presentation choice inside the child; the edge still carries one named flow. - Treat a new boundary discovered in the child the same way as a new flow — push it up if it also affects the parent's edge. - When the parent changes (a new upstream feed), the child is stale until you rebalance it. Diagrams rot from the parent down. ## What interviewers are testing Most candidates can list DFD shapes. Far fewer mention that levels have to reconcile. Bringing up balancing signals that you have maintained a model over time rather than drawn one once, and it gives you a natural, correct answer to *what do you do when the detailed diagram disagrees with the overview* — you treat the disagreement as a security finding about an undocumented interface, not as a drawing error.