Two tasks can share one condition that must survive the split
The common condition is part of the meaning of both resulting requirements. Copying only the action verbs produces a plausible task list with the wrong trigger. The review should therefore show the shared condition once in its original context and make its application to each candidate explicit. This avoids two opposite errors: dropping the condition from one action or assuming that every nearby action shares it. A useful follow-up asks what happens if recording succeeds but sending the receipt fails. That operational distinction may justify separate acceptance criteria even though the trigger is shared. The evaluation should inspect both provenance and behavior after the split. It should also check a later change to the approval condition, since both candidates may require review while unrelated notification requirements should remain unaffected.
Working through the example
A specification states that when a supervisor approves an order, the system records the decision and sends a receipt. Splitting produces an unconditional receipt task. Create separate recording and receipt candidates, each retaining the supervisor-approval condition. Preserve their common origin so later edits can be reviewed together.
A discriminating check
Try the workflow without approval and check that neither candidate loses the required gate. Some actions may have different failure behavior, which should be clarified independently after the shared condition is preserved. The project’s requirement-demarcation and traceability notes support retaining contextual evidence. Their application here is a proposed review workflow; it is not a demonstrated extraction guarantee.