diff --git a/.gitignore b/.gitignore
index 9b5c2c1e..ecd1fe9c 100644
--- a/.gitignore
+++ b/.gitignore
@@ -132,3 +132,6 @@ dmypy.json
 
 # generated by setuptools_scm
 /vultron/_version.py
+/node_modules/
+/package.json
+/package-lock.json
diff --git a/docs/adr/0000-record-architecture-decisions.md b/docs/adr/0000-record-architecture-decisions.md
index 59238626..d88b5946 100644
--- a/docs/adr/0000-record-architecture-decisions.md
+++ b/docs/adr/0000-record-architecture-decisions.md
@@ -1,8 +1,10 @@
+---
+status: accepted
+date: 2023-10-18
+deciders: adh
+---
 # Record architecture decisions
 
-* Status: accepted
-* Date: 2023-10-18
-
 ## Context
 
 We need to record the architectural decisions made on Opinionated Digital Center.
diff --git a/docs/adr/0001-use-markdown-any-decision-records.md b/docs/adr/0001-use-markdown-any-decision-records.md
new file mode 100644
index 00000000..a3294782
--- /dev/null
+++ b/docs/adr/0001-use-markdown-any-decision-records.md
@@ -0,0 +1,31 @@
+---
+status: accepted
+date: 2023-10-18
+deciders: adh
+---
+# Use Markdown Any Decision Records
+
+## Context and Problem Statement
+
+We want to record any decisions made in this project independent whether decisions concern the architecture ("architectural decision record"), the code, or other fields.
+Which format and structure should these records follow?
+
+## Considered Options
+
+* [MADR](https://adr.github.io/madr/) 3.0.0 – The Markdown Any Decision Records
+* [Michael Nygard's template](http://thinkrelevance.com/blog/2011/11/15/documenting-architecture-decisions) – The first incarnation of the term "ADR"
+* [Sustainable Architectural Decisions](https://www.infoq.com/articles/sustainable-architectural-design-decisions) – The Y-Statements
+* Other templates listed at <https://github.com/joelparkerhenderson/architecture_decision_record>
+* Formless – No conventions for file format and structure
+
+## Decision Outcome
+
+Chosen option: "MADR 3.0.0", because
+
+* Implicit assumptions should be made explicit.
+  Design documentation is important to enable people understanding the decisions later on.
+  See also [A rational design process: How and why to fake it](https://doi.org/10.1109/TSE.1986.6312940).
+* MADR allows for structured capturing of any decision.
+* The MADR format is lean and fits our development style.
+* The MADR structure is comprehensible and facilitates usage & maintenance.
+* The MADR project is vivid.
diff --git a/docs/adr/0001-use-markdown-architectural-decision-records.md b/docs/adr/0001-use-markdown-architectural-decision-records.md
deleted file mode 100644
index f3c8cb07..00000000
--- a/docs/adr/0001-use-markdown-architectural-decision-records.md
+++ /dev/null
@@ -1,44 +0,0 @@
-# Use Markdown Architectural Decision Records
-
-Adapted from
-[MADR's similar decision record](https://github.com/adr/madr/blob/2.1.2/docs/adr/0000-use-markdown-architectural-decision-records.md).
-
-* Status: accepted
-* Date: 2023-10-18
-
-## Context and Problem Statement
-
-We want to record architectural decisions made in this project.
-Which format and structure should these records follow?
-
-## Considered Options
-
-* [MADR](https://adr.github.io/madr/) 2.1.2 - The Markdown Architectural Decision Records
-* [Michael Nygard's template](http://thinkrelevance.com/blog/2011/11/15/documenting-architecture-decisions) - The first incarnation of the term "ADR"
-* [Sustainable Architectural Decisions](https://www.infoq.com/articles/sustainable-architectural-design-decisions) - The Y-Statements
-* Other templates listed at <https://github.com/joelparkerhenderson/architecture_decision_record>
-* Formless - No conventions for file format and structure
-
-## Decision Outcome
-
-Chosen option: "MADR 2.1.2", because
-
-* Implicit assumptions should be made explicit.
-  Design documentation is important to enable people understanding the decisions later on.
-  See also [A rational design process: How and why to fake it](https://doi.org/10.1109/TSE.1986.6312940).
-* The MADR format is lean and fits our development style.
-* The MADR structure is comprehensible and facilitates usage & maintenance.
-* The MADR project is vivid.
-* Version 2.1.2 is the latest one available when starting to document ADRs.
-
-### Positive Consequences
-
-The ADR are more structured. See especially:
-* [MADR-0002 - Do not use numbers in headings](https://github.com/adr/madr/blob/2.1.2/docs/adr/0002-do-not-use-numbers-in-headings.md).
-* [MADR-0005 - Use (unique number and) dashes in filenames](https://github.com/adr/madr/blob/2.1.2/docs/adr/0005-use-dashes-in-filenames.md).
-* [MADR-0010 - Support categories (in form of subfolders with local ids)](https://github.com/adr/madr/blob/2.1.2/docs/adr/0010-support-categories.md).
-* See [full set of MADR ADRs](https://github.com/adr/madr/blob/2.1.2/docs/adr).
-
-### Negative Consequences
-
-* Learning curve will be slightly longer.
diff --git a/docs/adr/README.md b/docs/adr/README.md
new file mode 100644
index 00000000..04664068
--- /dev/null
+++ b/docs/adr/README.md
@@ -0,0 +1,7 @@
+# Decisions
+
+This directory contains decision records for {project name}.
+
+For new ADRs, please use [adr-template.md](adr-template.md) as basis.
+More information on MADR is available at <https://adr.github.io/madr/>.
+General information about architectural decision records is available at <https://adr.github.io/>.
diff --git a/docs/adr/adr-template.md b/docs/adr/adr-template.md
new file mode 100644
index 00000000..054289ad
--- /dev/null
+++ b/docs/adr/adr-template.md
@@ -0,0 +1,79 @@
+---
+# These are optional elements. Feel free to remove any of them.
+status: {proposed | rejected | accepted | deprecated | … | superseded by [ADR-0005](0005-example.md)}
+date: {YYYY-MM-DD when the decision was last updated}
+deciders: {list everyone involved in the decision}
+consulted: {list everyone whose opinions are sought (typically subject-matter experts); and with whom there is a two-way communication}
+informed: {list everyone who is kept up-to-date on progress; and with whom there is a one-way communication}
+---
+# {short title of solved problem and solution}
+
+## Context and Problem Statement
+
+{Describe the context and problem statement, e.g., in free form using two to three sentences or in the form of an illustrative story.
+ You may want to articulate the problem in form of a question and add links to collaboration boards or issue management systems.}
+
+<!-- This is an optional element. Feel free to remove. -->
+## Decision Drivers
+
+* {decision driver 1, e.g., a force, facing concern, …}
+* {decision driver 2, e.g., a force, facing concern, …}
+* … <!-- numbers of drivers can vary -->
+
+## Considered Options
+
+* {title of option 1}
+* {title of option 2}
+* {title of option 3}
+* … <!-- numbers of options can vary -->
+
+## Decision Outcome
+
+Chosen option: "{title of option 1}", because
+{justification. e.g., only option, which meets k.o. criterion decision driver | which resolves force {force} | … | comes out best (see below)}.
+
+<!-- This is an optional element. Feel free to remove. -->
+### Consequences
+
+* Good, because {positive consequence, e.g., improvement of one or more desired qualities, …}
+* Bad, because {negative consequence, e.g., compromising one or more desired qualities, …}
+* … <!-- numbers of consequences can vary -->
+
+<!-- This is an optional element. Feel free to remove. -->
+## Validation
+
+{describe how the implementation of/compliance with the ADR is validated. E.g., by a review or an ArchUnit test}
+
+<!-- This is an optional element. Feel free to remove. -->
+## Pros and Cons of the Options
+
+### {title of option 1}
+
+<!-- This is an optional element. Feel free to remove. -->
+{example | description | pointer to more information | …}
+
+* Good, because {argument a}
+* Good, because {argument b}
+<!-- use "neutral" if the given argument weights neither for good nor bad -->
+* Neutral, because {argument c}
+* Bad, because {argument d}
+* … <!-- numbers of pros and cons can vary -->
+
+### {title of other option}
+
+{example | description | pointer to more information | …}
+
+* Good, because {argument a}
+* Good, because {argument b}
+* Neutral, because {argument c}
+* Bad, because {argument d}
+* …
+
+<!-- This is an optional element. Feel free to remove. -->
+## More Information
+
+{You might want to provide additional evidence/confidence for the decision outcome here and/or
+ document the team agreement on the decision and/or
+ define when this decision when and how the decision should be realized and if/when it should be re-visited and/or
+ how the decision is validated.
+ Links to other decisions and resources might here appear as well.}
diff --git a/docs/adr/template.md b/docs/adr/template.md
deleted file mode 100644
index fed92306..00000000
--- a/docs/adr/template.md
+++ /dev/null
@@ -1,72 +0,0 @@
-# [short title of solved problem and solution]
-
-* Status: [proposed | rejected | accepted | deprecated | ... | superseded by [ADR-0005](0005-example.md)] <!-- optional -->
-* Deciders: [list everyone involved in the decision] <!-- optional -->
-* Date: [YYYY-MM-DD when the decision was last updated] <!-- optional -->
-
-Technical Story: [description | ticket/issue URL] <!-- optional -->
-
-## Context and Problem Statement
-
-[Describe the context and problem statement, e.g., in free form using two to three sentences. You may want to articulate the problem in form of a question.]
-
-## Decision Drivers <!-- optional -->
-
-* [driver 1, e.g., a force, facing concern, ...]
-* [driver 2, e.g., a force, facing concern, ...]
-* ... <!-- numbers of drivers can vary -->
-
-## Considered Options
-
-* [option 1]
-* [option 2]
-* [option 3]
-* ... <!-- numbers of options can vary -->
-
-## Decision Outcome
-
-Chosen option: "[option 1]", because [justification. e.g., only option, which meets k.o. criterion decision driver | which resolves force force | ... | comes out best (see below)].
-
-### Positive Consequences <!-- optional -->
-
-* [e.g., improvement of quality attribute satisfaction, follow-up decisions required, ...]
-* ...
-
-### Negative Consequences <!-- optional -->
-
-* [e.g., compromising quality attribute, follow-up decisions required, ...]
-* ...
-
-## Pros and Cons of the Options <!-- optional -->
-
-### [option 1]
-
-[example | description | pointer to more information | ...] <!-- optional -->
-
-* Good, because [argument a]
-* Good, because [argument b]
-* Bad, because [argument c]
-* ... <!-- numbers of pros and cons can vary -->
-
-### [option 2]
-
-[example | description | pointer to more information | ...] <!-- optional -->
-
-* Good, because [argument a]
-* Good, because [argument b]
-* Bad, because [argument c]
-* ... <!-- numbers of pros and cons can vary -->
-
-### [option 3]
-
-[example | description | pointer to more information | ...] <!-- optional -->
-
-* Good, because [argument a]
-* Good, because [argument b]
-* Bad, because [argument c]
-* ... <!-- numbers of pros and cons can vary -->
-
-## Links <!-- optional -->
-
-* [Link type] [Link to ADR] <!-- example: Refined by [ADR-0005](0005-example.md) -->
-* ... <!-- numbers of links can vary -->