diff --git a/docs/documentation/libraries/airfoils/index.md b/docs/documentation/libraries/airfoils/index.md
new file mode 100644
index 0000000000000000000000000000000000000000..ffe1955d9521e0400cad37d4be7d8d859c240d49
--- /dev/null
+++ b/docs/documentation/libraries/airfoils/index.md
@@ -0,0 +1,92 @@
+# The `Airfoils` library
+
+**Description:**
+This file is part of UNICADO. It implements the `Airfoils` class which manages airfoil data stored in files. The class provides functionality to load airfoil files from a specified directory, print the available airfoils, retrieve airfoil polygon data, and copy airfoil files to a target directory.
+
+---
+
+## Class: Airfoils
+
+### Overview
+- **Purpose:** Manages airfoil data by loading airfoil files from a directory and providing methods to interact with them.
+- **Key Responsibilities:**
+    - Load airfoil data from a given directory.
+    - Maintain a collection (`available_airfoils`) that maps airfoil names to their file paths.
+    - Provide methods to print, retrieve, and copy airfoil data.
+
+---
+
+### Constructor
+
+#### `Airfoils(const std::filesystem::path& path_to_airfoil_directory)`
+- **Description:** Initializes the `Airfoils` object by loading airfoil files from the provided directory.
+- **Parameters:**
+    - `path_to_airfoil_directory`: Filesystem path to the directory containing airfoil files.
+- **Behavior:**
+    - Checks if the provided directory exists.
+    - If not, throws an error using `throwError` with a formatted message.
+    - Calls the private method `add_directory_airfoils(path_to_airfoil_directory)` to populate the `available_airfoils` map.
+
+---
+
+### Public Methods
+
+#### `void print_available_airfoils()`
+- **Description:** Prints the list of available airfoils with their names and file paths.
+- **Behavior:**
+    - Iterates over the `available_airfoils` map and prints each entry using formatted output.
+    - Uses `std::cout` or a runtime logging stream (`myRuntimeInfo->out`) if available.
+
+---
+
+#### `geom2::Polygon_2 get_airfoil(const std::string& airfoil)`
+- **Description:** Retrieves the polygon data of the specified airfoil.
+- **Parameters:**
+    - `airfoil`: Name of the airfoil.
+- **Return:**
+    - A `geom2::Polygon_2` object representing the airfoil's polygon data.
+- **Behavior:**
+    - Searches for the airfoil in the `available_airfoils` map.
+    - If the airfoil is not found, throws an error.
+    - Otherwise, reads and returns the airfoil data using `geom2::io::read_airfoil`.
+
+---
+
+#### `void copy_available_airfoil(const std::string& airfoil, const std::filesystem::path& target_directory)`
+- **Description:** Copies the specified airfoil file to a target directory.
+- **Parameters:**
+    - `airfoil`: Name of the airfoil.
+    - `target_directory`: Filesystem path to the destination directory.
+- **Behavior:**
+    - Checks if the target directory exists; if not, throws an error.
+    - Validates that the airfoil is available in the `available_airfoils` map; if not, throws an error.
+    - Compares the absolute paths of the source (airfoil file) and the target directory.
+        - If they are the same, logs that the copying is skipped.
+    - Attempts to copy the airfoil file using `std::filesystem::copy` with the `update_existing` option.
+    - Catches any exceptions during copying and rethrows them using `throwError`.
+
+---
+
+### Private Methods
+
+#### `void add_directory_airfoils(const std::filesystem::path& path_to_airfoil_directory)`
+- **Description:** Adds all airfoil files from the specified directory to the `available_airfoils` map.
+- **Parameters:**
+    - `path_to_airfoil_directory`: Filesystem path to the directory containing airfoil files.
+- **Behavior:**
+    - Verifies that the directory exists; if not, throws an error.
+    - Iterates over each entry in the directory using `std::filesystem::directory_iterator`.
+    - For each entry, calls the private method `add_airfoil(entry.path())`.
+
+---
+
+#### `void add_airfoil(const std::filesystem::path& airfoil_path)`
+- **Description:** Adds a single airfoil file to the `available_airfoils` map.
+- **Parameters:**
+    - `airfoil_path`: Filesystem path to the airfoil file.
+- **Behavior:**
+    - Checks if the file exists; if not, throws an error.
+    - Verifies that the path is a regular file and has a `.dat` extension.
+    - Extracts the airfoil name (using the filename's stem) and inserts it into the `available_airfoils` map.
+
+---
diff --git a/docs/documentation/libraries/aixml/endnode/getting-started.md b/docs/documentation/libraries/aixml/endnode/getting-started.md
new file mode 100644
index 0000000000000000000000000000000000000000..55c65612392f7dbcfb6d424bff44cc44aeef7715
--- /dev/null
+++ b/docs/documentation/libraries/aixml/endnode/getting-started.md
@@ -0,0 +1,45 @@
+# How to use the Endnode
+This section gives simple examples on how to use an endnode.
+
+!!! note
+    The values and variables are for tutorial purpose only
+
+## Creating and using a numeric endnode
+
+```cpp
+// Example: Create a numeric endnode for a value representing length in meters.
+Endnode<double> lengthNode("/path/to/wanted/endnode", "Aircraft Length", 10.0, "m", 5.0, 20.0);
+
+// Read from an XML node
+lengthNode.read(xml_node);
+
+// Update the value and then update the XML node
+lengthNode.set_value(12.5);
+lengthNode.update(xml_node);
+
+```
+
+## Creating and using a non-numeric endnode
+
+```cpp
+// Example: Create a string endnode for an aircraft model identifier.
+Endnode<std::string> modelNode("/path/to/string/endnode", "Aircraft Model", "A320");
+
+// Read and print the node
+modelNode.read(xml_node);
+modelNode.print();
+```
+
+## Creating and using a read-only Endnode
+```cpp
+// Example: Create a read-only endnode for a boolean
+EndnodeReadOnly<bool> readOnlyNode("/path/to/boolean/endnode");
+
+// Read the XML data
+readOnlyNode.read(xml_node);
+
+// Print both the parsed and original XML values
+// This will have only effect if it's working on a numeric node and if the numeric node is a none SI (but valid)
+readOnlyNode.print_xml();
+```
+
diff --git a/docs/documentation/libraries/aixml/endnode/index.md b/docs/documentation/libraries/aixml/endnode/index.md
new file mode 100644
index 0000000000000000000000000000000000000000..9ce745d5324d46c61607c2d18b6cd3dc1618875c
--- /dev/null
+++ b/docs/documentation/libraries/aixml/endnode/index.md
@@ -0,0 +1,137 @@
+# The `endnode` in UNICADO
+
+The `endnode` is a main access point to the aircraft exchange file and lets you interface the different nodes (leafs) in an easy way. This class is build on top of the aixml class (no inheritance) which is used for raw access of xml file content.
+
+## Overview
+
+The `endnode` implements templated classes that define an endnode as a part of an XML document. An `endnode` is the final element in a node hierarchy, representing a leaf node that contains a value and in the case of numeric nodes, its associated unit, lower and upper boundaries.
+
+The classes support:
+
+- **Numeric types** (any arithmetic type except `bool`)
+- **Boolean types** (`bool`)
+- **String type** (`std::string`)
+
+Each variant comes with its own constructors and methods to read from or update XML nodes. For numeric types, additional checks ensure that the value remains within specified boundaries and that units are valid according to SI or allowed custom conversions.
+
+## Code Structure
+
+### Concept: `is_numeric`
+
+- **Purpose:** Defines a concept that accepts arithmetic types excluding `bool`.
+- **Usage:** Used to restrict template instantiation for numeric operations.
+
+```cpp
+template <typename T>
+concept is_numeric = (std::is_arithmetic<T>::value && (!std::is_same<T, bool>::value));
+```
+
+For `std::string` and `bool` the concept is_numeric is used with logic operators:
+### For boolean:
+
+- **Purpose:** Adapts is_numeric concept that accepts bool type.
+- **Usage:** Used to restrict template instantiation for numeric operations.
+
+```cpp
+template <typename T>
+!is_numeric<T> && std::is_same<T, bool>::value
+```
+
+### For strings:
+
+- **Purpose:** Adapts is_numeric that accepts strings.
+- **Usage:** Used to restrict template instantiation for std::string operations.
+
+```cpp
+template <typename T>
+!is_numeric<T> && std::is_same<T, std::string>::value
+```
+
+
+### Class: EndnodeBase
+
+**Template Parameter:**
+
+- `T` - the type of value the endnode holds (arithmetic, bool, or std::string).
+
+**Responsibilities:**
+
+- Provides common functionality for reading XML node attributes.
+- Initializes node paths and default values.
+- Implements methods for:
+    - Reading node content from an XML node.
+    - Printing node values.
+    - Checking and converting units (for numeric types).
+    - Validating that a numeric value lies within defined boundaries.
+
+**Constructors:**
+
+- Overloaded to handle numeric types, booleans, and strings.
+- Allows setting default values, units, and boundaries.
+
+**Key Methods:**
+
+- `read(const node& xml)`: Reads XML node data.
+- `print()`: Prints the node's content.
+- `check_boundaries()`: Ensures numeric values are within allowed limits.
+- `check_unit()`: Validates unit correctness and handles custom-to-SI conversion if needed.
+- `convert_items()`: Converts values to SI units when a custom unit is used.
+
+**Internal Data Members:**
+
+- `description_`: A string description of the node.
+- `paths`: A vector of strings storing the XML path parts.
+- `value_`, `lower_boundary_`, `upper_boundary_`: Numeric values (for numeric types).
+- `unit_`: The unit associated with the numeric value.
+- Several constant collections for SI units and unit conversion factors.
+
+---
+
+### Class: Endnode
+
+**Inheritance:**
+
+- Derives from `EndnodeBase<T>`.
+
+**Purpose:**
+
+- Provides a concrete implementation of an endnode with capabilities to read from and update an XML node.
+
+**Additional Methods:**
+
+- `update(node& xml)`: Updates the XML node with the current values. Different overloads exist for numeric, boolean, and string types.
+- Overloaded arithmetic operators (`+=`, `-=`, `*=`, `/=`) for numeric types.
+- Assignment operators to easily update values or boundaries.
+- Setter methods for changing the node’s value, unit, and boundaries.
+
+**Usage Scenario:**
+
+- Use this class when you need to modify XML data – both reading from and writing to an XML document.
+
+---
+
+### Class: EndnodeReadOnly
+
+**Inheritance:**
+
+- Also derived from `EndnodeBase<T>`.
+
+**Purpose:**
+
+- Represents an XML endnode whose value is read-only after the initial XML read.
+
+**Differences from Endnode:**
+
+- Stores original XML values in separate members (`value_xml_`, `unit_xml_`, etc.).
+- Provides methods to print or retrieve the raw, unparsed XML data.
+
+**Key Methods:**
+
+- `read(const node& xml)`: Reads the XML data and stores both parsed and original (XML) values.
+- `print_xml()`: Prints the original XML values (format differs for numeric and non-numeric types).
+- Getters to access the raw XML values directly.
+
+The `EndnodeReadOnly` is mainly used for configuration files since those data should not be altered by the module. For classic access and updating, use the Endnode class.
+
+!!! danger "Important"
+    None SI units will be converted automatically to SI units by the given table in the endnode.h file when reading. Have a look at valid units in [valid units](valid_units.md)
diff --git a/docs/documentation/libraries/aixml/endnode/valid_units.md b/docs/documentation/libraries/aixml/endnode/valid_units.md
new file mode 100644
index 0000000000000000000000000000000000000000..a19850b13707462613247c3c4368a6e11ca722a9
--- /dev/null
+++ b/docs/documentation/libraries/aixml/endnode/valid_units.md
@@ -0,0 +1,59 @@
+# Allowed SI Units and how it is converted
+
+### SI Units Table
+
+| Unit   | Description                   |
+|--------|-------------------------------|
+| m      | meter                         |
+| m^2    | squaremeter                   |
+| m^3    | cubicmeter                    |
+| m/s    | meter per second              |
+| rad    | radian                        |
+| 1      | no unit                       |
+| Pa     | pascal                        |
+| kg     | kilogram                      |
+| kg/s   | kilogram per second           |
+| kg/Ns  | kilogram per newton second    |
+| s      | second                        |
+| J      | Joule                         |
+| J/kg   | Joule per kilogram            |
+| J/m^3  | Joule per cubic meter         |
+| W      | Watt                          |
+| V      | volt                          |
+| A      | ampere                        |
+| N      | newton                        |
+| N/m^2  | newton per square meter       |
+| kg/m^2 | kilogram per square meter     |
+| kg/m^3 | kilogram per cubic meter      |
+| kgm^2  | kilogram square meter         |
+| K      | Kelvin                        |
+| EUR    | Euro                          |
+| US     | Dollar                        |
+
+### Custom to SI Units Conversion Table
+
+| Custom Unit  | SI Unit |
+|--------------|---------|
+| deg          | rad     |
+| ft           | m       |
+| FL           | m       |
+| NM           | m       |
+| lbs          | kg      |
+| lbs/min      | kg/s    |
+| EUR          | EUR     |
+| US           | US      |
+| g            | 1       |
+| dBA          | Pa      |
+| EPNdB        | Pa      |
+| Sone         | Pa      |
+| h            | s       |
+| min          | s       |
+| a            | s       |
+| ft/min       | m/s     |
+| kts          | m/s     |
+| KCAS         | m/s     |
+| l            | m^3     |
+| Celsius      | K       |
+| micro meter  | m       |
+| kg/h         | kg/s    |
+
diff --git a/docs/documentation/libraries/aixml/index.md b/docs/documentation/libraries/aixml/index.md
new file mode 100644
index 0000000000000000000000000000000000000000..c1d085aa0d1bb0e2e6f55ba6e38ed917b8fc51ea
--- /dev/null
+++ b/docs/documentation/libraries/aixml/index.md
@@ -0,0 +1,11 @@
+# The aixml library
+
+This library purpose is to interact with xml files, especially for accessing xml files like the aircraft exchange file and the module configuration files.
+
+## Aixml
+
+This library contains methods for "raw" accessing of xml files based on the tinyxml library
+
+## Endnode
+
+This library contains template classes especially for the usage in UNICADO and should  be used in each C++ module for easy accessing nodes.
diff --git a/docs/documentation/libraries/index.md b/docs/documentation/libraries/index.md
index 479b8dd7febc3e2b36d5a8ef3c7fe212edb8d525..a2d47165de35b70bbd99159d54b8a4e9a804d79b 100644
--- a/docs/documentation/libraries/index.md
+++ b/docs/documentation/libraries/index.md
@@ -50,7 +50,7 @@ The **airfoils** libary provides a database for different airfoils.
 
 |Module Version|Language|License|Documentation|Dependencies|
 |:---:|:---:|:---:|---|---|
-|0.5.0|:simple-cplusplus: |GPLv3|-|-|
+|0.5.0|:simple-cplusplus: |GPLv3|[Link](airfoils/index.md)|-|
 
 ---
 
@@ -62,7 +62,7 @@ It uses a simple XML library, namely *tinyxml*, to read and parse the XML files.
 
 |Module Version|Language|License|Documentation|Dependencies|
 |:---:|:---:|:---:|---|---|
-|0.5.0|:simple-cplusplus: |GPLv3|-|-|
+|0.5.0|:simple-cplusplus: |GPLv3|[Link](aixml/index.md)|[tinyxml](https://github.com/leethomason/tinyxml2)|
 
 ---
 
@@ -105,7 +105,7 @@ The engine decks can originate from different softwaretools as long as they prov
 ## extern
 UNICADO currently uses two external libaries as submodules:
 
-- `doxygen-awesome-css` for documentation formation [(see here)](https://github.com/jothepro/doxygen-awesome-css.git)
+- `doxygen-awesome-css` for documentation formation (LEGACY - will be removed) [(see here)](https://github.com/jothepro/doxygen-awesome-css.git)
 - `pybind11` to use C++ libraries in the python tools [(see here)](https://github.com/pybind/pybind11.git)
 
 ---
@@ -135,6 +135,28 @@ The library gives a template how modules should be structured and gives helpers
 
 ---
 
+## pyavlpackage
+![Icon](site:assets/images/documentation/pymodulepackage.svg){.overview-img align=left}
+This library provides the core functionality to work with Athena Vortex Lattice (AVL) from M. Drela which is released under GPL.
+{.overview-item}
+
+|Module Version|Language|License|Documentation|Dependencies|
+|:---:|:---:|:---:|---|---|
+|0.5.0|:simple-cplusplus: |GPLv3|-|[AVL](https://web.mit.edu/drela/Public/web/avl/)|
+
+---
+
+## pyavlunicadopackage
+![Icon](site:assets/images/documentation/pymodulepackage.svg){.overview-img align=left}
+This library provides the core functionality to work with Athena Vortex Lattice (AVL) from M. Drela which is released under GPL using the pyavlpackage and the unicado geometry based on aircraftgeoemtry2.
+{.overview-item}
+
+|Module Version|Language|License|Documentation|Dependencies|
+|:---:|:---:|:---:|---|---|
+|0.5.0|:simple-cplusplus: |GPLv3|-|[AVL](https://web.mit.edu/drela/Public/web/avl/)|
+
+---
+
 ## pymodulepackage
 ![Icon](site:assets/images/documentation/pymodulepackage.svg){.overview-img  align=left}
 This library provides standardized UNICADO data preprocessing, run, and postprocessing functions for Python modules.
@@ -196,4 +218,4 @@ In addition, it defines some common **constants** which are useful for calculati
 
 |Module Version|Language|License|Documentation|Dependencies|
 |:---:|:---:|:---:|---|---|
-|0.5.0|:simple-cplusplus: |GPLv3|-|-|
\ No newline at end of file
+|0.5.0|:simple-cplusplus: |GPLv3|-|-|
diff --git a/docs/documentation/sizing/wing_design/design-methods.md b/docs/documentation/sizing/wing_design/design-methods.md
index 6d8e1f0a2c336670c4f35d159967f6a95fb6b4a2..323feb1389904d243e71d8bc52f71721e3673827 100644
--- a/docs/documentation/sizing/wing_design/design-methods.md
+++ b/docs/documentation/sizing/wing_design/design-methods.md
@@ -36,7 +36,7 @@ If the limits are exceeded which are defined in the aircraft exchange file in th
 After computing the aspect ratio, the taper ratio can be user defined or determined by a method from Howe. Howe uses the aspect ration and the quarter chord sweep to compute the taper ratio.
 
 #### Step 5: Dihedral computation
-The next step computes the dihedral which can be set by user or will be computed based on limits defined by Howe or Raymer. Since both, Howe and Raymer just give limitations, the dihedral as a mean value between the minimum and maximum values. Howe differentiates between sweept and unsweept while Raymer includes the mach state of the aircraft.
+The next step computes the dihedral which can be set by user or will be computed based on limits defined by Raymer. Raymer only defines limitations, so the dihedral is calculated as a mean value between the minimum and maximum values. Raymer differentiates between swept and unswept, including the mach state (transonic / supersonic) of the aircraft.
 
 #### Step 6: Calculate geometry
 Based on the computed data and the information from the aircraft exchange file, it will be determined if the wing geometry will be calculated with a kink or not. The kink is enabled when the _landing gear_ is _wing mounted_ and the wing is mounted _low_. Otherwise it uses an unkinked geometry.
@@ -49,6 +49,6 @@ The unkinked geometry calculation is straight forward, however the kinked versio
 The spar positions and control devices can be set by user. For control devices, a basic set of control devices will be set consisting of an aileron, and a number of high lift devices and spoilers for air and ground.
 
 #### Step 8: Mass calculation
-With the wing finished, the mass of the wing will be computed by two different methods, one is the Flight Optimization System (Flops) method and the other is a Method from Chiozzotto (PhD Thesis). Both methods allow changes in material while Flops uses a factor from 0 to 1 to vary the ratio between aluminim and composite materials while Chiozzotto sets two materials - _AL_ for aluminium and _CFRP_ for carbon fibre reinforced plastics.
+With the wing finished, the mass of the wing will be computed by two different methods, one is the Flight Optimization System (Flops) method and the other is a Method from Chiozzotto (PhD Thesis). Both methods allow changes in material while Flops uses a factor from 0 to 1 to vary the ratio between aluminum and composite materials while Chiozzotto sets two materials - _AL_ for aluminum and _CFRP_ for carbon fibre reinforced plastics.
 
 For the determination of the center of gravity and the position, again empirical methods from Howe are used.
diff --git a/docs/documentation/sizing/wing_design/index.md b/docs/documentation/sizing/wing_design/index.md
index d60a3ecd22277dc877d1484930eb6f33e26730e9..d8d1eb12a1c1dd2f86b79523fe760b5e4ad8d34d 100644
--- a/docs/documentation/sizing/wing_design/index.md
+++ b/docs/documentation/sizing/wing_design/index.md
@@ -1,5 +1,5 @@
 # Introduction {#mainpage}
-The wing is an essential part of an aircraft, therefore the _wing\_design_ tool is one of the core design tools in UNICADO and enables the workflow to design wings according to specified requirements and design specifications. 
+The wing is an essential part of an aircraft, therefore the _wing\_design_ tool is one of the core design tools in UNICADO and enables the workflow to design wings according to specified requirements and design specifications.
 
 According to the workflow, the tool requires a valid _Aircraft Exchange File_ with inputs from the tools _initial\_sizing_ and _fuselage\_design_.
 
@@ -17,20 +17,20 @@ According to the workflow, the tool requires a valid _Aircraft Exchange File_ wi
 ## Summary of features
 Here is a quick overview of what the tool is currently capable of including a preview which is planned:
 
-| Configuration     | Wing Type  | Methods |                           Status |
-|-------------------|------------|---------|:---------------------------------:|
-| tube-and-wing     | Cantilever | TUB     |       running :white_check_mark: |
-| blended-wing-body | ...        | ...     | under development :construction: |
+| Configuration     | Wing Type  | Methods |                 Status                  |
+|-------------------|------------|---------|:---------------------------------------:|
+| tube-and-wing     | Cantilever | TUB     | running :octicons-feed-issue-closed-16: |
+| blended-wing-body | ...        | ...     |    under development :construction:     |
 
 ## A User's Guide to Wing Design
 The _wing\_design_ tool will help you design various wings for classical configurations to blended wing body configurations (in the future). This user documentation will guide you through all necessary steps to understand the tool as well as the necessary inputs and configurations to create a new wing from scratch.
 
 The following pages will guide you through the process of generating your first wing within UNICADO:
 
-[:octicons-arrow-right-16: Basic Concepts](basic-concepts.md)   
-[:octicons-arrow-right-16: Getting Started](getting-started.md)   
-[:octicons-arrow-right-16: Design Methods](design-methods.md)   
-[:octicons-arrow-right-16: Design your first wing](run-your-first-wing-design.md)   
+[:octicons-arrow-right-16: Basic Concepts](basic-concepts.md)
+[:octicons-arrow-right-16: Getting Started](getting-started.md)
+[:octicons-arrow-right-16: Design Methods](design-methods.md)
+[:octicons-arrow-right-16: Design your first wing](run-your-first-wing-design.md)
 
 So let's get started!
 
@@ -41,10 +41,10 @@ If you are familiar with these concepts and want to contribute - head over to th
 
 The following pages will help you understand the build process code structure:
 
-[:octicons-arrow-right-16: Prerequisites](prerequisites.md)   
-[:octicons-arrow-right-16: Build the code](../../../get-involved/build-instructions/build/python.md)   
-[:octicons-arrow-right-16: Wing module structure](module-structure.md)   
-[:octicons-arrow-right-16: Method template](method-template.md)   
+[:octicons-arrow-right-16: Prerequisites](prerequisites.md)
+[:octicons-arrow-right-16: Build the code](../../../get-involved/build-instructions/build/python.md)
+[:octicons-arrow-right-16: Wing module structure](module-structure.md)
+[:octicons-arrow-right-16: Method template](method-template.md)
 
 We appreciate it!
 
diff --git a/docs/get-involved/modularization/cpp-modularization.md b/docs/get-involved/modularization/cpp-modularization.md
index 290726f7028be621aedecd7c1d182e9da737af05..7acf710dc35d7bac9a7af3fecd91341937fb9528 100644
--- a/docs/get-involved/modularization/cpp-modularization.md
+++ b/docs/get-involved/modularization/cpp-modularization.md
@@ -64,11 +64,11 @@ The class provides several public methods for various operations:
 
 - `showRuntime()` - Prints runtime information, e.g. program name, enabled flags etc.
 - `showDirectories()` - shows stored directories in directories_ map.
-- `getIODir()`, `getGeometryDir()` and other similar functions which return the path w/o ending seperator
-- `createGeometryDir()`, `createAirfoilDataDir()` and other similar functions which create the directoryif not existent
+- `getIODir()`, `getGeometryDir()` and other similar functions which return the path w/o ending separator
+- `createGeometryDir()`, `createAirfoilDataDir()` and other similar functions which create the directory if not existent
 - `checkFileExistence()` - checks if a file exists by specific argument
 - `create_common_directories` - creates standard output directories if not existent
-- `addDir()` - adds a directory to the directories_ map and creates it if not existent. The key will be specified in upper case letters
+- `add_directory()` - adds a directory to the directories_ map and creates it if not existent. The key will be specified in upper case letters
 - `reopenAcXML()` - reopens the aircraftXML - please make sure to (save and) close the acxml before
 - `saveAcXML()` - saves the current acxml node from the runtimeIO instantiation
 - `closeAcXML()` - closes the current acxml node from the runtimeIO instantiation
@@ -232,13 +232,14 @@ modeSelection = Modeselector("mode_2")
 modi selectedMode = modeSelection.get(); // selectedMode = 2
 ```
 
-## Intermediate level
+## Intermediate level (Virtual) and low level
 
-### Strategy and StrategySelector
+The intermediate level is at the current state a virtual level which routes you to your desired strategy (called so, since we use the strategy pattern to define it). However, the strategy itself specifies a new method which can be integrated. The intermediate level itself just describes the route to it. So you can think of it as a tree.
+The low level actual implements the new strategy (or method, however you want to call it for yourself). Since intermediate level and low level are somewhat connected, we will show what you need to create a new _strategy_ and how you can run such a strategy from the top level using the so called `StrategySelector`.
 
-The intermediate level, which describes the routing from top to low level, uses the so called **Strategy Design Pattern**. This pattern allows to set a specific strategy at first place and let it run through Selector, in this case the `StrategySelector` class (`strategySelector.h`, header-only).
+### Strategy
 
-Each strategy, such as the low-fidelity strategy or high-fidelity strategy, is implemented as a class that inherits from the base class `Strategy`. The `Strategy` base class defines the following pure virtual methods:
+Each strategy, such as e.g. a low-fidelity strategy or a high-fidelity strategy, is implemented as a class that inherits from the base class `Strategy`. The `Strategy` base class defines the following pure virtual methods which is defined inside the `strategySelector.h` header:
 
 - `initialize()`
 - `run()`
@@ -259,48 +260,11 @@ public:
     virtual void save() = 0;
     virtual ~Strategy() {};
 };
-```
-The `StrategySelector` class serves as a selector for strategies. It manages a dynamic allocation of a strategy using a `std::unique_ptr`. The class provides member functions to set the strategy, initialize the strategy with a given configuration class, run, update, report and save the strategy. Methods for this are:
 
-- `setStrategy()`
-- `initializeStrategy()`
-- `runStrategy()`
-- `updateStrategy()`
-- `reportStrategy()`
-- `saveStrategy()`
 
-The code for the class:
+The Strategy class is given as a basic template which should be used. However, an adaption of Input/Output types might be necessary but must be clearly stated.
 
-```c++
-class StrategySelector
-{
-public:
-    void setStrategy(std::unique_ptr<Strategy> strategy) {
-        strategy_ = std::move(strategy);
-    }
-    void initializeStrategy() {
-        strategy_->initialize();
-    }
-    void runStrategy() {
-        strategy_->run();
-    }
-    void updateStrategy() {
-        strategy_->update();
-    }
-    void reportStrategy() {
-        strategy_->report();
-    }
-    void saveStrategy() {
-        strategy_->save();
-    }
-private:
-    std::unique_ptr<Strategy<> strategy_;
-};
-```
-
-The Strategy and StrategySelector classes are given as basic templates which should be used. However, an adaption of Input/Output types might be necessary but must be clearly stated.
-
-To use these classes, a minimal example can be seen below:
+To use the class, a minimal example can be seen below:
 
 ```c++
 #include "strategySelector.h"
@@ -316,7 +280,7 @@ public:
 	void report() { std::cout << "report low" << std::endl; }
 	void save() { std::cout << "save low" << std::endl; }
 
-        const std::shared_ptr<RuntimeIO>& rtIO;
+  const std::shared_ptr<RuntimeIO>& rtIO;
 };
 
 class High : public Strategy
@@ -331,81 +295,56 @@ public:
 
 	const std::shared_ptr<RuntimeIO>& rtIO;
 };
+```
 
-int main(void) {
+Here, we have two strategies - a `low` strategy and a `high` strategy which inherit the base class `Strategy` and implement the necessary pure virtual methods. So we've now the low level and the top level. How to get to one of the strategies right now? Here the `StrategySelector` class will be introduced:
 
-	StrategySelector strategyholder;
-        const std::shared_ptr<RuntimeIO> rtIO = std::make_shared<RuntimeIO>(.....);
-	strategyholder.setStrategy(std::make_unique<Low>(rtIO));
+The `StrategySelector` class serves as a selector for strategies. It manages a dynamic allocation of a strategy using a `std::unique_ptr`. The class provides two major functions which will do the job you want to get to the strategy you want:
 
-	strategyholder.runStrategy();
+- `registerStrategy<strategy>(std::vector<std::string>)` - registers the `strategy` under a specific path defined by a vector of strings
+- `setStrategy(std::vector<std::string> , std::shared_ptr<RuntimeIO>)` - sets a registered strategy based on a vector of strings and an instance of a smart pointer of RuntimeIO.
 
-	strategyholder.setStrategy(std::make_unique<High>());
-	strategyholder.runStrategy();
-	strategyholder.saveStrategy();
-	return 0;
-}
-```
+The first method allows you to set up the method you want and the second allows you to set the method you want to use. So we go a step further and setup the example for the `Low` and `High` strategy:
 
-Output generated:
+```c++
+int main(void) {
 
-```bash
-$ ./a.exe
-run low
-run high
-save high
-```
-With `setStrategy`, a strategy will be selected and the RuntimeIO shared smart pointer is handed over to the strategy as a reference. All other calls via `strategyholder` will call methods from the *Low class strategy*. However, the strategy is changed after the first call of `runStrategy`, so below that second `setStrategy` statement, Methods within *High Strategy* are called.
+  // Define the strategyselector as strategy
+	StrategySelector strategy;
 
-The strategy is selected via a routing table system. To improve readability for the routing table, the file `strategySelector.h` provides two overlays:
+  // Get an RuntimeIO instance as a smart shared pointer
+  const std::shared_ptr<RuntimeIO> rtIO = std::make_shared<RuntimeIO>(.....);
 
-- `strategyptr` - `std::unique_ptr<Strategy>(const std::shared_ptr<RuntimeIO>&`
-- `strategyaccess` - `std::function<strategyptr>`
+  // Register your strategy by defining a path to the associated
+  strategy.registerStrategy<Low>({"low"})
+  strategy.registerStrategy<High>({"high"})
 
-A routing table is defined in a method inside the derived module class. As an example for empennage_design:
+  // Sets the strategy - here hardcoded selection of "high"
+  strategy.setStrategy({"high"}, rtIO);
 
-```c++
-strategyaccess EmpennageDesign::routing_(const std::vector<std::string>& route) {
-
- /* Routing table */
- std::map<std::string,std::map<std::string,std::map<std::string,strategyaccess>>> table = {
-   {"TAW",
-     std::map<std::string,std::map<std::string,strategyaccess>>{
-       {"CONVENTIONAL",
-         std::map<std::string,strategyaccess>{
-           {"LOW",[](const std::shared_ptr<RuntimeIO>& arg) {return std::make_unique<LowConventionalTaw>(arg);}},
-         }
-       },
-     }
-   },
-   {"BWB",
-     std::map<std::string,std::map<std::string,strategyaccess>>{
-       {"FINS",
-         std::map<std::string,strategyaccess>{
-           {"LOW",[](const std::shared_ptr<RuntimeIO>& arg) {return std::make_unique<LowFinsBwb>(arg);}},
-           {"MID",[](const std::shared_ptr<RuntimeIO>& arg) {return std::make_unique<MidFinsBwb>(arg);}}
-         }
-       }
-     }
-   }
- };
-
- return table[route.at(0)][route.at(1)][route.at(2)];
+  // Afterwards you can run also any of the implemented pure virtual methods which are defined in the currently set strategy like
+  strategy.runStrategy()
+	return 0;
 }
 ```
 
-`[](const std::shared_ptr<RuntimeIO>& arg) {return std::make_unique<LowFinsBwb>(arg)` is a lambda function which handle is returned from the routing_ table.
+With `setStrategy`, a strategy will be selected and the RuntimeIO shared smart pointer is handed over to the strategy as a reference.
 
 Inside the module constructor, the strategy is set by
 
 ```c++
-EmpennageDesign::EmpennageDesing(...) : Module(...) {
-  // read route from configuration file and store into std::vector<std::string> route_; name of vector might differ if there are more than one strategy to call
-  strategy_.setStrategy(routing_(route)(rtIO_));
+EmpennageDesign::EmpennageDesign(...) : Module(...) {
+  // read route from configuration file and store into std::vector<std::string> route; name of vector might differ if there are more than one strategy to call
+  std::vector<std::string> route = ... // Directly set up route - might not be necessary
+  ...
+  // Strategy registration
+  strategy.registerStrategy<...>(...);
+  ...
+  strategy.setStrategy(route, rtIO_);
   ...}
 ```
 
-The parameter for strategy set is called by invoking `routing_(...)` with the `route` vector which returns the handle for the selected strategy from the routing table according to the route. With `...(rtIO_)`, the returned handle is called with the `RuntimeIO` object `rtIO_` as an argument. The result is than handed over to the setStrategy method.
+The routing is done via a vector of `std::string` which can be anything (like keywords defining the aircraft type, the fidelity level of your method/strategy, the aircraft configuration or anything else). These strings build up the tree for the selection. If there is a registered strategy under such a vector string, you can access the strategy via setStrategy. Otherwise you get an error that the desired method is not existing.
 
 If you'd like to add your own module, you can choose the structure of your routing table freely. Existing UNICADO modules use for example following layers:
 
@@ -415,30 +354,29 @@ If you'd like to add your own module, you can choose the structure of your routi
 - method name
 - ...
 
-### The Fidelities {#fidelities}
+??? info "Fidelities"
+    The modularization was introduced for different fidelities. However this might not fit for all modules. If you have methods/strategies for certain fidelities, please stick to our fidelity list:
 
-The fidelity of each methods can be classified as low, mid, higher, high and own as follows:
+      - `low` - empirical methods
+      - `mid` - semi-empirical methods
+      - `higher` - analytical methods
+      - `high` - numerical methods
+      - `own` - own method (experimental)
 
-- `low` - empirical methods
-- `mid` - semi-empirical methods
-- `higher` - analytical methods
-- `high` - numerical methods
-- `own` - own method (experimental)
-
-## Low level
-
-!!!note
+### The low level
+This is a short recap of the former description. Make sure to have the strategy pure virtuals with you.
+??? note
     The low level implementations members should be public only. This has different reasons:
 
     1. There is no method next to the current
     2. To keep the overhead of the class as small as possible (no setter/getter methods which must be provided for private members)
-    3. Due to pep8 conventions (python normally has no private / protected members)
+    3. Due to pep8 conventions (python normally has no private / protected members) - yes naming convention is pep8 (even if it is not handled everywhere correctly, since it started somewhere else)
     4. isocpp: all private or all public - no mixture
 
 On the low level, the implementation of the algorithms is focused. Here you can structure your implementations according to the five base methods:
 
 - `initialize` - initialize your module to your needs and your output data by reading and preparing the data.
-- `run` - Here happens your wizardy stuff, sometimes muggle-like, sometime not 🧙.
+- `run` - Here happens your wizardly stuff, sometimes muggle-like, sometime not 🧙.
 - `update` - lets you call the update methods within the IOData class
 - `save` - if you opened any specific document during your module execution, you can save the data within this method and close the data.
 
@@ -490,12 +428,15 @@ public:
 /* LOW FIDELITY CONFIGS END */
 ```
 
+To see an example for this, have a look at `wing_design` module or `empennage_design` module.
+
+
 ### Report
 
 For report generation, a dedicated Report class (`report.h`) can be used. It offers access to HTML and Tex streams. Public methods are the following:
 
 - `Report` - Constructor
-- `setAircraftName` - Set the aircraftname for report documents
+- `setAircraftName` - Set the aircraft name for report documents
 - `generateReports` - generates reports based on settings from RuntimeIO (in case a module writes more than one report, individual names can be used)
 - `htmlReportStream` - returns the html report output stream
 - `texReportStream` - returns the tex report output stream
@@ -504,7 +445,7 @@ For report generation, a dedicated Report class (`report.h`) can be used. It off
 - `reportName` - returns standard name of the report
 - Legacy Method `addPlot` - adds a plot to the plots map by the name of the plot in case `plot.h` is used
 
-All methods for a report must be on the low level for a specific fidelity in a seperate `...Report.cpp` File. Report is an object of the main specific fidelity class and NOT an inherited class. Within your html report, can add generated plots by using the `image` function of `html.h`
+All methods for a report must be on the low level for a specific fidelity in a separate `...Report.cpp` File. Report is an object of the main specific fidelity class and NOT an inherited class. Within your html report, can add generated plots by using the `image` function of `html.h`
 
 ### Plot
 !!!attention
@@ -523,11 +464,13 @@ The Plot class (`plot.h`) is a basic frame for SVG Plot generation. There are mu
 - `generatePlotScript` - Generates plot script which is in the script stringstream
 - `generateSvg` - generates .svg based on the plotname in the given directory based on reference of a vector of unique pointers which stores svgObjects.
 
-All methods for a report must be on the low level for a specific fidelity in a seperate `...Plot.cpp` File. Plot is an object inside a method from the main specific fidelity class class and NOT an inherited class.
+All methods for a report must be on the low level for a specific fidelity in a separate `...Plot.cpp` File. Plot is an object inside a method from the main specific fidelity class class and NOT an inherited class.
 
 !!! note
     In case `plot.h` is used: Plots which are not added to the report (not part of the map `plots`) will not appear on the generated report!
 
+### Have a closer look ...
+How different strategies are handled, have a look at other modules. If you have questions, ask the unicado team!
 
-
-
+!!! tip
+    Have a look at modules like `wing_design`, `systems_design` or `mission_analysis` as a first start.
diff --git a/mkdocs.yml b/mkdocs.yml
index 8b5856da81ae7e697feb6fe741771b8f2bc72d10..81329e1250f1bde01ef4ce8067a2abc3693dbe48 100644
--- a/mkdocs.yml
+++ b/mkdocs.yml
@@ -209,6 +209,20 @@ plugins:
             OUTPUT_DIR: "docs/api/aircraft_geometry2"
           src-dirs: ../aircraft-design/libs/aircraftGeometry2/src/
           full-doc: true
+        airfoils:
+          doxyfile: Doxyfile
+          variables:
+            PROJECT_NAME: "airfoils"
+            OUTPUT_DIR: "docs/api/airfoils"
+          src-dirs: ../aircraft-design/libs/airfoils/src/
+          full-doc: true
+        aixml:
+          doxyfile: Doxyfile
+          variables:
+            PROJECT_NAME: "aixml"
+            OUTPUT_DIR: "docs/api/aixml"
+          src-dirs: ../aircraft-design/libs/aixml/src/
+          full-doc: true
         engine:
           doxyfile: Doxyfile
           variables:
@@ -411,6 +425,24 @@ nav:                                      # Customizes the main navigation struc
             - aircraftGeometry2/namespaces.md
             - aircraftGeometry2/files.md
             - aircraftGeometry2/functions.md
+        - airfoils:
+          - Introduction: documentation/libraries/airfoils/index.md
+          - API Reference:
+            - airfoils/classes.md
+            - airfoils/namespaces.md
+            - airfoils/files.md
+            - airfoils/functions.md
+        - aixml:
+          - Introduction: documentation/libraries/aixml/index.md
+          - Endnode:
+            - Introduction: documentation/libraries/aixml/endnode/index.md
+            - Valid Units: documentation/libraries/aixml/endnode/valid_units.md
+            - Getting Started: documentation/libraries/aixml/endnode/getting-started.md
+          - API Reference:
+            - aixml/classes.md
+            - aixml/namespaces.md
+            - aixml/files.md
+            - aixml/functions.md
         - engine:
           - Overview:
             - documentation/libraries/engine/index.md