SPI has no ACK or error checking. What are the implications?

SPI is fire-and-forget: the master clocks bytes out and in, but the protocol gives no acknowledgment that the slave received or understood anything, no flow control, and no built-in error detection. The implications: the master can't tell if a slave is absent, unpowered, or in a bad state, it'll happily clock bits and read whatever the (possibly floating) MISO line gives, which can look like valid data. There's no automatic retry or framing-error signal as in CAN or even UART's framing/parity. So reliability must be built at a higher layer if the application needs it: many SPI devices expose a status/ID register you can read back to confirm the device is alive and configured (a common bring-up sanity check is reading a known WHO_AM_I/ID value), payloads can carry a CRC or checksum that you verify, and command protocols can be designed to be idempotent or to echo back state. The upside of this minimalism is speed and simplicity, no per-transfer overhead, which is exactly why SPI is chosen for high-throughput on-board links where the short, controlled traces make errors rare. You accept "no safety net" in exchange for performance, and add checks only where warranted.