diff --git a/content/en/docs/v3.4/learning/api_guarantees.md b/content/en/docs/v3.4/learning/api_guarantees.md
index 579c2879a..840c34f14 100644
--- a/content/en/docs/v3.4/learning/api_guarantees.md
+++ b/content/en/docs/v3.4/learning/api_guarantees.md
@@ -51,6 +51,11 @@ KV Service operations are atomic and occur in a total order, consistent with
 real-time order of those operations. Total order is implied through [revision].
 Read more about [strict serializability].
 
+For transactions without nested TXNs, the order of execution of operations
+is guaranteed to be the same as in its list of operations, which means stable
+GET responses within the transaction.
+For transactions with nested TXNs, the order of execution is not specified.
+
 Strict serializability implies other weaker guarantees that might be easier to understand:
 
 #### Atomicity
@@ -87,7 +92,10 @@ removes the performance penalty of linearized accesses' reliance on live consens
 Watches make guarantees about events:
 * Ordered - events are ordered by revision.
   An event will never appear on a watch if it precedes an event in time that
-  has already been posted.
+  has already been posted. For transactions without nested TXNs, the order of
+  generated events is guaranteed to be the same as in its list of operations.
+  For transactions with nested TXNs, the order of generated events is not
+  specified.
 * Unique - an event will never appear on a watch twice.
 * Reliable - a sequence of events will never drop any subsequence of events
   within the available history window. If there are events ordered in time as
diff --git a/content/en/docs/v3.5/learning/api_guarantees.md b/content/en/docs/v3.5/learning/api_guarantees.md
index c2bfacf45..a6c3cbd00 100644
--- a/content/en/docs/v3.5/learning/api_guarantees.md
+++ b/content/en/docs/v3.5/learning/api_guarantees.md
@@ -51,6 +51,11 @@ KV Service operations are atomic and occur in a total order, consistent with
 real-time order of those operations. Total order is implied through [revision].
 Read more about [strict serializability].
 
+For transactions without nested TXNs, the order of execution of operations
+is guaranteed to be the same as in its list of operations, which means stable
+GET responses within the transaction.
+For transactions with nested TXNs, the order of execution is not specified.
+
 Strict serializability implies other weaker guarantees that might be easier to understand:
 
 #### Atomicity
@@ -87,7 +92,10 @@ removes the performance penalty of linearized accesses' reliance on live consens
 Watches make guarantees about events:
 * Ordered - events are ordered by revision.
   An event will never appear on a watch if it precedes an event in time that
-  has already been posted.
+  has already been posted. For transactions without nested TXNs, the order of
+  generated events is guaranteed to be the same as in its list of operations.
+  For transactions with nested TXNs, the order of generated events is not
+  specified.
 * Unique - an event will never appear on a watch twice.
 * Reliable - a sequence of events will never drop any subsequence of events
   within the available history window. If there are events ordered in time as
diff --git a/content/en/docs/v3.6/learning/api_guarantees.md b/content/en/docs/v3.6/learning/api_guarantees.md
index 2bddc9f1f..2e594a8bb 100644
--- a/content/en/docs/v3.6/learning/api_guarantees.md
+++ b/content/en/docs/v3.6/learning/api_guarantees.md
@@ -51,6 +51,11 @@ KV Service operations are atomic and occur in a total order, consistent with
 real-time order of those operations. Total order is implied through [revision].
 Read more about [strict serializability].
 
+For transactions without nested TXNs, the order of execution of operations
+is guaranteed to be the same as in its list of operations, which means stable
+GET responses within the transaction.
+For transactions with nested TXNs, the order of execution is not specified.
+
 Strict serializability implies other weaker guarantees that might be easier to understand:
 
 #### Atomicity
@@ -87,7 +92,10 @@ removes the performance penalty of linearized accesses' reliance on live consens
 Watches make guarantees about events:
 * Ordered - events are ordered by revision.
   An event will never appear on a watch if it precedes an event in time that
-  has already been posted.
+  has already been posted. For transactions without nested TXNs, the order of
+  generated events is guaranteed to be the same as in its list of operations.
+  For transactions with nested TXNs, the order of generated events is not
+  specified.
 * Unique - an event will never appear on a watch twice.
 * Reliable - a sequence of events will never drop any subsequence of events
   within the available history window. If there are events ordered in time as
diff --git a/content/en/docs/v3.7/learning/api_guarantees.md b/content/en/docs/v3.7/learning/api_guarantees.md
index 2bddc9f1f..2e594a8bb 100644
--- a/content/en/docs/v3.7/learning/api_guarantees.md
+++ b/content/en/docs/v3.7/learning/api_guarantees.md
@@ -51,6 +51,11 @@ KV Service operations are atomic and occur in a total order, consistent with
 real-time order of those operations. Total order is implied through [revision].
 Read more about [strict serializability].
 
+For transactions without nested TXNs, the order of execution of operations
+is guaranteed to be the same as in its list of operations, which means stable
+GET responses within the transaction.
+For transactions with nested TXNs, the order of execution is not specified.
+
 Strict serializability implies other weaker guarantees that might be easier to understand:
 
 #### Atomicity
@@ -87,7 +92,10 @@ removes the performance penalty of linearized accesses' reliance on live consens
 Watches make guarantees about events:
 * Ordered - events are ordered by revision.
   An event will never appear on a watch if it precedes an event in time that
-  has already been posted.
+  has already been posted. For transactions without nested TXNs, the order of
+  generated events is guaranteed to be the same as in its list of operations.
+  For transactions with nested TXNs, the order of generated events is not
+  specified.
 * Unique - an event will never appear on a watch twice.
 * Reliable - a sequence of events will never drop any subsequence of events
   within the available history window. If there are events ordered in time as