Added line about how ORIGIN_GROUP is dynamic in example.

product_docs/docs/pgd/5.6/commit-scopes/commit-scopes.mdx

@@ -123,9 +123,9 @@ Set `bdr.commit_scope` to `local` to  use the PGD default async replication.
 
 ## Origin groups
 
-Rules for commit scopes can depend on the node the transaction is committed on, that is, the node that acts as the origin for the transaction. The group to which that node belongs is the transaction's origin group. To make this transparent for the application, PGD allows a commit scope to define different rules depending on where the transaction originates from.
+Rules for commit scopes can depend on the node the transaction is committed on, that is, the node that acts as the origin for the transaction. The group to which that node belongs is the transaction's origin group. To make this transparent for the application, PGD allows a commit scope to define different rules depending on the transaction's origin group.
 
-For example, consider an EDB Postgres Distributed cluster with nodes spread across two data centers: a left and a right one. Assume the top-level PGD node group is called `top_group`. You can use the following commands to set up subgroups and create a commit scope requiring all nodes in the local data center to confirm the transaction but only one node from the remote one:
+For example, consider an EDB Postgres Distributed cluster with nodes spread across two data centers: a left (`left_dc`) and a right one (`right_dc`). Assume the top-level PGD node group is called `top_group`. You can use the following commands to set up subgroups and create a commit scope requiring all nodes in the local data center to confirm the transaction but only one node from the remote one:
 
 ```sql
 -- create sub-groups
@@ -177,9 +177,11 @@ SELECT bdr.alter_node_group_option(
 
 ### ORIGIN_GROUP syntax sugar
 
-You can also refer to the origin group dynamically when creating a commit scope rule by using `ORIGIN_GROUP` syntax sugar. This can make certain commit scopes like the one above, `example_scope`, even easier to specify in that you can simply specify one rule instead of two.
+You can also refer to the origin group of a transaction dynamically when creating a commit scope rule by using `ORIGIN_GROUP` syntax sugar. `ORIGIN_GROUP` of a transaction refers to the bottommost group from which the transaction originated. 
 
-Again, suppose that for transactions originating from nodes in `right_dc` you want all nodes in `right_dc` to confirm and any 1 from `left_dc` to confirm before the transaction is committed. Also, again suppose that for transactions originating in `left_dc` you want all nodes in `left_dc` and any 1 in `right_dc` to confirm before the transaction is commited. Above we used these two rules for this when defining `example_scope`:
+This can make certain commit scopes like the one above, `example_scope`, even easier to specify in that you can simply specify one rule instead of two.
+
+For example, again suppose that for transactions originating from nodes in `right_dc` you want all nodes in `right_dc` to confirm and any 1 from `left_dc` to confirm before the transaction is committed. Also, again suppose that for transactions originating in `left_dc` you want all nodes in `left_dc` and any 1 in `right_dc` to confirm before the transaction is commited. Above we used these two rules for this when defining `example_scope`:
 
 ```sql
 SELECT bdr.add_commit_scope(
@@ -196,13 +198,14 @@ SELECT bdr.add_commit_scope(
 );
 ```
 
-
 However, using `ORIGIN_GROUP`, just adding and using the following commit scope will have the same effect as the two individual rules we used above in `example_scope`:
 
 ```sql
 SELECT bdr.add_commit_scope(
-    commit_scope_name := 'example_scope_2`,
-    origin_node_group := 'top_group`,
+    commit_scope_name := 'example_scope_2',
+    origin_node_group := 'top_group',
     rule := 'ALL ORIGIN_GROUP GROUP COMMIT (commit_decision=raft) AND ANY 1 NOT ORIGIN_GROUP GROUP COMMIT';
     wait_for_ready := true
 );
+
+With this commit scope, when a transaction originates from `left_dc`, `ORIGIN_GROUP` maps to `left_dc` and `NOT ORIGIN_GROUP` maps to `right_dc`. Likewise, when a transaction originates from `right_dc`, `ORIGIN_GROUP` maps to `right_dc` and `NOT ORIGIN_GROUP` maps to `left_dc`.