A sub-goal repeats under three branches of your attack tree: duplicate, share, or lift it?

## The situation You are decomposing a music-streaming service's nightly royalty accounting job. The adversary is an authenticated low-privilege artist account; the asset is money. Three sub-goals hang under the root: ``` OR make the nightly royalty run pay out wrongly - inflate my own play counts - redirect another artist's payout to my account - suppress a rival's payout ``` And under each of them, the same node appears: *obtain write access to the payout table*. A strict tree cannot express that a node has three parents, so you have exactly three options, and the choice is a real design decision about the artifact — not a formatting preference. ## Option 1 — duplicate Write the sub-goal out three times, once under each parent, and keep a strict tree. - **For:** every reader convention, every drawing style and every roll-up over children assumes a tree, so nothing downstream breaks. Each copy can be tailored to its parent when the parent genuinely constrains it. - **Against:** three copies drift. Someone adds a fourth child to one copy; a control added under one copy makes it look as if the threat is handled while two identical copies sit uncovered. The more valuable the node, the more expensive the drift. Duplicate when the occurrences are **not actually identical** — different preconditions, different reachable actions, different timing under each parent — or when the node is a couple of lines and the audience needs a plain tree. ## Option 2 — share the node (the tree becomes a DAG) Draw the sub-goal once and let three parents point at it. The artifact is now a directed acyclic graph, not a tree. - **For:** one source of truth, no drift, and the structural fact is on the page: three goals converge here. - **Against:** arithmetic and reading habits. Any roll-up that walks children — an OR parent taking the best of its children, an AND parent summing them — can traverse the shared node more than once and count its effort repeatedly or attribute it to whichever parent it reached first. Path counting stops being a simple traversal. And a reader who assumes a tree can misread a converging edge as a mistake, so a shared node needs to be visually obvious. ## Option 3 — lift it into its own tree Promote the sub-goal to a root in its own right — *obtain write access to the payout table* becomes its own tree with its own decomposition — and leave a **reference stub** in each of the three parents pointing at it. This is also the answer to a different problem: a single branch that has simply grown too big. On a marine terminal's container-release gate system, with an on-site adversary holding a driver's handheld terminal and goods plus terminal availability at stake, the sub-goal *obtain a valid release code* keeps growing until it is a dozen-plus leaves and it visually dominates a tree that is supposed to be about the gate. Lifting it restores the parent tree's readability, gives the lifted tree room to be decomposed properly, and lets it have its own owner and its own review cadence. - **For:** readability of both artifacts, one place to maintain, and an explicit owner for a piece of analysis that had become a project on its own. - **Against:** indirection. A reader now has to follow a stub to a second document, and two artifacts can fall out of sync in a different way — the stub can outlive the tree it points at. It is worth the cost only when the node is genuinely large or genuinely shared. ## The decision rule Small and genuinely different per parent, duplicate. Small and identical, share. Large — either because it is deep or because three parents depend on it — lift, and leave stubs. If you are unsure, ask what a change to that node costs you: if updating it in one place must not silently leave two stale copies behind, you are past duplication. ## The finding hiding in the repetition Do not lose the analytical point in the bookkeeping. A sub-goal reachable from three different attacker goals is a **chokepoint**. One control there — separating who may write to the payout table from who may run the job, making writes to it append-only and reviewable — cuts three attack paths at once, and that leverage is the strongest funding argument the tree can produce. Duplicating the node buries this: three separate-looking rows in three branches read as three unrelated items in a backlog. Sharing or lifting makes it visible, which is often the better reason to choose those options than tidiness. The mirror of that is a caution: because a chokepoint node is a single point of failure in the analysis, a mistake in it is now wrong in three places at once. A lifted or shared node deserves more review attention than the average branch, not less.