diff --git a/CMakeLists.txt b/CMakeLists.txt
index e89c6e2..13d3123 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -4,7 +4,7 @@ project(predictable_parallel_patterns
         DESCRIPTION "predictable parallel patterns for scalable smart systems using work stealing"
         LANGUAGES CXX ASM)
 
-set(CMAKE_CXX_STANDARD 11)
+set(CMAKE_CXX_STANDARD 17)
 
 # seperate library and test/example executable output paths.
 set(EXECUTABLE_OUTPUT_PATH ${CMAKE_BINARY_DIR}/bin)
diff --git a/NOTES.md b/NOTES.md
index 859b922..f7793f2 100644
--- a/NOTES.md
+++ b/NOTES.md
@@ -4,6 +4,37 @@ The new version of pls uses a more complicated/less user friendly
 API in favor of performance and memory guarantees.
 For the old version refer to the second half of this document.
 
+# 18.03.2020 - Coding Standard/C++ Standard
+
+We previously stuck to strict 'static' allocation in global static
+storage or on the stack for most memory we need. However, we found
+this to be very restrictive and making our code overly complicated
+and not at all 'modern C++'.
+
+After some research we found that this restrictive style is common
+in very restrictive embedded domains. However, we target multi and many
+core systems that run many applications on a shared operating system in
+a more traditional 'PC-like' manner. The model best fitting this application
+style is the adaptive autosar standard. It models the system as a posix
+compliant os running specialized software for application deployment and management.
+Under this stack there is usually a normal OS scheduler, like e.g. a
+linux image tuned for low latencies. The target platform for such systems
+are intel and arm processors with 2 to 16 cores, making it ideal for
+our framework.
+
+Following this logic, we decide to orient ourselfs at the 
+[C++ 14 guidlines of autosar](https://www.autosar.org/fileadmin/user_upload/standards/adaptive/17-03/AUTOSAR_RS_CPP14Guidelines.pdf).
+Specificially, they encourage the use of dynamic memory allocation and
+modern C++, as long as some restrictions are hold. 
+The memory usage of an app must be bounded and best practice is to
+allocate resources 'outside of real-time sections, e.g. startup',
+making it, again, a good fit for our concept. We do not plan
+to follow all these rules, but we see them as an example for where
+our research can be applied later on. As the autosar standard is
+[moving towards C++ 17 and integrated into misra C++](https://www.autosar.org/news-events/details/misra-consortium-announce-integration-of-autosar-c-coding-guidelines-into-updated-industry-standar/)
+we decide to go for C++ 17 in our project. These facts make develpoment
+a lot more convenient and are enough to test our profe of concept prototype.
+
 # 13.03.2020 - Coroutines and 'Nice API'
 
 Before Christmas we finished the 'ugly' inline/object based API.