Step 1: Picture two instructions I1 (earlier in program order) and I2 (later) moving through a simple 5-stage pipeline (IF, ID, EX, MEM, WB), where ID is where operands are read and WB is where results are written back.
Step 2: Suppose I1 writes register R1 in its WB stage and I2 reads R1 in its ID stage. Because instructions overlap in the pipeline, I2's ID stage can occur several cycles before I1's WB stage completes. If nothing is done, I2 reads the old value of R1 instead of the new one I1 is about to produce, this is the read-after-write hazard, solved in real pipelines with forwarding paths that route I1's computed result directly to I2.
Step 3: Now suppose I1 reads R1 in ID and I2 writes R1 in WB, a write-after-read pattern. Since I2 enters the pipeline strictly after I1 and both stages proceed in the same forward-flowing order as instruction issue, I1's read of R1 always finishes before I2 could possibly write it, so this pattern cannot create a hazard in a normal in-order pipeline.
Step 4: Likewise, if both I1 and I2 write R1 (write-after-write) or both only read R1 (read-after-read), the strict in-order progression through the pipeline stages guarantees the writes happen in program order and the reads never corrupt each other, so neither situation produces a hazard.
Step 5: The one relationship that breaks down purely because of pipeline overlap, independent of any out-of-order machinery, is read-after-write, since the consumer's read stage can physically occur before the producer's write stage completes. That is the dependency responsible for data hazards.
\[ \boxed{\text{Read-after-write}} \]