Fragnet risk insertion — delay that propagates via logic

Some risks don't make an activity slower — they insert new work or a waiting period after it: a failed inspection, a consent that hasn't landed, re-work before handover. Stretching the activity's duration models that wrongly (it inflates the activity's own resource-time and misses downstream geometry). A fragnet risk injects the sampled delay after the mapped activity, so it propagates through the network logic like the inserted fragment it represents.

1. Add the risk normally — probability, distribution, min / likely / max in working days (this is the fragnet's duration when it fires).
2. Set Mode to fragnet in the register's Mode column.
3. Map the anchor activity first. The delay is inserted after the first activity in Maps to — put the anchor (the activity the fragnet hangs off) at the front. Its successors inherit the delay through their existing relationships; nothing about the anchor's own duration changes.
4. Run and read the drivers. A firing fragnet shows up in the completion distribution exactly as far as the network logic carries it — on a path with float, part of it is absorbed; on the critical path, all of it lands. The demo's R-01 Late utility diversion consent is modelled this way: 35% × triangular(10/20/45) inserted after the utility diversions.