Data on a bus is corrupted. How does the pattern of corruption narrow down the cause?

The pattern is the diagnostic, and it splits cleanly into deterministic versus random before you touch an instrument. Consistent corruption, the same wrong bytes every time for the same input, means the failure is deterministic, so it's a configuration or timing mismatch rather than anything analog: the two ends disagree on a parameter. On UART that's baud rate or frame format (data bits, parity, stop bits); on SPI it's the CPOL/CPHA mode, so the receiver samples on the wrong clock edge; on I2C it's an addressing or register-pointer mismatch. A very common root cause across all three is a wrong assumed peripheral clock behind a divider, so the configured number is right but the actual line rate isn't. Intermittent corruption that varies run to run points at the analog domain instead: noise coupling, a missing or poor common ground, marginal signal levels, reflections on long or unterminated cable, or edges too slow for the clock rate (on I2C, pull-ups too weak for the bus capacitance). A third pattern is worth naming: corruption that appears only above a certain clock rate is a signal-integrity or timing-margin problem, not a configuration one, since the settings didn't change. The practical rule is that deterministic bugs live in registers and configuration, and random bugs live in the physical layer, so the pattern tells you whether to re-read the datasheet or reach for the scope.