Original text:
4.1.4. As keys for new encryption levels become available, TLS provides QUIC <del> with those keys.  Separately, as TLS starts using keys at a given encryption level, TLS indicates to QUIC that it is now reading or writing with keys at that encryption level.  These events are not asynchronous; they always occur immediately after TLS is provided with new handshake bytes, or after TLS produces handshake bytes. </del>  TLS provides QUIC with three items as a new encryption level becomes available: process those acknowledgments in order to detect lost Handshake packets.  4.1.5. exchange-summary summarizes the exchange between QUIC and TLS for both client and server.  Each arrow is tagged with the encryption level used for that transmission.  4.2. This document describes how TLS 1.3 TLS13 is used with QUIC.

Reviewer comments:
URL a TLS stack. The canonical example being the Handshake keys, which are needed by a client to acknowledge partial server Handshake flights. TLS won't use those keys itself until it has the entire set of Handshake messages from the server. In doing this, I decided that it makes sense to reorder the sequence diagram to show what incoming packets trigger different events.
In order for the client to be able to acknowledge packets sent with Handshake encryption level, it needs to have access to the Handshake write key right after processing the ServerHello. URL states that the Handshake write key is exported after receiving the server's Finished message, which would make loss recovery of Handshake packets impossible. I found this fact non-obvious, and I think it should be documented in some way that we're deviating from the schedule in which a normal TLS 1.3 implementation would make new keys available.
I had the same realization a while ago, but failed to capture that in the spec. It's a fairly important point that - if ignored - would lead to bad outcomes, because a good part of the time you can get away with not exporting it early. You mostly just get transient errors... until the server can't fit its certificate into 3 packets, then you get a hard fail.

Revised text:
4.1.4. As keys for new encryption levels become available, TLS provides QUIC  <ins> with those keys.  Separately, as keys at a given encryption level become available to TLS, TLS indicates to QUIC that reading or writing keys at that encryption level are available.  These events are not asynchronous; they always occur immediately after TLS is provided with new handshake bytes, or after TLS produces handshake bytes. </ins> TLS provides QUIC with three items as a new encryption level becomes available: process those acknowledgments in order to detect lost Handshake packets. <ins> QUIC also needs access to keys that might not ordinarily be available to a TLS implementation.  For instance, a client might need to acknowledge Handshake packets before it is ready to send CRYPTO frames at that encryption level.  TLS therefore needs to provide keys to QUIC before it might produce them for its own use. </ins> 4.1.5. exchange-summary summarizes the exchange between QUIC and TLS for both client and server.  Each arrow is tagged with the encryption level used for that transmission. <ins> exchange-summary shows the multiple packets that form a single "flight" of messages being processed individually, to show what incoming messages trigger different actions.  New handshake messages are requested after all incoming packets have been processed.  This process might vary depending on how QUIC implementations and the packets they receive are structured. </ins> 4.2. This document describes how TLS 1.3 TLS13 is used with QUIC.