Review improvements

docs/concepts.mdx

@@ -6,25 +6,25 @@ sidebar_position: 2
 
 The *Open Micro Frontend Platform (OpenMFP)* aims to provide the opinionated, “batteries-included” platform for micro frontend architecture, enabling a well integrated, state of the art end user experience.
 
-This documentation provides an overview of the core concepts of OpenMFP. You will be able to find more detailed information in the upcoming "Architecture" section.
+This documentation provides an overview of OpenMFP's core concepts. For more in-depth details, refer to the upcoming "Architecture" section.
 
 ## Extensibility & Micro Frontend Architecture
 
 OpenMFP is designed to be extensible and modular. It is built around the concept of micro frontends, which are small, self-contained applications that can be developed, tested, and deployed independently. 
 
 This allows teams to work on different parts of the application without interfering with each other, and to release updates without affecting the rest of the system.
 
-Extensions are the building blocks of OpenMFP. They allow the platform to obtain additional features. Practically every OpenMFP feature is an extension.
+Extensions are the building blocks of OpenMFP, enabling the platform to acquire additional features. In fact, nearly every feature in OpenMFP is an extension.
 
-The three most common types of extensions are:
+The three most common types of extensions in OpenMFP are:
 
-1. **UI-only micro frontends** - micro frontends are self-sufficient applications running inside of another application, also called the “microservices for the frontend”. They allow you to do independent releases, split up applications into smaller chunks, and reuse shared functionality/infrastructure. OpenMFP uses the [Luigi](https://luigi-project.io/) micro frontend framework to develop micro frontends.
+1. **UI-only Micro Frontends** - micro frontends are self-sufficient applications running within another application, also called the “microservices for the frontend”. They allow you to do independent releases, split up applications into smaller chunks, nd support the reuse of shared functionality and infrastructure. OpenMFP uses the [Luigi](https://luigi-project.io/) framework to develop these micro frontends.
 
-An OpenMFP micro frontend application should be able to work in a “micro frontend” mode, meaning it should:
-  * Not show a Header/Footer or sidebar Menu
-  * It should use the Luigi Client for an app internal navigation to properly adjust the browser URL on navigate
-  * It should be able to consume the provided Luigi context and the backend APIs should be able to accept the provided JWT token.
-2. **Micro frontends with backend service dependencies** - this option combines the micro frontend with additional backend services such as Events.
+    An OpenMFP micro frontend application should be able to work in a “micro frontend” mode, which means it should:
+    * Not show a Header, Footer or sidebar Menu.
+    * It should use the Luigi Client for internal navigation to properly adjust the browser URL on navigate.
+    * It should be able to consume the provided Luigi context and the backend APIs should be able to accept the provided JWT token.
+2. **Micro Frontends with Backend Service Dependencies** - this option combines micro frontend with additional backend services such as Events.
 3. **Service-only Extensions** - Extensions which include only backend services.
 
 :::info
@@ -39,20 +39,19 @@ Currently we make use of Keycloak for authentication. Keycloak is an open source
 
 ### Control Plane
 
-The Control Plane will be the central point of control for the OpenMFP platform, which will offer an API to manage the platform and its capabilities. The Control Plane will be responsible for managing the lifecycle of the platform, including creating and managing Kubernetes clusters (workspaces), users and permissions.
+The Control Plane will serve as the central point of control for the OpenMFP platform, which will offer an API to manage the platform and its capabilities. The Control Plane will be responsible for managing the lifecycle of the platform, including creating and managing Kubernetes clusters (workspaces), as well as managing users and permissions.
 
 We plan to leverage [kcp](https://www.kcp.io/) (Kubernetes-like Control Plane) so that you can provide your user specific control plane capabilities.
 
 ### Authorization
 
-The inclusion of a central ReBAC service (relationship based access control) addresses the important need of having a seamless user and permission management that supports the same extensibility and modularity for access control, removing friction from scenarios that span multiple components.
-
-- Central management of authorization to eliminate the need of double maintaining access permissions for every capability / service
-- Relationship based model can be extended dynamically with rules from different parties
-- Architecture proven to support cloud scale
-
-We aim to provide a central authorization capability, based on OpenFGA (which is based on Google’s “Zanzibar” architecture paper).
+The inclusion of a central ReBAC (Relationship Based Access Control) service addresses the crucial need of having a seamless user and permission management. This service supports the same extensibility and modularity for access control, removing friction in scenarios that span multiple components.
 
+Key benefits include:
 
+- Central authorization management, eliminating the need to maintain access permissions for every capability or service separately.
+- A relationship based model that can be dynamically extended with rules from different parties.
+- An architecture proven to scale effectively in cloud environments.
 
+We aim to provide a central authorization capability, based on [OpenFGA](https://openfga.dev) (which is based on Google’s “Zanzibar” architecture paper).
 

docs/getting-started/create-microfrontend.mdx

@@ -75,12 +75,12 @@ The following is an example of very minimal content configuration file. The cont
 Restart the server and validate that the configuration is loaded correctly in the path http://localhost:4200/assets/content-configuration.json
 
 ## Step 5: Consuming Local Content Configuration
-To see the Microfrontend in the OpenMFP Portal, you need to use your local `content-configuration.json` file go to the user button located on the top right corner
-**Settings** -> **Development**.
+To see the Microfrontend in the OpenMFP Portal, you need to use your local `content-configuration.json` file.
+Go to the user button located in the top-right corner and navigate to **Settings** -> **Development**.
 
-There you will find the Local Development Mode, please activate the **Is Development Mode Active** and add the content configuration file path in the input.
+There, you will find the Local Development Mode. Activate **Is Development Mode Active** and enter the content configuration file path in the input field.
 
-Then click on **Add** and then on **Save** and you should see your Microfrontend in the OpenMFP Portal.
+Click **Add** and then **Save**, and your Microfrontend should appear in the OpenMFP Portal.
 
 <div style={{textAlign: 'center'}}>
 <img src={MyMicrofrontendImgUrl} height="400" alt="Register User Form"/>

docs/getting-started/local-develpment.mdx

@@ -33,7 +33,7 @@ First, you need to register on the demo portal:
 <img src={RegisterUserImgUrl} height="500" alt="Register User Form"/>
 </div>
 
-Once you are registered, you will be automatically logged in and redirected to the OpenMFP home portal page, where you can start integrating your microfrontends.
+Once you are registered, you will be automatically logged in and redirected to the OpenMFP home portal page, where you can start integrating your micro frontends.
 
 <div style={{textAlign: 'center'}}>
 <img src={OpenMFPPortalImgUrl} height="400" alt="Register User Form"/>