diff --git a/product_docs/docs/pgd/5/consistency/conflicts.mdx b/product_docs/docs/pgd/5/consistency/conflicts.mdx
index 4dafa0ca3b3..feca5ee7a32 100644
--- a/product_docs/docs/pgd/5/consistency/conflicts.mdx
+++ b/product_docs/docs/pgd/5/consistency/conflicts.mdx
@@ -212,7 +212,7 @@ The database can clean up the deleted row by the time the `UPDATE` is received i
 
 Another type of `UPDATE`/`DELETE` conflict is when a `DELETE` for a row comes after that row was updated locally. In this situation, the outcome depends on the type of conflict detection used and the replication identity in use. 
 
-When using the default, [origin conflict detection](#origin-conflict-detection) and only primary keys for replication, no conflict is detected, leading to the `DELETE` being applied and the row being removed. 
+When using [origin conflict detection](#origin-conflict-detection) (the default) and only primary keys for replication, no conflict is detected, leading to the `DELETE` being applied and the row being removed. 
 
 If `REPLICA IDENTITY FULL` is being used for replication, the conflict will be detected and a `delete_recently_updated` conflict is generated.