diff --git a/protocol_rfcs/managed-commits.md b/protocol_rfcs/managed-commits.md
index 0ac70889c1b..92210d433d3 100644
--- a/protocol_rfcs/managed-commits.md
+++ b/protocol_rfcs/managed-commits.md
@@ -161,7 +161,11 @@ Even after a commit succeeds, Delta clients can only discover the commit through
 have no way to determine which file in `_delta_log/_commits` directory corresponds to the actual commit `v`.
 
 The commit-owner is responsible to implement an API (defined by the Delta client) that Delta clients can use to retrieve information about un-backfilled commits maintained
-by the commit-owner. Delta clients who are unaware of the commit-owner (or unwilling to talk to it), may not see recent un-backfilled commits and thus may encounter stale reads. The API must also return the latest version of the table ratified by commit-owner (if any).
+by the commit-owner. The API must also return the latest version of the table ratified by commit-owner (if any).
+Providing the latest ratified table version helps address potential race conditions between listing commits and contacting the commit-owner.
+For example, if a client performs a listing before a recently ratified commit is backfilled, and then contacts the commit-owner after the backfill completes,
+the commit-owner may return an empty list of un-backfilled commits. Without knowing the latest ratified version, the client might incorrectly assume their listing was complete
+and read a stale snapshot. Delta clients who are unaware of the commit-owner (or unwilling to talk to it), may not see recent un-backfilled commits and thus may encounter stale reads.
 
 
 ## Sample Commit Owner API