diff --git a/LOs.csv b/LOs.csv
index 83be89a3..2d336bb9 100644
--- a/LOs.csv
+++ b/LOs.csv
@@ -74,7 +74,7 @@ LO-3.2.4,(K2),Understand how to create variables using the VAR statement,,,
 LO-3.2.5,(K2),Understand how `local` and `suite` scope variables are created,,,
 LO-3.3.2,(K1),Recall the rules how keyword names are matched.,,,
 LO-3.3.3,(K1),Recall all available settings and their purpose for User Keywords,,,
-LO-3.3.4,(K1),Recall the significance of the first logical line and in keyword documentation for the log file.,,,
+LO-3.3.4,(K1),Recall the significance of the first logical line in keyword documentation for the log file.,,,
 LO-3.3.5,(K2),Understand the purpose and syntax of the [Arguments] setting in User Keywords.,,,
 LO-3.3.5.1-1,(K1),Recall what makes an argument mandatory in a user keyword.,,,
 LO-3.3.5.1-2,(K3),Define User Keywords with mandatory arguments.,,,
@@ -108,7 +108,7 @@ LO-4.2.1-2,(K2),Understand when Suite Teardown is executed and used,,,
 LO-4.2.2-1,(K1),"Recall key characteristics, benefits, and syntax of Test|Task Teardown",,,
 LO-4.2.2-2,(K2),Understand when Test|Task Teardown is executed and used,,,
 LO-4.2.3,(K1),"Recall key characteristics, benefits, and syntax of Keyword Teardown",,,
-LO-4.3,(K1),Recall how to define Initialization Files and its purpose,,,
+LO-4.3,(K1),Recall how to define Initialization Files and their purpose,,,
 LO-4.3.2,(K2),Understand the execution order of Suite Setup and Suite Teardown in Initialization Files and their sub-suites and tests|tasks,,,
 LO-4.3.3,(K1),Recall the allowed sections and their content in Initialization Files,,,
 LO-4.4,(K1),Recall the purpose of Test|Task Tags in Robot Framework,,,
