fix: typos (#719)

blog/conditional-tuples-announcement.md

@@ -60,7 +60,7 @@ You'll get the following results for the [ListObjects](https://openfga.dev/api/s
 
 Note that:
 
-- `user:bob` will always get `allowed:true` as we has assigned as as viewer unconditionally.
+- `user:bob` will always get `allowed:true` as we have assigned as viewer unconditionally.
 - `user:anne` will get `allowed:true` if the `current_time` is before the `grant_time` + `grant_duration` and `allowed:false` otherwise.
 - If you don't provide the `current_time` in the context, the Check and ListObjects operations will fail.
 

docs/content/authorization-concepts.mdx

@@ -48,7 +48,7 @@ ReBAC also lets you natively solve for ABAC when attributes can be expressed in
 
 <ProductName format={ProductNameFormat.ShortForm}/> extends ReBAC by making it simpler to express additional ABAC scenarios using [Conditions](./modeling/conditions.mdx) or [Contextual Tuples](./modeling/token-claims-contextual-tuples.mdx).
 
-ReBAC can also be consided PBAC, as authorization policies are centralized.
+ReBAC can also be considered PBAC, as authorization policies are centralized.
 
 ## What is Zanzibar?
 

docs/content/concepts.mdx

@@ -584,7 +584,7 @@ The list objects endpoint responds with a list of objects for a given type that
 For example, the following returns all the objects with document type for which `anne` of type user has a `viewer` relation with:
 
 <ListObjectsRequestViewer
-  authorizationModelId="1uHxCSuTP0VKPYSnkq1pbb1jeZw"
+  authorizationModelId="01HVMMBCMGZNT3SED4Z17ECXCA"
   objectType="document"
   relation="viewer"
   user="user:anne"

docs/content/configuration-language.mdx

@@ -388,7 +388,7 @@ Above, `document` <ProductConcept section="what-is-a-type-definition" linkName="
 
 :::info
 
-`can_rename` does not reference the [direct relationship type restrictions](#the-direct-relationship-type-restrictions), which means a user cannot be directly assigned this relation and it must inherited when the `editor` relation is assigned. Conversely, the `viewer` relation allows both direct and indirect relationships using the [Union Operator](#the-union-operator).
+`can_rename` does not reference the [direct relationship type restrictions](#the-direct-relationship-type-restrictions), which means a user cannot be directly assigned this relation and it must be inherited when the `editor` relation is assigned. Conversely, the `viewer` relation allows both direct and indirect relationships using the [Union Operator](#the-union-operator).
 
 :::
 
@@ -1013,7 +1013,7 @@ The following snippet:
                   },
                 },
                 {
-                  // a user that is an viewer on any of the object's parents is also implicitly a viewer on the object
+                  // a user that is a viewer on any of the object's parents is also implicitly a viewer on the object
                   tupleToUserset: {
                     tupleset: {
                       relation: 'parent',

docs/content/getting-started/create-store.mdx

@@ -18,7 +18,7 @@ import TabItem from '@theme/TabItem';
 
 A [store](../concepts.mdx#what-is-a-store) is a OpenFGA entity that contains your authorization data. You will need to create a store in OpenFGA before adding an [authorization model](../concepts.mdx#what-is-an-authorization-model) and [relationship tuples](../concepts.mdx#what-is-a-relationship-tuple) to it.
 
-This article explains how to setup an OpenFGA store.
+This article explains how to set up an OpenFGA store.
 
 ## Step By Step
 

docs/content/getting-started/immutable-models.mdx

@@ -25,7 +25,7 @@ You can list all the authorization models for a store using the [ReadAuthorizati
 
 Some endpoints relating to tuples ([Check](/api/service#/Relationship%20Queries/Check), [ListObjects](/api/service#/Relationship%20Queries/ListObjects), [Expand](/api/service#/Relationship%20Queries/Expand), [Write](/api/service#/Relationship%20Tuples/Write)) accept an `authorization_model_id`, which we strongly recommend passing, especially in production.
 
-In practice, you would pin the authorization model ID alongside the store ID in your configuration management system. Your services would read this value and use it in their requests to FGA. This helps you ensure that your services are using the same consistent ID across all your applications, and that rollouts can be seemless.
+In practice, you would pin the authorization model ID alongside the store ID in your configuration management system. Your services would read this value and use it in their requests to FGA. This helps you ensure that your services are using the same consistent ID across all your applications, and that rollouts can be seamless.
 
 ### Benefits of Passing in an Authorization Model ID
 

docs/content/getting-started/overview.mdx

@@ -9,7 +9,7 @@ import { DocumentationNotice, IntroCard, CardGrid, ProductName } from '@componen
 
 <DocumentationNotice />
 
-The following will provide a step by step guide on how to get started with <ProductName />.
+The following will provide a step-by-step guide on how to get started with <ProductName />.
 
 <IntroCard
   title="When to use"

docs/content/getting-started/perform-list-objects.mdx

@@ -145,7 +145,7 @@ To obtain the [access token](https://auth0.com/docs/get-started/authentication-a
 To return all documents that user `user:anne` has relationship `reader` with:
 
 <ListObjectsRequestViewer
-  authorizationModelId="1uHxCSuTP0VKPYSnkq1pbb1jeZw"
+  authorizationModelId="01HVMMBCMGZNT3SED4Z17ECXCA"
   objectType="document"
   relation="reader"
   user="user:anne"
@@ -165,7 +165,7 @@ To return all documents that user `user:anne` has relationship `reader` with:
 The result `document:otherdoc` and `document:planning` are the document objects that `user:anne` has `reader` relationship with.
 
 :::caution Warning
-The performance characteristics of the ListObjects endpoint vary drastically depending on the model complexity, number of tuples, and the relations it needs to evaluate. Relations with 'and' or 'but not' are more expensive to evaluate than relations with 'or'."
+The performance characteristics of the ListObjects endpoint vary drastically depending on the model complexity, number of tuples, and the relations it needs to evaluate. Relations with 'and' or 'but not' are more expensive to evaluate than relations with 'or'.
 :::
 
 ## Related Sections

docs/content/getting-started/setup-openfga/configure-openfga.mdx

@@ -47,7 +47,7 @@ authn:
 ## Using environment variables
 
 The OpenFGA server supports **environment variables** for configuration, and they will take priority over your configuration file.
-Each variable must be prefixed with `OPENFGA_` and followed by your option in uppercase (e.g `--grpc-tls-key` becomes `OPENFGA_GRPC_TLS_KEY`).
+Each variable must be prefixed with `OPENFGA_` and followed by your option in uppercase (e.g. `--grpc-tls-key` becomes `OPENFGA_GRPC_TLS_KEY`).
 
 ## Using command line variables
 
@@ -81,7 +81,7 @@ openfga run
     --datastore-uri 'postgres://postgres:password@postgres:5432/postgres?sslmode=disable'
 ```
 
-To learn how to run in in Docker, check our [Docker documentation](./docker-setup.mdx#using-postgres).
+To learn how to run in Docker, check our [Docker documentation](./docker-setup.mdx#using-postgres).
 ### MySQL
 
 The MySQL datastore has stricter limits for the max length of some fields for tuples compared to other datastore engines, in particular:
@@ -102,7 +102,7 @@ openfga run \
     --datastore-uri 'root:secret@tcp(mysql:3306)/openfga?parseTime=true'
 ```
 
-To learn how to run in in Docker, check our [Docker documentation](./docker-setup.mdx#using-mysql).
+To learn how to run in Docker, check our [Docker documentation](./docker-setup.mdx#using-mysql).
 
 ## Configuring Authentication
 
@@ -150,7 +150,7 @@ http:
 </TabItem>
 </Tabs>
 
-To learn how to run in in Docker, check our [Docker documentation](./docker-setup.mdx#pre-shared-key-authentication).
+To learn how to run in Docker, check our [Docker documentation](./docker-setup.mdx#pre-shared-key-authentication).
 
 ### OIDC
 
@@ -196,7 +196,7 @@ http:
 
 </Tabs>
 
-To learn how to run in in Docker, check our [Docker documentation](./docker-setup.mdx#oidc-authentication).
+To learn how to run in Docker, check our [Docker documentation](./docker-setup.mdx#oidc-authentication).
 
 ## Profiler (pprof)
 :::caution Warning

docs/content/getting-started/setup-openfga/overview.mdx

@@ -11,7 +11,7 @@ import {
 } from "@components/Docs";
 
 # Setup OpenFGA
-Follow the guides below to setup an OpenFGA server.
+Follow the guides below to set up an OpenFGA server.
 
 <DocumentationNotice />
 

docs/content/getting-started/setup-openfga/playground.mdx

@@ -10,7 +10,7 @@ The Playground facilitates rapid development by allowing you to visualize and mo
 
 It is enabled on port 3000 by default and accessible at http://localhost:3000/playground. 
 
-The Playground is designed for early prototyping and learning. It has serveral limitations:
+The Playground is designed for early prototyping and learning. It has several limitations:
 
 - It works by embedding the public [Playground website](https://play.fga.dev) in an `<iframe>`. To do this securely, the public Playground configures its Content Security Policies to enable running it from `localhost`. **You can't run the Playground in a host different than `localhost`.
 - It does not support OIDC authentication. 

docs/content/getting-started/tuples-api-best-practices.mdx

@@ -35,7 +35,7 @@ It is strongly recommended that authorization model ID be specified in your Rela
 
 Specifying authorization model ID in API calls have the following advantages:
 1. Better performance as <ProductName format={ProductNameFormat.ShortForm}/> will not need to perform a database query to get the latest authorization model ID.
-2. Allows consistent behavior in your production system until until you are ready to switch to the new model.
+2. Allows consistent behavior in your production system until you are ready to switch to the new model.
 
 ## Related Sections
 

docs/content/interacting/relationship-queries.mdx

@@ -287,7 +287,7 @@ It provides a solution to the [Search with Permissions (Option 3)](./search-with
 Use the ListObjects API to get what objects a user can see based on the relationships they have. See [Search with Permissions](./search-with-permissions.mdx) for more guidance.
 
 <ListObjectsRequestViewer
-  authorizationModelId="1uHxCSuTP0VKPYSnkq1pbb1jeZw"
+  authorizationModelId="01HVMMBCMGZNT3SED4Z17ECXCA"
   objectType="document"
   relation="reader"
   user="user:bob"

docs/content/modeling/advanced/github.mdx

@@ -402,7 +402,7 @@ To add support for teams and memberships all we need to do is add this object to
   }}
 />
 
-In addition, the repo's relations should be add team member as a directly related user types.
+In addition, the repo's relations should have team member as a directly related user types.
 
 <AuthzModelSnippetViewer
   configuration={{
@@ -714,7 +714,7 @@ We can now make Erik a member of contoso and make contoso own **contoso/tooling*
   ]}
 />
 
-What we still lack is the ability to create "default permissions" for the organization and have those be considered when determining if a user has a particular relation to a repository. Let's start with the simplest case **admin**. We want to say that a user is a admin of a repo if either:
+What we still lack is the ability to create "default permissions" for the organization and have those be considered when determining if a user has a particular relation to a repository. Let's start with the simplest case **admin**. We want to say that a user is an admin of a repo if either:
 
 - [done] they have a repo admin relation (directly or through team membership)
 - [pending] their organization is configured with **repo_admin** as the base permission

docs/content/modeling/blocklists.mdx

@@ -206,7 +206,7 @@ Now we can add relationship tuples indicating that a certain user is `blocked` f
 
 ### 02. Modify Our Model So Users Who Are Blocked Can No Longer Edit The Document
 
-Now that we can mark users as `blocked` from editing documents, we need to support denying the `editor` relationship when a user is `blocked`. We do that by modifying the relation definition of `editor`, and making use of the [**the exclusion operator**](../configuration-language.mdx#the-exclusion-operator) to exclude the set of `blocked` users, as we can see here:
+Now that we can mark users as `blocked` from editing documents, we need to support denying the `editor` relationship when a user is `blocked`. We do that by modifying the relation definition of `editor`, and making use of the [**exclusion operator**](../configuration-language.mdx#the-exclusion-operator) to exclude the set of `blocked` users, as we can see here:
 
 <AuthzModelSnippetViewer
   configuration={{

docs/content/modeling/building-blocks/usersets.mdx

@@ -118,7 +118,7 @@ Imagine the following authorization model:
                   this: {},
                 },
                 {
-                  // a user who is related as an writer is also implicitly related as a reader
+                  // a user who is related as a writer is also implicitly related as a reader
                   computedUserset: {
                     relation: 'writer',
                   },

docs/content/modeling/conditions.mdx

@@ -186,7 +186,7 @@ but if the current time is outside the grant window then you get a deny decision
   ]}
 />
 
-Similarly, we can use the [ListObjects API](https://openfga.dev/api/service#/Relationship%20Queries/ListObjects) to return all of the documents that `user:anne` has viewer access to given the current time. For example,
+Similarly, we can use the [ListObjects API](https://openfga.dev/api/service#/Relationship%20Queries/ListObjects) to return all of the documents that `user:anne` has viewer access given the current time. For example,
 
 <ListObjectsRequestViewer
   objectType="document"
@@ -260,8 +260,8 @@ Note that some of the types support generics, these types are indicated with `<T
 ## Limitations
 * The size of the condition `context` parameter that can be written alongside a relationship tuple is limited to 32KB in size.
 
-* The size of the condition `context` parameter for query requests (e.g. Check, ListObjects, etc..) is not explicitly limited, but the OpenFGA server has an overall request size limit of 512KB at this time.
+* The size of the condition `context` parameter for query requests (e.g. Check, ListObjects, etc.) is not explicitly limited, but the OpenFGA server has an overall request size limit of 512KB at this time.
 
-* We're still working on the changes to support Conditions in the official FGA CLI and various OpenFGA SDKs including: .NET and Python. At this moment you cannot Write conditional relationship tuples with these tools and/or query (e.g. Check, ListObjects, etc..) OpenFGA with condition context.
+* We're still working on the changes to support Conditions in the official FGA CLI and various OpenFGA SDKs including: .NET and Python. At this moment you cannot Write conditional relationship tuples with these tools and/or query (e.g. Check, ListObjects, etc.) OpenFGA with condition context.
 
 * We enforce a maximum Google CEL expression evaluation cost of 100 (by default) to protect the server from malicious conditions. The evaluation cost of a CEL expression is a function of the size the input that is being compared and the composition of the expression. For more general information please see the official [Language Definition for Google CEL](https://github.com/google/cel-spec/blob/master/doc/langdef.md). If you hit these limits with practical use-cases, please reach out to the maintainer team and we can discuss.

docs/content/modeling/getting-started.mdx

@@ -582,7 +582,7 @@ Why? This relation definition states:
   `{ user: {user-id}, relation: "member", object: "organization:{id}" }`
 
 :::info Important
-Relation definitions of the form “define \{relation\}: [user, organization#member]" are fairly common. They are used to express that relationships "to the object with that relation" (e.g. "users" of type user or "member of organization") can be assigned by your system and that only the users that have that relation are those with a [direct relationship](./building-blocks/direct-relationships.mdx).
+Relation definitions of the form "define \{relation\}: [user, organization#member]" are fairly common. They are used to express that relationships "to the object with that relation" (e.g. "users" of type user or "member of organization") can be assigned by your system and that only the users that have that relation are those with a [direct relationship](./building-blocks/direct-relationships.mdx).
 :::
 
 You can read more about group membership and types in [Modeling User Groups](./user-groups.mdx).
@@ -644,7 +644,7 @@ The complete <ProductConcept section="what-is-a-type-definition" linkName="type
 
 After defining your "group" like types, continue with the most important type for the feature: the one that allows the main use case. In this case "document", since the main use case for users is to create, write, read and collaborate on documents.
 
-Defining relations for the main type lets you to focus on your core use case, and will likely make other type definitions easier.
+Defining relations for the main type lets you focus on your core use case, and will likely make other type definitions easier.
 
 ##### Relation: Owner
 

docs/content/modeling/migrating/migrating-relations.mdx

@@ -31,7 +31,7 @@ This guide assumes you are familiar with the following OpenFGA concepts:
 - A <ProductConcept section="what-is-a-type" linkName="Type" />: a class of objects that have similar characteristics
 - A <ProductConcept section="what-is-a-user" linkName="User" />: an entity in the system that can be related to an object
 - A <ProductConcept section="what-is-a-relation" linkName="Relation" />: is a string defined in the type definition of an authorization model that defines the possibility of a relationship between an object of the same type as the type definition and a user in the system
-- An <ProductConcept section="what-is-an-object" linkName="Object" />: represents an entity in the system. Users' relationships to it can be define through relationship tuples and the authorization model
+- An <ProductConcept section="what-is-an-object" linkName="Object" />: represents an entity in the system. Users' relationships to it can be defined through relationship tuples and the authorization model
 - A <ProductConcept section="what-is-a-relationship-tuple" linkName="Relationship Tuple" />: a grouping consisting of a user, a relation and an object stored in <ProductName format={ProductNameFormat.ShortForm} />
 - [Intersection Operator](../../configuration-language.mdx#the-intersection-operator): the intersection operator can be used to indicate a relationship exists if the user is in all the sets of users
 
@@ -209,7 +209,7 @@ Run a check in the API for Bethany to ensure correct access.
 
 Next, migrate the existing relationship tuples. The new relation makes this definition obsolete.
 
-Use the `read` API to lookup all relationship tuples.
+Use the `read` API to look up all relationship tuples.
 
 <ReadRequestViewer
   tuples={[

docs/content/modeling/modular-models.mdx

@@ -50,7 +50,7 @@ Currently, modules are stored as metadata but are not used by <ProductName forma
 
 ### Type Extensions
 
-As teams implement features, they might find that core types they are dependent upon might not contain all the realtions they need. However, it might not make sense for these relations to be owned by the owner of that type if they aren't needed across the system.
+As teams implement features, they might find that core types they are dependent upon might not contain all the relations they need. However, it might not make sense for these relations to be owned by the owner of that type if they aren't needed across the system.
 
 To solve this, individual types can be extended within other modules to implement the relations needed.
 
@@ -62,11 +62,11 @@ In order to allow this, there are certain requirements for type extension:
 
 ## Example
 
-In this example we'll look at how an authorization model for a SaaS compny with a issue tracking and wiki software could implement modular models.
+In this example we'll look at how an authorization model for a SaaS company with an issue tracking and wiki software could implement modular models.
 
 ### Core
 
-It's likely there will be a core set of types owned by a team that manages the overall identity for the company, this would provide the basics usch as users, organizations and groups that can be used by each respective product area.
+It's likely there will be a core set of types owned by a team that manages the overall identity for the company, this would provide the basics such as users, organizations and groups that can be used by each respective product area.
 
 ```dsl.openfga
 module core
@@ -141,7 +141,7 @@ schema: '1.2'
 contents:
   - core.fga
   - issue-tracker/projects.fga
-  - issue-tracker//tickets.fga
+  - issue-tracker/tickets.fga
   - wiki.fga
 ```