Most organizations have steps that appear in many processes: find the standards that apply, build and verify, run a review, capture what was learned. When each workflow carries its own copy, the copies drift. One team adds a lint step, another does not, and six months later "the review step" means five different things. Fragments solve the same problem functions solve in code: write it once, call it everywhere. The same pattern holds outside engineering: a legal check or a brand review used by many content workflows.
A fragment is not a sub-workflow. A sub-workflow is a detour a decision starts at run time, with its own instance and a parent that waits. A fragment is inlined into the workflow that embeds it; its steps simply become part of the line. Use a fragment for steps that always run in that position, and a sub-workflow for work that only happens on some paths.
The design discipline is to keep fragments narrow and outcome-shaped. A fragment called build-and-verify with three clear steps is easy to reuse. A fragment that tries to cover every variant of a process becomes a second monolith.