diff --git a/modules/ROOT/pages/clauses/filter.adoc b/modules/ROOT/pages/clauses/filter.adoc
index 07142dd9b..c59dd10a6 100644
--- a/modules/ROOT/pages/clauses/filter.adoc
+++ b/modules/ROOT/pages/clauses/filter.adoc
@@ -128,7 +128,7 @@ RETURN n.name AS name, n.age AS age
 `FILTER` and `WHERE` are both used to apply filter to queries.
 However, there are a number of important differences between them that arise from the fact that `FILTER` is a clause and `WHERE` is a subclause:
 
-* While `WHERE` should not be understood as a filter after the matching is finished (it should rather be seen as adding constraints to a described pattern), `FILTER` should be understood as performing post-match filtering, and not as adding constraints to a described patterns.
+* `FILTER` acts on entities _after_ they have been matched, whereas `WHERE` constrains what rows get matched _before_ the match is performed.
 * `FILTER` cannot be used within `MATCH`, `OPTIONAL MATCH`, or `WITH` clauses but only alongside them.
 This means that, unlike `WHERE`, `FILTER` cannot be used to add filters inside patterns.
 
@@ -140,9 +140,9 @@ This `OPTIONAL MATCH` example highlights the differences between the `WHERE` sub
 .`WHERE` constraining an `OPTIONAL MATCH` pattern
 [source, cypher]
 ----
-UNWIND [32,37,40] AS ages
-OPTIONAL MATCH (p:Person)
-WHERE p.age = ages
+UNWIND [32,37,40] AS ageValue
+OPTIONAL MATCH (p:Person) 
+WHERE p.age = ageValue
 RETURN p.name AS name, p.age AS age
 ----
 
@@ -165,10 +165,10 @@ The same is not true if `WHERE` is exchanged for `FILTER`:
 .`FILTER` adding post-filtering to `OPTIONAL MATCH`
 [source, cypher]
 ----
-UNWIND [32,37,40] AS ages
-OPTIONAL MATCH (p:Person)
-FILTER p.age = ages
-RETURN p.name
+UNWIND [32,37,40] AS ageValue
+OPTIONAL MATCH (p:Person) 
+FILTER p.age = ageValue
+RETURN p.name AS name, p.age AS age
 ----
 
 .Result
@@ -183,7 +183,7 @@ RETURN p.name
 |===
 
 Unlike `WHERE`, `FILTER` is not part of the `OPTIONAL MATCH` and so removes entire rows from the result set based on the condition provided within the expression.
-That is, when `OPTIONAL MATCH` fails to find a match and `p` is `NULL`, `FILTER p.age = ages` cannot be evaluated, causing the entire row to be removed.
+That is, when `OPTIONAL MATCH` fails to find a match and `p` is `NULL`, `FILTER p.age = ageValue` cannot be evaluated, causing the entire row to be removed.
 
 =====
 
diff --git a/modules/ROOT/pages/clauses/let.adoc b/modules/ROOT/pages/clauses/let.adoc
index 01a6ad455..1eaae9815 100644
--- a/modules/ROOT/pages/clauses/let.adoc
+++ b/modules/ROOT/pages/clauses/let.adoc
@@ -186,7 +186,7 @@ The fact that `LET` does not drop variables means that it can be used to chain e
 .Chaining expressions: comparing `LET` and `WITH`
 =====
 
-The below query shows that variables bound by a `LET` clause be referenced by subsequent clauses without being explicitly carried over.
+The below query shows that variables bound by a `LET` clause can be referenced by subsequent clauses without being explicitly carried over.
 Specifically, the variable `isExpensive` is created in the first `LET` clause and referenced again in the subsequent clauses.
 Note also that the variable `p`, bound in the `MATCH` clause, is available in the final `RETURN` clause despite not being referenced in any of `LET` clauses.
 
@@ -244,7 +244,7 @@ Unlike `WITH`, `LET` cannot perform aggregations or be combined with `DISTINCT`.
 For example, in the following query, `WITH` could not be replaced by `LET`:
 
 .Combining `WITH DISTINCT` and aggregations on expressions
-[source, source]
+[source, cypher]
 ----
 MATCH (c:Customer)-[:BUYS]->(p:Product)
 WITH DISTINCT c, sum(p.price) AS totalSpent
@@ -268,7 +268,7 @@ RETURN c.firstName AS customer, totalSpent
 |===
 
 .Combining `WITH` and `LET`
-[source, source]
+[source, cypher]
 ----
 MATCH (c:Customer)-[:BUYS]->(p:Product)
 WITH DISTINCT c, sum(p.price) AS totalSpent