diff --git a/handling-writes/custom-conflict-resolution.mdx b/handling-writes/custom-conflict-resolution.mdx
index 6ea65c7b..ce369b90 100644
--- a/handling-writes/custom-conflict-resolution.mdx
+++ b/handling-writes/custom-conflict-resolution.mdx
@@ -3,9 +3,7 @@ title: "Custom Conflict Resolution"
 description: "Implement custom conflict resolution in PowerSync for concurrent updates from multiple offline clients."
 ---
 
-The default behavior is "**last write wins per field**". Updates to different fields on the same record don't conflict with each other. The server processes operations in the order received, so if two users modify the *same* field, the last update to reach the server wins.
-
-For most apps, this works fine. But some scenarios demand more complex conflict resolution strategies.
+See [Handling Update Conflicts](/handling-writes/handling-update-conflicts) for basic guidance on how to handle conflicts. For most apps, the approaches documented there are fine. But some scenarios demand more complex conflict resolution strategies.
 
 ## When You Might Need Custom Conflict Resolution
 
diff --git a/handling-writes/handling-update-conflicts.mdx b/handling-writes/handling-update-conflicts.mdx
index 447caaf9..208976e4 100644
--- a/handling-writes/handling-update-conflicts.mdx
+++ b/handling-writes/handling-update-conflicts.mdx
@@ -1,9 +1,11 @@
 ---
 title: "Handling Update Conflicts"
-description: "Understand how PowerSync resolves conflicts when multiple users update the same records while offline."
+description: "Understand what happens when multiple users update the same records while offline."
 ---
 
-**The default behavior is essentially "last write wins", but this can be** [**customized by the developer**](/handling-writes/custom-conflict-resolution)**.**
+By design PowerSync is unopinionated when it comes to handling conflicts on the backend. On the client, mutations are stored in an "upload queue" - an ordered log of mutations. This upload queue must be sequentially drained against backend API endpoints configured by the developer.  The developer's app backend therefore dictates how mutations from clients are processed and applied against the source database. PowerSync then replicates and syncs those mutations back to the client. This is known as server-authoritative reconcilliation. 
+
+In the simplest backend implementation, the behavior of the overall system will be per-field Last-Write-Wins (LWW). However, this can be [customized](/handling-writes/custom-conflict-resolution).
 
 The upload queue on the client stores three types of operations:
 
@@ -17,7 +19,7 @@ The operations must be idempotent — i.e. the backend may receive the same oper
 
 * A per-client incrementing operation ID is included with each operation that can be used to deduplicate operations, and/or the backend can implement the operations in an idempotent way (e.g. ignore DELETE on a row that is already deleted).
 
-A conflict may arise when two clients update the same record before seeing the other client’s update, or one client deletes the record while the other updates it.
+A conflict may arise when two clients update the same field on the same record before seeing the other client’s update, or one client deletes the record while the other updates it.
 
 Typically, the backend should be implemented to handle writes as follows: