diff --git a/adr-c4k/project-section.md b/adr-c4k/project-section.md
new file mode 100644
index 0000000..1b667e6
--- /dev/null
+++ b/adr-c4k/project-section.md
@@ -0,0 +1,25 @@
+# How is the c4k-project section?
+
+
+This is the template in [Documenting architecture decisions - Michael Nygard](http://thinkrelevance.com/blog/2011/11/15/documenting-architecture-decisions).
+You can use [adr-tools](https://github.com/npryce/adr-tools) for managing the ADR files.
+
+In each ADR file, write these sections:
+
+# Title
+
+## Status
+
+What is the status, such as proposed, accepted, rejected, deprecated, superseded, etc.?
+
+## Context
+
+What is the issue that we're seeing that is motivating this decision or change?
+
+## Decision
+
+What is the change that we're proposing and/or doing?
+
+## Consequences
+
+What becomes easier or more difficult to do because of this change?
diff --git a/adr-provs/project-section.md b/adr-provs/project-section.md
new file mode 100644
index 0000000..a798ff7
--- /dev/null
+++ b/adr-provs/project-section.md
@@ -0,0 +1,25 @@
+# How is the provs-project section?
+
+
+This is the template in [Documenting architecture decisions - Michael Nygard](http://thinkrelevance.com/blog/2011/11/15/documenting-architecture-decisions).
+You can use [adr-tools](https://github.com/npryce/adr-tools) for managing the ADR files.
+
+In each ADR file, write these sections:
+
+# Title
+
+## Status
+
+What is the status, such as proposed, accepted, rejected, deprecated, superseded, etc.?
+
+## Context
+
+What is the issue that we're seeing that is motivating this decision or change?
+
+## Decision
+
+What is the change that we're proposing and/or doing?
+
+## Consequences
+
+What becomes easier or more difficult to do because of this change?
diff --git a/principles/README.md b/principles/README.md
new file mode 100644
index 0000000..82fe393
--- /dev/null
+++ b/principles/README.md
@@ -0,0 +1,27 @@
+1. Schnitt: Erst fachlich, dann technisch
+2. Tests: 
+  1. Jedes Element nur einmal testen
+  2. möglichst billig testen
+3. YAGNI / KISS
+
+#Postel's Law:
+
+be conservative in what you do, be liberal in what you accept from others.
+
+https://martinfowler.com/bliki/TolerantReader.html
+
+5. DDD Aufteilung nutzen
+  1. Domain isoliert - isoliert testbar
+  2. Inputs / Outputs validieren
+  3. Aggregate bilden
+6. Configuration ist dumm
+7. Wir programmieren in Programmiersprachen und nicht in XML / Template / yaml ...
+8. Gute Programmiersprachen erfinden ist schwierig, drum lassen wir das
+9. Microkernel
+10. Schnelles Feedback ist relevant
+11. Wenn wir Magie wirken, dann muss die gut sein
+12. Wir vermeiden zirkuläre Abhängigkeiten
+13. Modularisierung ermöglichen
+14. Komposition
+15. versionierte / nicht veränderbare Dependency
+16. Das nötigste ist dokumentiert
\ No newline at end of file