Attacks

An artifact / deliverable targets a root / problem it aims to resolve.

Definition

An attacks arrow says that an artifact / deliverable is meant to resolve, remove, or reduce a root / problem.

It is one specific relationship an artifact can have, not the only one. Artifacts also connect to actions, outcomes, and other artifacts with ordinary influences arrows. Use attacks only where "this artifact exists to fix that problem" is the point being made.

Direction

From the artifact to the problem it targets. This is one of the few arrows that may point back toward the roots, because the artifact acts on the problem rather than flowing from it.

When to use it

During refinement, when the group wants to show which problem a particular artifact is for.

Making solution-to-problem links visible has a useful side effect: it shows at a glance which nodes are solutions and which are problems. That helps the group notice solution-dumping early.

How to draw it

A dotted line with a filled arrowhead. Placing the artifact next to its target problem helps the pair read as a unit, but it is not required. Add the dotted line to the legend.

Examples

• "Automated deployment pipeline" attacks "Deployment complexity"
• "Code review checklist" attacks "Inconsistent code quality"
• "Team charter" attacks "Unclear roles and responsibilities"

Required or optional

Optional. In observed trees, attacks appeared once the group had started mapping artifacts. Relationship types tend to grow out of need, not in advance.