diff --git a/README.md b/README.md
index 0cefc568..2f48da50 100644
--- a/README.md
+++ b/README.md
@@ -163,7 +163,7 @@
 - [`3.3.3 User Keyword Settings`](website/docs/chapter-03/03_user_keyword.md#333-user-keyword-settings)
   - LO-3.3.3 (K1) Recall all available settings and their purpose for User Keywords
 - [`3.3.4 User Keyword Documentation`](website/docs/chapter-03/03_user_keyword.md#334-user-keyword-documentation)
-  - LO-3.3.4 (K1) Recall the significance of the first logical line and in keyword documentation for the log file.
+  - LO-3.3.4 (K1) Recall the significance of the first logical line in keyword documentation for the log file.
 - [`3.3.5 User Keyword Arguments`](website/docs/chapter-03/03_user_keyword.md#335-user-keyword-arguments)
   - LO-3.3.5 (K2) Understand the purpose and syntax of the [Arguments] setting in User Keywords.
   - [`3.3.5.1 Defining Mandatory Arguments`](website/docs/chapter-03/03_user_keyword.md#3351-defining-mandatory-arguments)
@@ -222,7 +222,7 @@
 - [`4.2.3 Keyword Teardown`](website/docs/chapter-04/02_teardowns.md#423-keyword-teardown)
   - LO-4.2.3 (K1) Recall key characteristics, benefits, and syntax of Keyword Teardown
 - [`4.3 Initialization Files`](website/docs/chapter-04/03_init_files.md)
-- LO-4.3 (K1) Recall how to define Initialization Files and its purpose
+- LO-4.3 (K1) Recall how to define Initialization Files and their purpose
 - [`4.3.1 Purpose of Initialization Files`](website/docs/chapter-04/03_init_files.md#431-purpose-of-initialization-files)
 - [`4.3.2 Suite Setup and Suite Teardown of Initialization Files`](website/docs/chapter-04/03_init_files.md#432-suite-setup-and-suite-teardown-of-initialization-files)
   - LO-4.3.2 (K2) Understand the execution order of Suite Setup and Suite Teardown in Initialization Files and their sub-suites and tests|tasks
diff --git a/website/docs/chapter-01/01_purpose.md b/website/docs/chapter-01/01_purpose.md
index 68f8de59..7a5d2feb 100644
--- a/website/docs/chapter-01/01_purpose.md
+++ b/website/docs/chapter-01/01_purpose.md
@@ -46,7 +46,7 @@ Robot Framework is typically not used for **component testing** nor **integratio
 
 ### 1.1.1.1 Synthetic Monitoring
 
-Beyond traditional test levels, **Synthetic Monitoring**, also referred to as **Active Monitoring** or **Proactive Monitoring**, is a proactive approach that simulates user interactions with live systems at regular intervals. It detects performance issues or downtime early with the goal of detecting such failure before they affect actual users.
+Beyond traditional test levels, **Synthetic Monitoring**, also referred to as **Active Monitoring** or **Proactive Monitoring**, is a proactive approach that simulates user interactions with live systems at regular intervals. It detects performance issues or downtime early with the goal of detecting such failures before they affect actual users.
 
 
 
diff --git a/website/docs/chapter-01/02_architecture.md b/website/docs/chapter-01/02_architecture.md
index efca12c5..a3d68ee4 100644
--- a/website/docs/chapter-01/02_architecture.md
+++ b/website/docs/chapter-01/02_architecture.md
@@ -58,7 +58,7 @@ Robot Framework itself focuses primarily on **test|task execution**.
 It includes:
 
 - A parser to read test|task data and build an execution model.
-- An execution engine to process model and execute the keywords.
+- An execution engine to process the model and execute the keywords.
 - A result generation mechanism to provide logs and reports.
 - A collection of generic standard libraries to process and handle data or interact with files and processes.
 - Defined APIs for extensions and customizations.
diff --git a/website/docs/chapter-01/03_syntax.md b/website/docs/chapter-01/03_syntax.md
index 7ddc9241..5322bf1d 100644
--- a/website/docs/chapter-01/03_syntax.md
+++ b/website/docs/chapter-01/03_syntax.md
@@ -15,7 +15,7 @@ Robot Framework is a script-based interpreter for files that contain textual spe
 These files are typically organized into directories.
 The syntax of Robot Framework is designed to be simple and human-readable, allowing for quick learning and ease of use.
 
-Key attributes of the syntax that improves the before mentioned:
+Key attributes of the syntax that improve the before mentioned:
 
 - **Space-separated syntax**: Robot Framework uses two or more spaces as the primary separator (although one space is allowed as a character).
   A use of **FOUR (4)** spaces is recommended to ensure clarity and readability of the specification.
@@ -25,7 +25,7 @@ Key attributes of the syntax that improves the before mentioned:
 - **String first**: Unquoted strings are considered as strings, while variables need special syntax.
 - **Single spaces are valid**: Single spaces are valid as a character in most elements and values without quotation.
 - **Mostly case-insensitive**: Most elements like keyword or variable names are case insensitive.
-However, some syntax, like library imports is case-sensitive.
+However, some syntax, like library imports, is case-sensitive.
 
 :::tip[Note]
 
diff --git a/website/docs/chapter-01/04_styles.md b/website/docs/chapter-01/04_styles.md
index 3a7b2a8a..cd268656 100644
--- a/website/docs/chapter-01/04_styles.md
+++ b/website/docs/chapter-01/04_styles.md
@@ -16,16 +16,16 @@ While **Keyword-Driven Testing (KDT)** and **Behavior-Driven Development (BDD)**
 
 Both styles can be mixed, even within the same test or task, but it is strongly recommended to have separate styles for separate purposes and not mix them within the same body.
 One practical solution would be to define acceptance test cases that cover users' expectations in a declarative *Behavior-Driven Style*, while using keywords that are implemented in an imperative *Keyword-Driven style*.
-Further system level :term[test cases]{term="Test Case"}, that are not covering acceptance criteria could be written in a *Keyword-Driven style*.
+Further system level :term[test cases]{term="Test Case"}, that are not covering acceptance criteria, could be written in a *Keyword-Driven style*.
 
 The approach of both styles is different in that way,
 that the *Behavior-Driven Style* is a **declarative** specification,
-where the script describe/declare what the system should do or how it should behave,
+where the script describes/declares what the system should do or how it should behave,
 while the *Keyword-Driven Style* is an **imperative** specification,
 where the script specifies what the automation should do to control the system.
 
 
-Beside these two different specification approaches how to write/formulate
+Besides these two different specification approaches how to write/formulate
 your automation script and their step sequences,
 there is also a third specification method, **Data-Driven Specification** that can be combined
 with the other two styles, to define the data that is used in the automation.
diff --git a/website/docs/chapter-02/01_suitefile.md b/website/docs/chapter-02/01_suitefile.md
index 65538baf..065bae68 100644
--- a/website/docs/chapter-02/01_suitefile.md
+++ b/website/docs/chapter-02/01_suitefile.md
@@ -19,7 +19,7 @@ If the path to a single file is given as **Root Suite** directly to Robot Framew
 
 If a directory path is given, starting at this location, Robot Framework will parse all `*.robot` files and directories within this path.
 Robot Framework analyzes all containing files and determines if they contain test cases or tasks. If they do, they are considered **Suite Files** or **Low-Level Suites**.
-All directories that either directly or indirectly contain a Suite File are considered **Suites Directories** or **Higher-Level Suites**.
+All directories that either directly or indirectly contain a Suite File are considered **Suite Directories** or **Higher-Level Suites**.
 
 The ordering of suites during execution is, by default, defined by their name and hierarchy.
 All files and directories, which are suites in one directory, are considered on the same level and are executed in case-insensitive alphabetical order.
@@ -128,7 +128,7 @@ It allows you to import keywords from external libraries (`Library`) or resource
 
 In this section, the suite name, that is normally derived from the file name, can be redefined with the `Name` setting and its documentation can be defined with the `Documentation` setting.
 
-Additional metadata can be defined by multiple `Metadata` entries, which can contain key-value pairs that can be used to store additional information about the suite, like the author, the version, or related requirements of the suite.
+Additional suite metadata can be defined by multiple `Metadata` entries, which can contain key-value pairs that can be used to store additional information about the suite, like the author, the version, or related requirements of the suite.
 
 This section can also define keywords called for execution flow control, such as `Suite Setup` and `Suite Teardown`, which are executed before and after the suite's tests run. See [4.1 Setups (Suite, Test|Task, Keyword)](chapter-04/01_setups.md) and
 [4.2 Teardowns (Suite, Test|Task, Keyword)](chapter-04/02_teardowns.md) for more information.
diff --git a/website/docs/chapter-02/02_suitefile_syntax.md b/website/docs/chapter-02/02_suitefile_syntax.md
index 52cf3671..65b93b84 100644
--- a/website/docs/chapter-02/02_suitefile_syntax.md
+++ b/website/docs/chapter-02/02_suitefile_syntax.md
@@ -15,7 +15,7 @@ Understand the basic syntax of test cases and tasks.
 ::::
 
 Suite files and resource files share the same syntax, however they differ in their capabilities.
-Resource files are explained in more detail in [2.4.2 Resource Files](chapter-02/04_keyword_imports.md#242-resource-files) [3.1 Resource File Structure](chapter-03/01_resource_file.md).
+Resource files are explained in more detail in [2.4.2 Resource Files](chapter-02/04_keyword_imports.md#242-resource-files) and [3.1 Resource File Structure](chapter-03/01_resource_file.md).
 
 
 ## 2.2.1 Separation and Indentation
@@ -219,9 +219,9 @@ Some examples are:
 All those characters or character sequences that are interpreted as control characters can be escaped by a backslash `\`.
 This means that the character following the backslash is interpreted as a normal character and not as a control character.
 
-This leads to the fact that a backslash itself must be escaped by another backslash to be interpreted as a normal backslash character. Therefore it is strongly recommended to use forward slashes `/` as path separators in paths also on windows environments and avoid backslashes `\` whenever possible.
+This leads to the fact that a backslash itself must be escaped by another backslash to be interpreted as a normal backslash character. Therefore it is strongly recommended to use forward slashes `/` as path separators in paths also on Windows environments and avoid backslashes `\` whenever possible.
 
-Leading and trailing spaces in values are normally considered being part of the separator surrounding the values.
+Leading and trailing spaces in values are normally considered to be part of the separator surrounding the values.
 If values shall contain leading or trailing spaces they must be either enclosed in backslashes `\` or replaced by the special variable `${SPACE}` that contains a single space character.
 
 Example:
diff --git a/website/docs/chapter-02/03_executing.md b/website/docs/chapter-02/03_executing.md
index 9898eb93..621d2096 100644
--- a/website/docs/chapter-02/03_executing.md
+++ b/website/docs/chapter-02/03_executing.md
@@ -32,7 +32,7 @@ Understand how to run the `robot` command and its basic usage.
 
 The `robot` command is used to run a Robot Framework execution, which will execute suites and their containing tests|tasks.
 
-At a basic level, you can run `robot` by providing the path to a suite file or suite directory containing suite files as last argument.
+At a basic level, you can run `robot` by providing the path to a suite file or suite directory containing suite files as the last argument.
 ```plaintext
 robot <path_to_root_suite>
 ```
@@ -93,7 +93,7 @@ After executing a suite, Robot Framework, by default, generates three output fil
 
 `log.html` and `report.html` are generated based on the information stored in `output.xml`.
 
-A unique feature of Robot Framework is, that it logs each keyword call and its arguments with its log outputs and timestamps, so that it is possible to have a very detailed view of the execution flow and the data that was used during the execution.
+A unique feature of Robot Framework is that it logs each keyword call and its arguments with its log outputs and timestamps, so that it is possible to have a very detailed view of the execution flow and the data that was used during the execution.
 In case of a failure it is possible to see the exact keyword call that failed and the arguments that were used, which can be very helpful for debugging or reporting. Furthermore, you also get all passed keywords and even the non‑executed keywords, allowing you to trace the whole execution flow.
 
 
@@ -143,7 +143,7 @@ This status is used if an element was executed successfully without any errors o
 
 **Atomic elements** are `PASS` if they were executed successfully without reporting an error by raising an exception.
 
-**Composite elements** are `PASS` if all their executed body elements are pass.
+**Composite elements** are `PASS` if all their executed body elements are `PASS`.
 E.g. in case of User Keywords this means that if all keywords or Robot Framework language statements that were directly called by that User Keyword were `PASS` the User Keyword itself is considered `PASS`.
 
 Library Keywords like `Run Keyword And Expect Error`, from BuiltIn Library, do `PASS` if the keyword they are internally calling does raise an error with the expected message or type.
@@ -170,12 +170,12 @@ Exceptions are teardowns, as explained in [Chapter 4: Advanced Structuring and E
 
 **Atomic elements** are `FAIL` if they were tried to be executed but raised an exception.
 
-**Composite elements** are `FAIL` if at least one of their executed direct body elements are `FAIL`.
+**Composite elements** are `FAIL` if at least one of their executed direct body elements is `FAIL`.
 Therefore a failure typically distributes upwards through the hierarchy of elements until it reaches the root suite.
 
 A User Keyword is `FAIL` if one of its called Library Keywords is `FAIL`.
 A test|task is `FAIL` if one of its directly called Keywords is `FAIL`.
-A suite (file) is `FAIL` if one of its test|task is `FAIL` and
+A suite (file) is `FAIL` if one of its tests|tasks is `FAIL` and
 a suite (directory) is `FAIL` if one of its suites (file) is `FAIL`.
 
 
diff --git a/website/docs/chapter-02/04_keyword_imports.md b/website/docs/chapter-02/04_keyword_imports.md
index ef77ee24..5c900334 100644
--- a/website/docs/chapter-02/04_keyword_imports.md
+++ b/website/docs/chapter-02/04_keyword_imports.md
@@ -34,17 +34,14 @@ Recall the three types of libraries in Robot Framework.
 
 From a user perspective there are three different kinds of libraries:
 - **Robot Framework Standard Libraries**: These are libraries that are shipped with Robot Framework and are available without any additional installation. See documentation of [ext: Robot Framework Standard Libraries](https://robotframework.org/robotframework/#standard-libraries) for more information.
-- **3rd Party Libraries** / **External Libraries**: These are libraries have been developed and maintained by community members and have to be installed/downloaded separately.
+- **3rd Party Libraries** / **External Libraries**: These are libraries that have been developed and maintained by community members and have to be installed/downloaded separately.
 - **Custom Libraries**: These libraries are developed by the users themselves to solve specific problems or to encapsulate more complex functionality.
 
-Further more detailed information about the different types of libraries and are described in later chapters.
-{/* TODO: Do we fulfill this promise? */}
-
-To import a library into a suite or resource file the `Library` setting is used in the `*** Settings ***` section followed by the name of the library as long as they are located in the Python module search path, which automatically happens if they are installed via `pip`.
+To import a library into a suite or resource file the `Library` setting is used in the `*** Settings ***` section followed by the name of the library as long as it is located in the Python module search path, which automatically happens if it is installed via `pip`.
 The name of the library is case-sensitive and should be taken from the library's keyword documentation.
 By default, libraries in Robot Framework are implemented in Python and the name of the library is the name of the Python module that contains the library implementation.
 
-Alternatively, if a library is not in Python module search path, a library can be imported using the path to the Python module. See [2.4.3 Import Paths](chapter-02/04_keyword_imports.md#243-import-paths).
+Alternatively, if a library is not in the Python module search path, a library can be imported using the path to the Python module. See [2.4.3 Import Paths](chapter-02/04_keyword_imports.md#243-import-paths).
 
 Be aware that the library [`BuiltIn`](https://robotframework.org/robotframework/latest/libraries/BuiltIn.html) is always imported invisibly and does not need to be imported explicitly.
 
diff --git a/website/docs/chapter-02/05_keyword_interface.md b/website/docs/chapter-02/05_keyword_interface.md
index 8a8fd3f2..562e301a 100644
--- a/website/docs/chapter-02/05_keyword_interface.md
+++ b/website/docs/chapter-02/05_keyword_interface.md
@@ -13,7 +13,7 @@ Understand the structure of keyword interfaces and how to interpret keyword docu
 
 Library Keywords and User Keywords that are defined in a resource file should have a documentation text that describes what the keyword does and how it should be used.
 
-Robot Framework is capable of generating **Keyword Documentation** files that contains a library- or resource-documentation, all keywords, their argument interfaces, and their documentation texts.
+Robot Framework is capable of generating **Keyword Documentation** files that contain a library- or resource-documentation, all keywords, their argument interfaces, and their documentation texts.
 This documentation file can be generated with the `libdoc` command and can be used to provide a reference for users who want to use the keywords.
 
 Basically all standard and external 3rd party libraries offer these Keyword Documentations as online available HTML pages.
@@ -36,7 +36,7 @@ Recall the information that can be found in a keyword documentation.
 
 ::::
 
-The Keyword Documentation is structured so, that it contains first the library or resource documentation, followed by a list of all keywords that are available in that library or resource file.
+The Keyword Documentation is structured so that it contains first the library or resource documentation, followed by a list of all keywords that are available in that library or resource file.
 
 Each library or resource documentation can contain the following information sections for keywords:
 - **Name**: The name of the keyword as it is called.
@@ -114,7 +114,7 @@ Understand the difference between argument kinds.
 ::::
 
 Most library keywords can be parameterized with arguments that are passed to the keyword when it is called to customize its behavior.
-The more business oriented keywords are the less arguments they typically have.
+The more business oriented keywords are the fewer arguments they typically have.
 
 Keyword arguments can be grouped into different argument kinds.
 On the one hand you can group them by their definition attributes and on the other hand by their usage kind.
@@ -281,8 +281,8 @@ These are also referred to as `*args` or `*varargs` in Python.
 Some keywords need to collect a variable amount of values into one argument, because it is not possible to define the amount of values in advance.
 
 One example for this kind of keyword is [2.5.1.2 Example Keyword `Set To Dictionary`](chapter-02/05_keyword_interface.md#2512-example-keyword-set-to-dictionary) from the Collections library.
-This keyword adds key and values to a `dictionary` with variable amount of `key_value_pairs`.
-Depending on the number of keys and values, different amount of arguments are needed.
+This keyword adds key and values to a `dictionary` with a variable amount of `key_value_pairs`.
+Depending on the number of keys and values, a different amount of arguments is needed.
 
 This key_value_pairs argument is marked with a single asterisk `*` before the argument name in the keyword documentation.
 
@@ -380,11 +380,11 @@ However, the actual implementation of the keyword may expect a different type of
 If an argument type is defined and Robot Framework has a matching converter function available, that can convert the given type to the expected type, the conversion is tried automatically.
 If the conversion fails, the keyword call will fail with an error message before the actual keyword code is executed.
 Robot Framework brings some built-in converters for common types like integer, float, boolean, list, dictionary, etc.
-Library developers can also register their own converters for none-supported types.
+Library developers can also register their own converters for non-supported types.
 
 Defining types for arguments is nowadays the recommended way to let Robot Framework convert the given arguments to the expected type, however it is optional.
 
-Lets imagine a keyword that clicks on a specific coordinate on the screen, e.g. `Click On Coordinates`.
+Let's imagine a keyword that clicks on a specific coordinate on the screen, e.g. `Click On Coordinates`.
 This keyword would expect two integer arguments, one for the `x`-coordinate and one for the `y`-coordinate.
 
 That keyword can now claim that it expects two integer arguments by defining type hints for these arguments.
@@ -404,7 +404,7 @@ In the first call the keyword will be called with the integer values `10` and `2
 The second keyword call will fail, because the second argument is not a number and cannot be converted to an integer.
 The error message would be: `ValueError: Argument 'y' got value 'Not_A_Number' that cannot be converted to integer.`
 
-The advantage of using type hints is that the user get more information about what kind of values are expected and the keyword implementation can be simpler, because it can rely on the arguments being of the expected type.
+The advantage of using type hints is that the user gets more information about what kind of values are expected and the keyword implementation can be simpler, because it can rely on the arguments being of the expected type.
 
 {/* TODO: Just to understand that they are there and that they may document how values are handled or which are allowed. */}
 
diff --git a/website/docs/chapter-02/06_writing_test.md b/website/docs/chapter-02/06_writing_test.md
index 1180f2c8..646b885c 100644
--- a/website/docs/chapter-02/06_writing_test.md
+++ b/website/docs/chapter-02/06_writing_test.md
@@ -23,13 +23,13 @@ After the keyword name the arguments are set.
 All arguments are separated by multiple spaces from the keyword name and from each other and can also include single spaces.
 Argument values are stripped from leading and trailing spaces, but spaces within the argument value are preserved.
 
-If an argument shall contain more than one consecutive spaces or start or end with spaces, the spaces must be escaped by a backslash `\` to prevent them from being interpreted as a part of a "multi-space-separator".
+If an argument shall contain more than one consecutive space or start or end with spaces, the spaces must be escaped by a backslash `\` to prevent them from being interpreted as a part of a "multi-space-separator".
 
 Example:
 ```robotframework
 *** Test Cases ***
 Mandatory Positional Arguments
-    [Documentation]    Only mandatory arguments are use positionally
+    [Documentation]    Only mandatory arguments are used positionally
     Should Be Equal    1    1
 
 Mixed Positional Arguments
@@ -83,7 +83,7 @@ Some keywords do not have an obvious order of arguments.
 In these cases, calling keywords with named arguments can lead to better readability and understanding of the keyword call.
 
 Using arguments positionally is very handy for arguments that are obvious and easy to understand.
-In the early login example the following keyword calls exists:
+In the early login example the following keyword call exists:
 ```robotframework
 *** Test Cases ***
 Login User With Password
@@ -100,7 +100,7 @@ Click on x and y
     Click On Coordinates    x=82    y=70
 ```
 
-Calling keywords that have a :term[Variable Number of Positional Arguments] does require to set all preceding arguments by their position if the :term[Variable Number of Positional Arguments] shall be set.
+Calling keywords that have a :term[Variable Number of Positional Arguments] does require setting all preceding arguments by their position if the :term[Variable Number of Positional Arguments] shall be set.
 
 Example:
 ```robotframework
@@ -161,7 +161,7 @@ Recall how to use embedded arguments.
 
 ::::
 
-Embedded Arguments are mostly used in Behavior-Driven Development (BDD) using Robot Frameworks Behavior-Driven Specification style.
+Embedded Arguments are mostly used in Behavior-Driven Development (BDD) using Robot Framework's Behavior-Driven Specification style.
 
 Embedded Arguments are part of the keyword name as described in [2.5.2.3 Embedded Arguments](chapter-02/05_keyword_interface.md#2523-embedded-arguments).
 
diff --git a/website/docs/chapter-03/01_resource_file.md b/website/docs/chapter-03/01_resource_file.md
index 5bbc0cea..c3f7d89c 100644
--- a/website/docs/chapter-03/01_resource_file.md
+++ b/website/docs/chapter-03/01_resource_file.md
@@ -20,7 +20,7 @@ is given as an argument to the setting.
 The extension for resource files shall be `.resource`.
 
 Unless the resource file is given as an absolute path,
-it is first searched relatively to
+it is first searched relative to
 the directory where the importing file is located.
 If the file is not found there, it is then searched from the
 directories in Python's module search path.
@@ -47,7 +47,7 @@ The allowed sections in recommended order are:
 
   Additional settings are:
   - `Keyword Tags` to set tags for all keywords in the resource file.
-    defining and using Keyword tags is not part of this syllabus.
+    Defining and using Keyword tags is not part of this syllabus.
 
   Other settings available in suites are not available in resource files.
 
diff --git a/website/docs/chapter-03/02_variables.md b/website/docs/chapter-03/02_variables.md
index 16e94e59..55a4fa39 100644
--- a/website/docs/chapter-03/02_variables.md
+++ b/website/docs/chapter-03/02_variables.md
@@ -120,7 +120,7 @@ Variables created in this section:
 - have a **suite scope** in the suite created or imported to.
 
 Because two or more spaces are used to separate elements in a row,
-all values are stripped of leading and trailing spaces, identical to arguments of keyword calls (see [2.2.4 Escaping of Control Characters](chapter-02/02_suitefile_syntax.md#224-escaping-of-control-characters) to be able to define these spaces.
+all values are stripped of leading and trailing spaces, identical to arguments of keyword calls (see [2.2.4 Escaping of Control Characters](chapter-02/02_suitefile_syntax.md#224-escaping-of-control-characters)) to be able to define these spaces.
 
 Variable values in Robot Framework can include other variables, and their values will be concatenated at runtime when the line is executed.
 This means that when a variable is used within another variable's value, the final value is resolved by replacing the variables with their actual content during execution.
@@ -461,7 +461,7 @@ In Robot Framework, variables have different scopes, which define where they can
 
 - **`SUITE` Scope**: Variables defined at the suite level, for example in the `*** Variables ***` section or through importing resource files, are available to all tests|tasks and keywords called within the suite.
 
-  That means that they can be accessed inside a keyword, called from a test|task of that suite even, if this variable is not created as part of the argument interface of that keyword.
+  That means that they can be accessed inside a keyword, called from a test|task of that suite, even if this variable is not created as part of the argument interface of that keyword.
 
 Examples and more details on variable scope, such as `TEST` and `GLOBAL` scope can be found in the [5.1.2 Variable Scopes](chapter-05/01_advanced_variables.md#512-variable-scopes) section.
 
diff --git a/website/docs/chapter-03/03_user_keyword.md b/website/docs/chapter-03/03_user_keyword.md
index 12defdab..ca6f6afa 100644
--- a/website/docs/chapter-03/03_user_keyword.md
+++ b/website/docs/chapter-03/03_user_keyword.md
@@ -67,7 +67,7 @@ To identify keywords that shall be executed, Robot Framework uses a matching alg
 
 By default, if not explicitly defined by the library developers, all Library Keywords are named in **Title Case** with capital letters at the beginning of each word, and spaces between words.
 
-Project may choose a different naming convention for User Keywords, but it is recommended to be consistent across the project for User Keyword names.
+Projects may choose a different naming convention for User Keywords, but it is recommended to be consistent across the project for User Keyword names.
 
 They are defined without indentation, and the subsequent lines until the next unindented line are considered the body of the keyword.
 The following topics explain how to structure the body of a keyword.
@@ -97,7 +97,7 @@ All available settings are listed below and explained in this section or in sect
 - `[Timeout]` (*) Sets the possible user keyword timeout.
 - `[Return]` (*) Deprecated. Use the `RETURN` statement instead. (see [3.3.6 RETURN Statement](chapter-03/03_user_keyword.md#336-return-statement))
 
-(*) The application of these settings are not part of this syllabus.
+(*) The application of these settings is not part of this syllabus.
 
 
 
@@ -107,7 +107,7 @@ All available settings are listed below and explained in this section or in sect
 
 :::K1[LO-3.3.4]
 
-Recall the significance of the first logical line and in keyword documentation for the log file.
+Recall the significance of the first logical line in keyword documentation for the log file.
 
 :::
 
@@ -425,7 +425,7 @@ Get ISO Time
 
 Should we have that  chapter???
 Opinions?
-And if, is this want we want to ask the participants to know?
+And if, is this what we want to ask the participants to know?
 */}
 
 
diff --git a/website/docs/chapter-03/04_datadriven.md b/website/docs/chapter-03/04_datadriven.md
index 42e8d370..0c261d69 100644
--- a/website/docs/chapter-03/04_datadriven.md
+++ b/website/docs/chapter-03/04_datadriven.md
@@ -54,7 +54,7 @@ Recall the syntax and properties of multiple named test|task with one template
 
 ::::
 
-The following example has six different test|task, each with different name and different data sets, all using the `Login With Invalid Credentials Should Fail` keyword template.
+The following example has six different tests|tasks, each with a different name and different data sets, all using the `Login With Invalid Credentials Should Fail` keyword template.
 
 ```robotframework
 *** Settings ***
@@ -116,7 +116,7 @@ Valid Logins
 
 If one data row fails, this template execution is marked FAIL and the test|task is marked FAIL, but **the other data rows are still executed**.
 
-This approach creates only a single tests|tasks for multiple data rows in the logs and reports, which can be beneficial statistically.
+This approach creates only a single test|task for multiple data rows in the logs and reports, which can be beneficial statistically.
 
 However, this approach has also its drawbacks:
 
diff --git a/website/docs/chapter-04/02_teardowns.md b/website/docs/chapter-04/02_teardowns.md
index eefb7e72..d1f0066b 100644
--- a/website/docs/chapter-04/02_teardowns.md
+++ b/website/docs/chapter-04/02_teardowns.md
@@ -24,7 +24,7 @@ To prevent such issues, Robot Framework provides the **Teardown** functionality,
 As mentioned before, a failure resulting in a keyword with the status `FAIL` will cause Robot Framework not to execute all subsequent keywords of the current test|task.
 These not-executed keywords will receive the status `NOT RUN`.
 
-A **Teardown** is a single keyword call with potential argument values that is executed after the child suites, test|tasks, and keywords have completed execution, regardless of the outcome, even if previously executed elements have failed.
+A **Teardown** is a single keyword call with potential argument values that is executed after the child suites, tests|tasks, and keywords have completed execution, regardless of the outcome, even if previously executed elements have failed.
 It ensures that necessary cleanup actions are performed, maintaining the integrity of the environment for subsequent executions.
 
 **Typical use cases for Teardowns include:**
diff --git a/website/docs/chapter-04/03_init_files.md b/website/docs/chapter-04/03_init_files.md
index 2a6d59db..4298f18d 100644
--- a/website/docs/chapter-04/03_init_files.md
+++ b/website/docs/chapter-04/03_init_files.md
@@ -5,7 +5,7 @@
 
 :::K1[LO-4.3]
 
-Recall how to define Initialization Files and its purpose
+Recall how to define Initialization Files and their purpose
 
 :::
 
@@ -68,7 +68,7 @@ The following sections are allowed in initialization files:
 - **`*** Settings ***` Section (required)**:
   - `Name`: Set a custom name for the suite directory.
   - `Documentation`: Provide documentation for the suite.
-  - `Metadata`: Add metadata to the suite.
+  - `Metadata`: Add suite metadata.
   - `Suite Setup`: Define a keyword to be executed before any tests|tasks or child suites.
   - `Suite Teardown`: Define a keyword to be executed after all tests|tasks and child suites have completed.
   - `Test Setup`|`Task Setup`: Set a default setup keyword for all tests|tasks in the suite (can be overridden in lower-level suites or tests|tasks).
diff --git a/website/docs/chapter-04/04_tags.md b/website/docs/chapter-04/04_tags.md
index 51159270..b280d8c6 100644
--- a/website/docs/chapter-04/04_tags.md
+++ b/website/docs/chapter-04/04_tags.md
@@ -12,7 +12,7 @@ Recall the purpose of Test|Task Tags in Robot Framework
 ::::
 
 In Robot Framework, **tags** offer a simple yet powerful mechanism for classifying and controlling the execution of tests|tasks.
-Tags are free-form text labels that can be assigned to tests|tasks to provide metadata, enable flexible test selection, and organize test results.
+Tags are free-form text labels that can be assigned to tests|tasks to provide meta information, enable flexible test selection, and organize test results.
 
 Tags are also used to create a statistical summary of the test|task results in the execution protocols.
 
@@ -154,7 +154,7 @@ Examples:
 ## 4.4.3 Reserved Tags
 
 Tags starting with `robot:` are reserved for internal use by Robot Framework and should not be used in user-defined tags.
-Using own tags with this prefix may lead to unexpected behavior in test execution and reporting.
+Using your own tags with this prefix may lead to unexpected behavior in test execution and reporting.
 
 - `robot:exclude`: Marks tests|tasks that should be excluded from execution similar to `--exclude`.
 - `robot:skip`: Marks tests|tasks that should be skipped during execution similar to `--skip`.
diff --git a/website/docs/chapter-04/05_skip.md b/website/docs/chapter-04/05_skip.md
index b4b54f4b..9d29ee03 100644
--- a/website/docs/chapter-04/05_skip.md
+++ b/website/docs/chapter-04/05_skip.md
@@ -42,7 +42,7 @@ Tests|tasks can be skipped with `--skip` by tags when executing Robot Framework,
 The difference between `--skip` and `--exclude` is that `--skip` will mark the tests|tasks as skipped in the report and log, while `--exclude` will not execute them at all.
 Therefore skip is better for documenting that a specific test|task was not executed for a specific reason.
 
-**Example**: If there is a defect in the System under Test (SUT) and a test|task has been written to reproduce the defect and tests its resolution, but the defect is not yet resolved, the test|task can be tagged with the defect-number and skipped until the defect has been resolved.
+**Example**: If there is a defect in the System under Test (SUT) and a test|task has been written to reproduce the defect and test its resolution, but the defect is not yet resolved, the test|task can be tagged with the defect-number and skipped until the defect has been resolved.
 
 **Example**: Assuming there are different test environments and some tests can only be executed in specific environments, the tests can be tagged with the environment name and skipped in all other environments.
 
diff --git a/website/docs/chapter-05/01_advanced_variables.md b/website/docs/chapter-05/01_advanced_variables.md
index 133198ba..8095fe9c 100644
--- a/website/docs/chapter-05/01_advanced_variables.md
+++ b/website/docs/chapter-05/01_advanced_variables.md
@@ -39,7 +39,7 @@ Built-in variables cannot generally be sorted into one of these categories, as s
 Examples:
 - `${TEST_NAME}` is dynamically set during execution to the name of the currently running test case.
 - `${OUTPUT_DIR}` is statically defined before the execution and contains the directory where `output.xml`, `log.html` and `report.html` are written.
-- `${LOG_LEVEL}` is by default set statically via command line options or `INFO` as default, but can be changed, with the keyword `Set Log Level` during exection.
+- `${LOG_LEVEL}` is by default set statically via command line options or `INFO` as default, but can be changed, with the keyword `Set Log Level` during execution.
 
 ### 5.1.1.1 Statically Defined or Imported Variables
 
diff --git a/website/docs/chapter-05/02_control_structures.md b/website/docs/chapter-05/02_control_structures.md
index 8d660524..a31549ca 100644
--- a/website/docs/chapter-05/02_control_structures.md
+++ b/website/docs/chapter-05/02_control_structures.md
@@ -88,7 +88,7 @@ Quick Check
     IF    $user == 'Admin'    Log    Admin access granted.
 ```
 
-Executes the `Log` keyword if `${user}` equals to the string `'Admin'`.
+Executes the `Log` keyword if `${user}` equals the string `'Admin'`.
 
 No `END` is needed for inline IF.
 
diff --git a/website/docs/example-exam/Example-exam.mdx b/website/docs/example-exam/Example-exam.mdx
index f2e196fe..51850ab9 100644
--- a/website/docs/example-exam/Example-exam.mdx
+++ b/website/docs/example-exam/Example-exam.mdx
@@ -2,6 +2,6 @@ import Quiz from '@site/src/components/Quiz/Quiz';
 
 # Example Questions
 
-This example exam should give you the oportunity to check you knowledge and to get an impression what kind of questions may be asked in the real examination for RFCP®.
+This example exam should give you the opportunity to check your knowledge and to get an impression of what kind of questions may be asked in the real examination for RFCP®.
 
 <Quiz name="Example" src="Example.md"/>
diff --git a/website/docs/learning_objectives.md b/website/docs/learning_objectives.md
index e0832b25..abaf31ef 100644
--- a/website/docs/learning_objectives.md
+++ b/website/docs/learning_objectives.md
@@ -76,7 +76,7 @@
 | [`LO-3.2.5`](chapter-03/02_variables.md#325-variable-scope-introduction) | K2 | Understand how `local` and `suite` scope variables are created |
 | [`LO-3.3.2`](chapter-03/03_user_keyword.md#332-user-keyword-names) | K1 | Recall the rules how keyword names are matched. |
 | [`LO-3.3.3`](chapter-03/03_user_keyword.md#333-user-keyword-settings) | K1 | Recall all available settings and their purpose for User Keywords |
-| [`LO-3.3.4`](chapter-03/03_user_keyword.md#334-user-keyword-documentation) | K1 | Recall the significance of the first logical line and in keyword documentation for the log file. |
+| [`LO-3.3.4`](chapter-03/03_user_keyword.md#334-user-keyword-documentation) | K1 | Recall the significance of the first logical line in keyword documentation for the log file. |
 | [`LO-3.3.5`](chapter-03/03_user_keyword.md#335-user-keyword-arguments) | K2 | Understand the purpose and syntax of the [Arguments] setting in User Keywords. |
 | [`LO-3.3.5.1-1`](chapter-03/03_user_keyword.md#3351-defining-mandatory-arguments) | K1 | Recall what makes an argument mandatory in a user keyword. |
 | [`LO-3.3.5.1-2`](chapter-03/03_user_keyword.md#3351-defining-mandatory-arguments) | K3 | Define User Keywords with mandatory arguments. |
@@ -110,7 +110,7 @@
 | [`LO-4.2.2-1`](chapter-04/02_teardowns.md#422-testtask-teardown) | K1 | Recall key characteristics, benefits, and syntax of Test\|Task Teardown |
 | [`LO-4.2.2-2`](chapter-04/02_teardowns.md#422-testtask-teardown) | K2 | Understand when Test\|Task Teardown is executed and used |
 | [`LO-4.2.3`](chapter-04/02_teardowns.md#423-keyword-teardown) | K1 | Recall key characteristics, benefits, and syntax of Keyword Teardown |
-| [`LO-4.3`](chapter-04/03_init_files.md) | K1 | Recall how to define Initialization Files and its purpose |
+| [`LO-4.3`](chapter-04/03_init_files.md) | K1 | Recall how to define Initialization Files and their purpose |
 | [`LO-4.3.2`](chapter-04/03_init_files.md#432-suite-setup-and-suite-teardown-of-initialization-files) | K2 | Understand the execution order of Suite Setup and Suite Teardown in Initialization Files and their sub-suites and tests\|tasks |
 | [`LO-4.3.3`](chapter-04/03_init_files.md#433-allowed-sections-in-initialization-files) | K1 | Recall the allowed sections and their content in Initialization Files |
 | [`LO-4.4`](chapter-04/04_tags.md) | K1 | Recall the purpose of Test\|Task Tags in Robot Framework |
diff --git a/website/docs/overview.md b/website/docs/overview.md
index 7f4df546..f221add4 100644
--- a/website/docs/overview.md
+++ b/website/docs/overview.md
@@ -115,7 +115,7 @@ This includes tracking which participants have earned certifications, maintainin
 
 Our current exclusive exam provider is the [Global Association for Software Quality](https://www.gasq.org/en/home.html).
 
-Global Association for Software Quality , abbreviated GASQ,
+Global Association for Software Quality, abbreviated GASQ,
 is an international exam provider and a leading association in the software quality industry.
 GASQ was founded by experts from Europe, Asia and America as an independent,
 international non-profit association aiming to advocate and promote software quality in research, teaching and industry.
diff --git a/website/static/glossary/glossary.json b/website/static/glossary/glossary.json
index a595c57c..c81bbc0e 100644
--- a/website/static/glossary/glossary.json
+++ b/website/static/glossary/glossary.json
@@ -21,7 +21,7 @@
 		"term": "Automation Script",
 		"aliases": [],
 		"abbreviation": "",
-		"definition": "Robot Framework suite, test, task, or keyword collection that automates a defined workflow or behavior."
+		"definition": "Robot Framework suite, test|task, or keyword collection that automates a defined workflow or behavior."
 	},
 	{
 		"term": "Argument",
@@ -45,7 +45,7 @@
 		"term": "Behavior-Driven Specification",
 		"aliases": [],
 		"abbreviation": "",
-		"definition": "Declarative Robot Framework style where tests|tasks describe system behavior from the user perspective using natural-language-like steps with embedded arguments and optional Given/When/Then/And/But prefixes."
+		"definition": "Declarative Robot Framework style in which tests|tasks describe system behavior from the user's perspective using natural-language-like steps with embedded arguments and optional Given/When/Then/And/But prefixes."
 	},
 	{
 		"term": "Built-In Variables",
@@ -69,7 +69,7 @@
 		"term": "Control Structure",
 		"aliases": [],
 		"abbreviation": "",
-		"definition": "Statement such as `IF`, `FOR`, `WHILE`, `BREAK`, or `CONTINUE` that controls execution flow inside a test, task, or keyword."
+		"definition": "Statement such as `IF`, `FOR`, `WHILE`, `BREAK`, or `CONTINUE` that controls execution flow inside a test|task, or keyword."
 	},
 	{
 		"term": "Data-Driven Specification",
@@ -83,6 +83,12 @@
 		"abbreviation": "",
 		"definition": "Layer in the Generic Test Automation Architecture (gTAA) containing test data such as suites, tests, tasks, resource files, keywords, and variables written in Robot Framework syntax."
 	},
+	{
+		"term": "Dictionary Variable",
+		"aliases": [],
+		"abbreviation": "&{}",
+		"definition": "Robot Framework variable of dictionary type created with the `&{}` syntax that holds key-value pairs and can be accessed by keys."
+	},
 	{
 		"term": "Embedded Argument",
 		"aliases": [],
@@ -99,7 +105,7 @@
 		"term": "Execution Artifacts",
 		"aliases": [],
 		"abbreviation": "",
-		"definition": "Files produced by Robot Framework execution—such as `output.xml`, `log.html`, and `report.html`—that document what was executed and with which results."
+		"definition": "Files generated by a Robot Framework execution (e.g. `output.xml`, `log.html`, and `report.html`) that document the execution process and its results."
 	},
 	{
 		"term": "Execution Layer",
@@ -117,7 +123,7 @@
 		"term": "Fail Status",
 		"aliases": [],
 		"abbreviation": "",
-		"definition": "Execution status indicating that an element (such as a keyword, test, task, or suite) did not meet its expected outcome or raised an error during execution."
+		"definition": "Execution status indicating that an element (e.g. keyword, test|task, or suite) did not meet its expected outcome or raised an error during execution."
 	},
 	{
 		"term": "FOR Loop",
@@ -128,13 +134,13 @@
 	{
 		"term": "Free Named Argument",
 		"aliases": ["**kwargs"],
-		"abbreviation": "kwargs",
+		"abbreviation": "",
 		"definition": "Catch-all named argument kind in a keyword specification, marked with **, that gathers all named values not explicitly defined elsewhere into a dictionary."
 	},
 	{
 		"term": "Generic Test Automation Architecture",
 		"aliases": ["gTAA"],
-		"abbreviation": "gTAA",
+		"abbreviation": "",
 		"definition": "Layered reference architecture for test automation that separates definition, execution, and adaptation layers and describes Robot Framework’s role in an automation solution."
 	},
 	{
@@ -150,14 +156,14 @@
 		"definition": "Variable with global scope that can be accessed from all suites and keywords in a Robot Framework execution."
 	},
 	{
-		"term": "Higher-Level Suite (Suite Directory)",
-		"aliases": [],
-		"abbreviation": "",
-		"definition": "Directory treated as a suite because it directly or indirectly contains at least one suite file, grouping lower-level suites into a suite tree."
+		"term": "IF Statement",
+		"aliases": ["IF/ELSE"],
+		"abbreviation": "IF",
+		"definition": "Control structure in Robot Framework used to execute one block of statements when a condition is true and optionally alternative blocks with `ELSE IF` or `ELSE` when it is not."
 	},
 	{
-		"term": "Initialization File (__init__.robot)",
-		"aliases": [],
+		"term": "Initialization File",
+		"aliases": ["__init__.robot", "Suite Initialization File"],
 		"abbreviation": "",
 		"definition": "Suite file located in a directory that configures that directory as a suite and defines suite-level settings, variables, setups, and teardowns for contained suites."
 	},
@@ -173,12 +179,6 @@
 		"abbreviation": "",
 		"definition": "Compact single-line IF statement (`IF  <condition>  <keyword>  [args]`) used to execute one keyword conditionally without an END."
 	},
-	{
-		"term": "K-Level (Knowledge Level)",
-		"aliases": [],
-		"abbreviation": "",
-		"definition": "Categorization of learning objectives based on Bloom’s Taxonomy: K1 (Remember), K2 (Understand), and K3 (Apply), indicating expected depth of knowledge."
-	},
 	{
 		"term": "Keyword",
 		"aliases": [],
@@ -189,7 +189,7 @@
 		"term": "Keyword Interface",
 		"aliases": [],
 		"abbreviation": "",
-		"definition": "Documented information of a keyword—including name, arguments with kinds and types, return values, documentation, and examples—as exposed by HTML documentation or IDEs."
+		"definition": "Documented information about a keyword, including its name, arguments with kinds and types, return values, documentation, and examples, as exposed by HTML documentation or IDEs."
 	},
 	{
 		"term": "Keyword-Driven Specification",
@@ -203,11 +203,17 @@
 		"abbreviation": "",
 		"definition": "Collection of library keywords implemented typically in Python (or other languages) that Robot Framework imports to interact with external systems, perform computations, or provide utility functions."
 	},
+	{
+		"term": "Knowledge Level",
+		"aliases": [],
+		"abbreviation": "K-Level",
+		"definition": "Categorization of learning objectives based on Bloom’s Taxonomy: K1 (Remember), K2 (Understand), and K3 (Apply), indicating expected depth of knowledge."
+	},
 	{
 		"term": "List Variable",
 		"aliases": [],
-		"abbreviation": "",
-		"definition": "Robot Framework variable of list type accessed with the `@{}` syntax that holds an ordered collection of values and can be unpacked when passed to keywords."
+		"abbreviation": "@{}",
+		"definition": "Robot Framework variable of list type created with the `@{}` syntax that holds an ordered collection of values and can be unpacked when passed to keywords."
 	},
 	{
 		"term": "Local Variable",
@@ -216,8 +222,8 @@
 		"definition": "Variable whose scope is limited to a single keyword, test, or task execution and is not visible outside that body."
 	},
 	{
-		"term": "Log File (log.html)",
-		"aliases": [],
+		"term": "Log File",
+		"aliases": ["log.html"],
 		"abbreviation": "",
 		"definition": "Detailed HTML execution log (log.html) generated by Robot Framework that shows keyword-level execution steps, arguments, messages, and statuses."
 	},
@@ -228,10 +234,10 @@
 		"definition": "Argument kind in a keyword specification without a default value that must be provided in calls and that precedes optional arguments."
 	},
 	{
-		"term": "Metadata (Suite Metadata)",
+		"term": "Suite Metadata",
 		"aliases": [],
 		"abbreviation": "",
-		"definition": "Key–value information defined with the Metadata setting in a suite to document attributes such as author, version, or related requirements."
+		"definition": "Key–value information defined with the `Metadata` setting in a suite to document attributes such as author, version, or related requirements."
 	},
 	{
 		"term": "Named-Only Argument",
@@ -246,22 +252,22 @@
 		"definition": "Argument value provided in a keyword call using an explicit name=value pair."
 	},
 	{
-		"term": "Output File (output.xml)",
-		"aliases": [],
+		"term": "Output File",
+		"aliases": ["output.xml"],
 		"abbreviation": "",
-		"definition": "Machine-readable execution result file (output.xml) produced by Robot Framework that contains the full execution tree, messages, and statistics in XML format."
+		"definition": "Primary machine-readable execution result file (e.g. `output.xml`) produced by Robot Framework that stores the full execution tree, messages, and statistics and serves as the source for generating log and report files."
 	},
 	{
 		"term": "Optional Argument",
 		"aliases": [],
 		"abbreviation": "",
-		"definition": "Argument kind in a keyword specification that may be omitted because it has a default value or is a catch-all (such as Variable Number of Positional Arguments marked with * or Free Named Arguments marked with **)."
+		"definition": "Argument kind in a keyword specification that may be omitted because it has a default value or is a catch-all (e.g. `Variable Number of Positional Arguments` marked with `*` or `Free Named Arguments` marked with `**`)."
 	},
 	{
 		"term": "Pass Status",
 		"aliases": [],
 		"abbreviation": "",
-		"definition": "Execution status indicating that an element (such as a keyword, test, task, or suite) executed successfully and met its expectations."
+		"definition": "Execution status indicating that an element (e.g. keyword, test|task, or suite) executed successfully and met its expectations."
 	},
 	{
 		"term": "Positional Argument",
@@ -276,10 +282,10 @@
 		"definition": "Argument kind in a keyword specification that can be set either by position or by name (but not both for the same value) and that may be mandatory or optional."
 	},
 	{
-		"term": "Report File (report.html)",
-		"aliases": [],
+		"term": "Report File",
+		"aliases": ["report.html"],
 		"abbreviation": "",
-		"definition": "High-level HTML summary (report.html) of a Robot Framework execution that focuses on statistics and overall pass/fail status of suites and tests|tasks."
+		"definition": "High-level HTML summary (`report.html`) of a Robot Framework execution that focuses on statistics and the overall pass/fail status of suites and tests|tasks."
 	},
 	{
 		"term": "Resource File",
@@ -288,8 +294,8 @@
 		"definition": "File (commonly with extension .resource or .robot) that contains user keywords and variables and is imported by suites to share and reuse these artifacts."
 	},
 	{
-		"term": "Return Statement (RETURN)",
-		"aliases": [],
+		"term": "RETURN Statement",
+		"aliases": ["RETURN"],
 		"abbreviation": "",
 		"definition": "Statement used in user keywords to return one or more values that can be assigned to variables in the calling context."
 	},
@@ -302,7 +308,7 @@
 	{
 		"term": "Robotic Process Automation",
 		"aliases": ["RPA"],
-		"abbreviation": "RPA",
+		"abbreviation": "",
 		"definition": "Automation of business processes or tasks normally performed by humans, often across multiple systems, without necessarily focusing on testing."
 	},
 	{
@@ -314,7 +320,7 @@
 	{
 		"term": "Robot Framework® Certified Professional",
 		"aliases": ["RFCP"],
-		"abbreviation": "RFCP",
+		"abbreviation": "",
 		"definition": "Foundational certification level for Robot Framework that validates understanding of core concepts, syntax, and basic control structures."
 	},
 	{
@@ -324,10 +330,10 @@
 		"definition": "Top-level suite in a Robot Framework execution determined by the initial directory or file path passed to the `robot` command."
 	},
 	{
-		"term": "Scalar Access Syntax (${})",
+		"term": "Scalar Access Syntax",
 		"aliases": [],
-		"abbreviation": "",
-		"definition": "Standard variable access form in Robot Framework used to read values regardless of whether the underlying variable was defined as scalar, list-like, or dictionary-like."
+		"abbreviation": "${}",
+		"definition": "Standard variable access form `${}` in Robot Framework used to read values regardless of whether the underlying variable was defined as scalar, list-like, or dictionary-like."
 	},
 	{
 		"term": "Scalar Variable",
@@ -339,19 +345,25 @@
 		"term": "Skip Status",
 		"aliases": [],
 		"abbreviation": "",
-		"definition": "Execution status indicating that an element (such as a test or task) was intentionally not executed, for example due to selection options or an explicit skip."
+		"definition": "Execution status indicating that an element (e.g. a test|task) was intentionally not executed, for example due to selection options or an explicit skip."
 	},
 	{
-		"term": "Standard Library (Robot Framework)",
+		"term": "Standard Library",
 		"aliases": [],
 		"abbreviation": "",
 		"definition": "Library shipped with Robot Framework itself providing generic functionality such as operating system interaction, string manipulation, or process handling."
 	},
 	{
-		"term": "Suite (Test Suite / Task Suite)",
-		"aliases": [],
+		"term": "Suite",
+		"aliases": ["Test Suite", "Task Suite"],
+		"abbreviation": "",
+		"definition": "Collection of tests|tasks (optionally with local keywords and variables) defined in a .robot file or directory that is executed as a unit by Robot Framework."
+	},
+	{
+		"term": "Suite Directory",
+		"aliases": ["Higher-Level Suite"],
 		"abbreviation": "",
-		"definition": "Collection of tests or tasks (optionally with local keywords and variables) defined in a .robot file or directory that is executed as a unit by Robot Framework."
+		"definition": "Directory treated as a suite because it directly or indirectly contains at least one suite file, grouping lower-level suites into a suite tree."
 	},
 	{
 		"term": "Suite File",
@@ -385,7 +397,7 @@
 	},
 	{
 		"term": "Task",
-		"aliases": ["Test Case"],
+		"aliases": [],
 		"abbreviation": "",
 		"definition": "Executable entity in Robot Framework similar to a test case but used for non-testing automation such as RPA workflows, defined in a `*** Tasks ***` section."
 	},
@@ -393,13 +405,13 @@
 		"term": "Test Setup",
 		"aliases": ["Task Setup"],
 		"abbreviation": "",
-		"definition": "Keyword executed before an individual test or task starts to prepare preconditions specific to that test|task."
+		"definition": "Keyword executed before an individual test|task starts to prepare preconditions specific to that test|task."
 	},
 	{
 		"term": "Test Teardown",
 		"aliases": ["Task Teardown"],
 		"abbreviation": "",
-		"definition": "Keyword executed after an individual test or task finishes to clean up resources specific to that test|task."
+		"definition": "Keyword executed after an individual test|task finishes to clean up resources specific to that test|task."
 	},
 	{
 		"term": "Test Template",
@@ -409,8 +421,8 @@
 	},
 	{
 		"term": "Test Case",
-		"aliases": ["Task"],
-		"abbreviation": "Test",
+		"aliases": ["Test"],
+		"abbreviation": "",
 		"definition": "Executable specification in Robot Framework that verifies some aspect of system behavior and is defined in a `*** Test Cases ***` section."
 	},
 	{
@@ -423,13 +435,13 @@
 		"term": "Test Level",
 		"aliases": [],
 		"abbreviation": "",
-		"definition": "Classification of testing focus (such as unit, component, integration, system, system integration, acceptance, or end-to-end) describing scope and granularity of tests."
+		"definition": "Classification of testing focus (e.g. unit, component, integration, system, system integration, acceptance, or end-to-end) describing scope and granularity of tests."
 	},
 	{
 		"term": "Test Tag",
 		"aliases": ["Task Tag"],
 		"abbreviation": "",
-		"definition": "Label assigned to tests or tasks via the Tags setting to categorize them and enable filtering, selection, and reporting."
+		"definition": "Label assigned to tests|tasks via the Tags setting to categorize them and enable filtering, selection, and reporting."
 	},
 	{
 		"term": "Test Timeout",
@@ -465,7 +477,7 @@
 		"term": "Variable Scope",
 		"aliases": [],
 		"abbreviation": "",
-		"definition": "Visibility and lifetime of a variable (such as global, suite, test|task, or local) during a Robot Framework execution."
+		"definition": "Visibility and lifetime of a variable (e.g. global, suite, test|task, or local) during a Robot Framework execution."
 	},
 	{
 		"term": "WHILE Loop",