Every write in Raft is a small election of its own: the leader proposes, a majority must accept, and only then does the write become real. The AppendEntries consistency check is the load-bearing detail — prevLogIndex and prevLogTerm are a precondition, not a formality. If a follower's log does not chain onto that point, it rejects, and the leader steps its nextIndex backward until the logs agree.
Commit is a count, not a confirmation: the leader waits for a majority of replicas to hold the entry, then advances commitIndex. Application to the state machine is deliberately separate and ordered — no machine applies an entry before the majority committed it, which is what keeps state machines from diverging. The client's acknowledgment comes last, after application. That ordering — append, replicate, commit, apply, reply — is why Raft survives leader crashes: committed entries are always in a majority's log, so a new leader inherits them intact.