diff --git a/modules/ROOT/pages/clustering/databases.adoc b/modules/ROOT/pages/clustering/databases.adoc
index 4b80003f8..b526cfba9 100644
--- a/modules/ROOT/pages/clustering/databases.adoc
+++ b/modules/ROOT/pages/clustering/databases.adoc
@@ -100,6 +100,7 @@ In this example, the `server01` member is used.
 neo4j@neo4j$ ./bin/neo4j-admin database restore --from-path=/path/to/foo-backup-dir foo
 ----
 . Find the server ID of `server01` by logging in to Cypher Shell and running `SHOW SERVERS`.
+Cross-reference the address to find the server ID.
 Use any database to connect.
 +
 [source, cypher, role=noplay]
@@ -117,6 +118,8 @@ SHOW SERVERS;
 | "8512c9b9-d9e8-48e6-b037-b15b0004ca18" | "localhost:7687" | "Enabled" | "Available" | ["system",  "neo4j"] |
 +------------------------------------------------------------------------------------------------------------+
 ----
+In this case, the address for `server01` is `localhost:7687` and thus, the server ID is `8512c9b9-d9e8-48e6-b037-b15b0004ca18`.
++
 . On one of the servers, use the `system` database and create the database `foo` using the server ID of `server01`.
 +
 [source, cypher, role=noplay]
@@ -149,9 +152,9 @@ SHOW DATABASE foo;
 
 This method seeds all servers with an identical seed from an external source, specified by the URI.
 The seed can be either a backup or a dump from an existing database.
+The sources of seeds are called _seed providers_.
 
-The mechanism is pluggable, allowing new sources of seeds to be supported.
-These are called _seed providers_.
+The mechanism is pluggable, allowing new sources of seeds to be supported (see link:https://www.neo4j.com/docs/java-reference/current/extending-neo4j/project-setup/#extending-neo4j-plugin-seed-provider[Java Reference -> Implement custom seed providers] for more information).
 The product has built-in support for seed from a mounted file system (file), FTP server, HTTP/HTTPS server and Amazon S3.
 
 [NOTE]
diff --git a/modules/ROOT/pages/clustering/introduction.adoc b/modules/ROOT/pages/clustering/introduction.adoc
index fb549d012..065274ecf 100644
--- a/modules/ROOT/pages/clustering/introduction.adoc
+++ b/modules/ROOT/pages/clustering/introduction.adoc
@@ -45,7 +45,7 @@ The remainder of this section assumes a database has multiple primaries.
 Database primaries achieve high availability by replicating all transactions using the Raft protocol.
 Raft ensures that the data is safely durable by waiting for a majority of primaries in a database (N/2+1) to acknowledge a transaction, before acknowledging its commit to the end user application.
 In practice, only one of the multiple primaries execute write transactions from clients.
-This writer is elected automatically from amongst a database’s primaries and may change over time.
+This writer is elected automatically from amongst a database's primaries and may change over time.
 The writer primary synchronously replicates writes to the other primaries.
 The database secondaries replicates the writes asynchronously from more up-to-date members of the cluster.
 
@@ -101,7 +101,7 @@ Consequently, client applications are guaranteed to read their own writes, regar
 This simplifies interaction with large clusters, allowing clients to treat them as a single (logical) server.
 ====
 
-Causal consistency makes it possible to write to databases hosted on servers in primary mode (where data is safe) and read those writes from databases hosted on servers in secondary mode (where graph operations are scaled out).
+Causal consistency makes it possible to write to databases hosted on servers in primary mode and read those writes from databases hosted on servers in secondary mode (where graph operations are scaled out).
 For example, causal consistency guarantees that the write which created a user account is present when that same user subsequently attempts to log in.
 
 //image::causal-clustering-drivers.svg[title="Cluster setup with causal consistency via Neo4j drivers", role="middle"]