diff --git a/content/docs/learn/design/domain-modeling.md b/content/docs/learn/design/domain-modeling.md
index f995c92c..e992c535 100644
--- a/content/docs/learn/design/domain-modeling.md
+++ b/content/docs/learn/design/domain-modeling.md
@@ -56,7 +56,7 @@ data class Event(
 )
 ```
 
-If we go back to our previous example, the compiler now fails to compile since we pass `Organizer ` where `Title` is expected, `Description` where `Organizer` is expected, and so on.
+If we go back to our previous example, the compiler now fails to compile since we pass `Organizer` where `Title` is expected, `Description` where `Organizer` is expected, and so on.
 
 ```kotlin
 Event(
@@ -87,7 +87,7 @@ Using an `enum class` is much more powerful than `String` for reasons beyond the
 So it's much easier to reason about `AgeRestriction` than to reason and work with `String`.
 
 In functional programming, this type of data composition is also known as a **sum type**, which models an _or_ relationship.
-So we can say that an `AgeRestriction `is either `General` _or_ `PG` _or_ `PG13` _or_ `Restricted` _or_ `NC17`.
+So we can say that an `AgeRestriction` is either `General` _or_ `PG` _or_ `PG13` _or_ `Restricted` _or_ `NC17`.
 This tells us much more than if it was just a `String`. A `String` would have infinite values, while `AgeRestriction` modeled as an `enum class` only has five different values.
 So using sum types can drastically reduce the complexity of our types.
 
diff --git a/content/docs/learn/typed-errors/working-with-typed-errors.md b/content/docs/learn/typed-errors/working-with-typed-errors.md
index aecaee14..6f8a058a 100644
--- a/content/docs/learn/typed-errors/working-with-typed-errors.md
+++ b/content/docs/learn/typed-errors/working-with-typed-errors.md
@@ -534,7 +534,7 @@ fun example() {
 <!--- KNIT example-typed-errors-12.kt -->
 <!--- TEST assert -->
 
-The type system now tracks that a new error of `OtherError` might have occurred, but we recovered from any possible errors of `UserNotFound `. This is useful across application layers or in the service layer, where we might want to `recover` from a `DatabaseError` with a `NetworkError` when we want to load data from the network when a database operation failed.
+The type system now tracks that a new error of `OtherError` might have occurred, but we recovered from any possible errors of `UserNotFound`. This is useful across application layers or in the service layer, where we might want to `recover` from a `DatabaseError` with a `NetworkError` when we want to load data from the network when a database operation failed.
 To achieve the same with the `Raise` DSL, we need to be inside the context of `Raise<OtherError>` to `raise` it.
 
 <!--- INCLUDE
@@ -653,7 +653,7 @@ If we want to accumulate all the errors, we can use `mapOrAccumulate` on `Iterab
 
 Since you have potentially more than one failure, the error type in `Either` must be some sort of list.
 However, we know that if we are not in the happy path, then _at least one_ error must have occurred.
-Arrow makes this fact explicit by making the return type of `mapOrAccumulate ` a `NonEmptyList`, or `Nel` for short.
+Arrow makes this fact explicit by making the return type of `mapOrAccumulate` a `NonEmptyList`, or `Nel` for short.
 
 :::