diff --git a/docs/content/docs/concepts/application-building-blocks.md b/docs/content/docs/concepts/application-building-blocks.md
index d82ca23..996a314 100644
--- a/docs/content/docs/concepts/application-building-blocks.md
+++ b/docs/content/docs/concepts/application-building-blocks.md
@@ -26,7 +26,7 @@
 
 # Application Building Blocks
 
-Stateful Functions provides a framework for building event drivent applications. Here, we explain important aspects of Stateful Function’s architecture.
+Stateful Functions provides a framework for building event driven applications. Here, we explain important aspects of Stateful Function’s architecture.
 
 ## Event Ingress
 
@@ -36,7 +36,7 @@
 
 
 In Stateful Functions, the component that ingests records into the system is called an event ingress.
-This can be anything from a Kafka topic, to a messsage queue, to an http request - anything that can get data into the system and trigger the intitial functions to begin computation.
+This can be anything from a Kafka topic, to a message queue, to an http request - anything that can get data into the system and trigger the initial functions to begin computation.
 
 ## Stateful Functions
 
@@ -63,7 +63,7 @@
 
 ### Fault Tolerance
 
-For both state and messaging, Stateful Functions is able to provide the exactly-once guarantees users expect from a modern data processessing framework.
+For both state and messaging, Stateful Functions is able to provide the exactly-once guarantees users expect from a modern data processing framework.
 
 {{< img width="80%" src="/fig/concepts/statefun-app-fault-tolerance.svg" >}}
 
diff --git a/docs/content/docs/concepts/distributed_architecture.md b/docs/content/docs/concepts/distributed_architecture.md
index 3c64181..bebdf99 100644
--- a/docs/content/docs/concepts/distributed_architecture.md
+++ b/docs/content/docs/concepts/distributed_architecture.md
@@ -47,7 +47,7 @@
 
 ## Logical Co-location, Physical Separation
 
-A core principle of many Stream Processors is that application logic and the application state must be co-located. That approach is the basis for their out-of-the box consistency. Stateful Functions takes a unique approach to that by *logically co-locating* state and compute, but allowing to *physically separate* them.
+A core principle of many Stream Processors is that application logic, and the application state must be co-located. That approach is the basis for their out-of-the box consistency. Stateful Functions takes a unique approach to that by *logically co-locating* state and compute, but allowing to *physically separate* them.
 
   - *Logical co-location:* Messaging, state access/updates and function invocations are managed tightly together, in the same way as in Flink's DataStream API. State is sharded by key, and messages are routed to the state by key. There is a single writer per key at a time, also scheduling the function invocations.
 
@@ -60,7 +60,7 @@
 
 #### Remote Functions
 
-*Remote Functions* use the above-mentioned principle of *physical separation* while maintaining *logical co-location*. The state/messaging tier (i.e., the Flink processes) and the function tier are deployed, managed, and scaled independently.
+*Remote Functions* use the above-mentioned principle of *physical separation* while maintaining *logical co-location*. The state/messaging tier (i.e., the Flink processes), and the function tier are deployed, managed, and scaled independently.
 
 Function invocations happen through an HTTP / gRPC protocol and go through a service that routes invocation requests to any available endpoint, for example a Kubernetes (load-balancing) service, the AWS request gateway for Lambda, etc. Because invocations are self-contained (contain message, state, access to timers, etc.) the target functions can be treated like any stateless application.
 
diff --git a/docs/content/docs/concepts/logical.md b/docs/content/docs/concepts/logical.md
index 20f08f4..babf3f9 100644
--- a/docs/content/docs/concepts/logical.md
+++ b/docs/content/docs/concepts/logical.md
@@ -28,7 +28,7 @@
 
 Stateful Function's are allocated logically, which means the system can support an unbounded number of instances with a finite amount of resources.
 Logical instances do not use CPU, memory, or threads when not actively being invoked, so there is no theoretical upper limit on the number of instances that can created.
-Users are encouraged to model their applications as granularly as possible, based on what makes the most sense for their application, instead of desigining applications around resource constraints.
+Users are encouraged to model their applications as granularly as possible, based on what makes the most sense for their application, instead of designing applications around resource constraints.
 
 
 
@@ -40,11 +40,11 @@
 
 {{< img width="80%" src="/fig/concepts/address.svg" >}}
 
-An address is made of two components, a ``FunctionType`` and ``ID``.
+An address consists of two components, a ``FunctionType`` and ``ID``.
 A function type is similar to a class in an object-oriented language; it declares what sort of function the address references.
 The ID is a primary key, which scopes the function call to a specific instance of the function type.
 
-When a function is being invoked, all actions - including reads and writes of persisted states - are scoped to the current address.
+When a function is invoked, all actions - including reads and writes of persisted states - are scoped to the current address.
 
 For example, imagine there was a Stateful Functions application to track the inventory of a warehouse.
 One possible implementation could include an ``Inventory`` function that tracks the number units in stock for a particular item; this would be the function type.