diff --git a/proposals/1954-remove-prev_event-from-essential-keys-list.md b/proposals/1954-remove-prev_event-from-essential-keys-list.md
index 1cd0fd361..735fac012 100644
--- a/proposals/1954-remove-prev_event-from-essential-keys-list.md
+++ b/proposals/1954-remove-prev_event-from-essential-keys-list.md
@@ -48,7 +48,7 @@ retrospectively to describe the de-facto redaction algorithm.
 ## Potential issues
 
 It is theoretically possible that a closed federation could exist whose servers
-do follow the spec as is. This MSC would render those servers uncompliant with
+do follow the spec as is. This MSC would render those servers non-compliant with
 the spec. On balance this seems unlikely and in the worst case those
 implementors could add the change to a subsequent room version, eventually
 reaching spec consistency as older room versions are deprecated.
@@ -57,8 +57,8 @@ Another scenario is that a client may redact events according to the spec as is
 and persist prev_content through the redaction, thereby diverting from that on
 the server(s). Client authors will have to update their code to drop
 ```prev_content``` - however, given that prev_content should not be used in
-important calculations and/or visualisations, this ought to be relatively
-uninvaisive change.
+important calculations and/or visualisations, this ought to be a relatively
+non-invasive change.
 
 
 ## Security considerations