diff --git a/cip/1.accepted/CIP2016-12-14-Constraint-syntax.adoc b/cip/1.accepted/CIP2016-12-14-Constraint-syntax.adoc
index f8581aab37..c8954dcf7a 100644
--- a/cip/1.accepted/CIP2016-12-14-Constraint-syntax.adoc
+++ b/cip/1.accepted/CIP2016-12-14-Constraint-syntax.adoc
@@ -70,7 +70,7 @@ The semantics for constraints follow these general rules:
 
 1. The constraint pattern define the constraint _domain_, where all entities that would be returned by a `MATCH` clause with the same pattern constitute the domain, with one notable exception (see <<domain-exception, 3.>>).
 
-2. The constraint expressions defined in the `REQUIRE` clauses of the constraint definition must all evaluate to `true`.
+2. The constraint expressions defined in the `REQUIRE` clauses of the constraint definition must all evaluate to `true`, at all times.
 
 3. [[domain-exception]]Entities for which a constraint expression evaluate to `null` under Cypher's ternary logic are _excluded_ from the constraint domain, even if they fit within the constraint pattern.
 
@@ -78,7 +78,7 @@ The semantics for constraints follow these general rules:
 
 The following list describes the situations in which an error will be raised:
 
-* Attempting to add a constraint on a graph where the data does not comply with the constraint criterion.
+* Attempting to add a constraint on a graph where the data does not comply with a constraint predicate.
 * Attempting to add a constraint with a name that already exists.
 * Attempting to add a constraint that the underlying engine does not support enforcing.
 * Attempting to drop a constraint referencing a non-existent name.
@@ -87,7 +87,7 @@ The following list describes the situations in which an error will be raised:
 ==== Mutability
 
 Once a constraint has been added, it may not be amended.
-Should a user wish to change its definition, it has to be dropped and added anew with an updated structure.
+Should a user wish to change a constraint definition, the constraint has to be dropped and added anew with an updated structure.
 
 [[uniqueness]]
 ==== Uniqueness
@@ -158,7 +158,7 @@ This field contains the constraint definition, which is the contents of the cons
 
 The contents of this field are left unspecified, to be used for implementation-specific messages and/or details.
 
-Consider the following constraint:
+.Example: consider the following constraint:
 [source, Cypher]
 ----
 CREATE CONSTRAINT myConstraint
@@ -300,7 +300,7 @@ REQUIRE acyclic(p)
 === Interaction with existing features
 
 The main interaction between the constraints and the rest of the language occurs during updating statements.
-Existing constraints will cause any updating statements to fail, thereby fulfilling the main purpose of this feature.
+Existing constraints will cause some updating statements to fail, thereby fulfilling the main purpose of this feature.
 
 === Alternatives
 
@@ -368,7 +368,7 @@ ADD CONSTRAINT uc_PersonID UNIQUE (P_Id,LastName)
 Constraints make Cypher's notion of schema more well-defined, allowing users to maintain graphs in a more regular, easier-to-manage form.
 
 Additionally, this specification is deliberately defining a constraint _language_ within which a great deal of possible concrete constraints are made possible.
-This allows different implementers of Cypher to independently choose how to limit the scope of supported constraint expressions that fit their model and targeted use cases.
+This allows different implementers of Cypher to independently choose how to limit the scope of supported constraint expressions that fit their model and targeted use cases, while retaining a common and consistent semantic and syntactic model.
 
 == Caveats to this proposal