diff --git a/docs/content/configuration-language.mdx b/docs/content/configuration-language.mdx
index 6c9e5d1ca..cedbb829b 100644
--- a/docs/content/configuration-language.mdx
+++ b/docs/content/configuration-language.mdx
@@ -23,7 +23,7 @@ import {
 
 <DocumentationNotice />
 
-<ProductName format={ProductNameFormat.LongForm}/>'s Configuration Language builds a representation of a system's <ProductConcept section="what-is-an-authorization-model" linkName="authorization model" />, which informs <UpdateProductNameInLinks link="/api/service" name="{ProductName}'s API" /> on the <ProductConcept section="what-is-a-type" linkName="object types" /> in the system are and how they relate to each other. The Configuration Language describes the <ProductConcept section="what-is-a-relation" linkName="relations" /> possible for an object of a given type and lists the conditions under which one is related to that object.
+<ProductName format={ProductNameFormat.LongForm}/>'s Configuration Language builds a representation of a system's <ProductConcept section="what-is-an-authorization-model" linkName="authorization model" />, which informs <UpdateProductNameInLinks link="/api/service" name="{ProductName}'s API" /> on the <ProductConcept section="what-is-a-type" linkName="object types" /> in the system and how they relate to each other. The Configuration Language describes the <ProductConcept section="what-is-a-relation" linkName="relations" /> possible for an object of a given type and lists the conditions under which one is related to that object.
 
 The Configuration Language can be presented in **DSL** or **JSON** syntax. The JSON syntax is accepted by the API and closely tracks the language in the [Zanzibar paper](https://research.google/pubs/pub48190/). The DSL adds syntactic sugar on top of JSON for ease of use, but compiles down to JSON before being sent to <ProductName format={ProductNameFormat.ShortForm}/>'s API. JSON syntax is used to call API directly or through the [SDKs](./getting-started), while DSL is used to interact with <ProductName format={ProductNameFormat.ShortForm}/> in the [Playground](https://play.fga.dev/), and they can be switched between throughout this documentation. 
 
diff --git a/docs/content/intro.mdx b/docs/content/intro.mdx
index 55f1688e0..d1ed91bfc 100644
--- a/docs/content/intro.mdx
+++ b/docs/content/intro.mdx
@@ -17,7 +17,7 @@ Inspired by [Google’s Zanzibar](https://zanzibar.academy), Google’s internal
 <ProductName format={ProductNameFormat.ShortForm}/> provides developer the following benefits:
 
 - Move authorization logic outside of application code, making it easier to write, change and audit
-- Increase velocity by standardizing on a single authorization solution.
+- Increase velocity by standardizing on a single authorization solution
 - Centralize authorization decisions and audit logs making it simpler to comply with security and compliance requirements
 - Help their products to move faster because it is simpler to evolve authorization policies
 
diff --git a/docs/content/modeling/direct-access.mdx b/docs/content/modeling/direct-access.mdx
index 4ce18197c..a1ac0d7f8 100644
--- a/docs/content/modeling/direct-access.mdx
+++ b/docs/content/modeling/direct-access.mdx
@@ -113,7 +113,7 @@ Once you add that relationship tuple to <ProductName format={ProductNameFormat.S
 
 <CheckRequestViewer user={'user:bob'} relation={'editor'} object={'document:meeting_notes.doc'} allowed={true} />
 
-Checking whether `bob` is an `editor` of `document:meeting_notes.doc` returns **false** because that relationship tuple does not exist in <ProductName format={ProductNameFormat.ShortForm}/> yet.
+Checking whether `bob` is an `viewer` of `document:meeting_notes.doc` returns **false** because that relationship tuple does not exist in <ProductName format={ProductNameFormat.ShortForm}/> yet.
 
 <CheckRequestViewer user={'user:bob'} relation={'viewer'} object={'document:meeting_notes.doc'} allowed={false} />
 
diff --git a/docs/content/modeling/getting-started.mdx b/docs/content/modeling/getting-started.mdx
index d58618add..193a4b998 100644
--- a/docs/content/modeling/getting-started.mdx
+++ b/docs/content/modeling/getting-started.mdx
@@ -370,7 +370,7 @@ In those cases [**User** should also be an object type](./building-blocks/object
 
 Each of the previously defined types has a set of relations. <ProductConcept section="what-is-a-relation" linkName="Relations" /> are an important component in your model. After all, <ProductName format={ProductNameFormat.ShortForm}/> is a <IntroductionSection linkName="Relationship Based Access Control (ReBAC)" section="what-is-relationship-based-access-control-rebac"/> system.
 
-To identify relations for a type we in the write-up we can perform an exercise similar to the one we did in [list the type of objects in your system](#02-list-the-object-types).
+To identify relations for a type in the write-up we can perform an exercise similar to the one we did in [list the type of objects in your system](#02-list-the-object-types).
 
 Relations for a type \{type\} will be all of these:
 
@@ -594,7 +594,7 @@ For the direct relationships, we need to figure out the object types that makes
 
 However, it will not make sense for organization member's user to be of type document, folder or drive.
 
-We will specify this logic as part of directly <ProductConcept section="what-is-a-directly-related-user-type" linkName="directly related user type" />.
+We will specify this logic as part of <ProductConcept section="what-is-a-directly-related-user-type" linkName="directly related user type" />.
 
 :::note Side note
 This also automatically supports nested organizational membership if you want such a feature in your system. You could use relationship tuples like the following one to express that "members of organization A are members of organization B":