diff --git a/_pages/contact.md b/_pages/contact.md
index aea7ae0..69c569a 100755
--- a/_pages/contact.md
+++ b/_pages/contact.md
@@ -10,7 +10,7 @@ order: 25
Please let us know - we're listening to you:
-* Email (our adress is spam-protected)
+* Email (our address is spam-protected)
* on our [github issue tracker](https://github.com/arc42/arc42-template/issues) at https://github.com/arc42/arc42-template/issues.
* on various Twitter accounts:
* [@arc42Tipps](https://twitter.com/arc42Tipps)
diff --git a/_pages/home.md b/_pages/home.md
index 591d7bc..5381f55 100755
--- a/_pages/home.md
+++ b/_pages/home.md
@@ -47,7 +47,7 @@ Check out **[ practical tips](/keywords)** for using arc42, organized by templa
>
>* **[lean](/keywords/#lean)**: You are looking for opportunities to shorten or streamline your documentation pragmatically. You want to reduce efforts without loosing content or value. You are working in an agile environment and want to have lightweight documentation – based on the motto: _travel light_.
>* **[thorough](/keywords/#thorough)**: You are working in a more formal environment, e.g. developing very large or critical systems with hard quality requirements. Your stakeholders require thoroughness, accuracy and attention to detail. Maybe your systems and their documentation have to be audited.
->* **[essential](/keywords/#essential)**: Despite lean and agile, there are some informations about your system that you should always document; i.e. quality goals of your architecture.
+>* **[essential](/keywords/#essential)**: Despite lean and agile, there is some information about your system that you should always document; i.e. quality goals of your architecture.
## Still have questions?
diff --git a/_pages/section-1.md b/_pages/section-1.md
index 9016d3f..834abf1 100755
--- a/_pages/section-1.md
+++ b/_pages/section-1.md
@@ -36,7 +36,7 @@ Keep these excerpts as short as possible.
Balance readability of this document with potential redundancy w.r.t to requirements documents.
-
+
{% include example.md category="overview" %}
@@ -64,7 +64,7 @@ A table with the most important quality goals and concrete scenarios, ordered by
See [section 10 (Quality Requirements)](/section-10/) for a complete overview of quality scenarios.
-
+
{% include example.md category="quality" %}
diff --git a/_pages/section-10.md b/_pages/section-10.md
index 9bc173b..d6f63d0 100755
--- a/_pages/section-10.md
+++ b/_pages/section-10.md
@@ -21,7 +21,7 @@ Since quality requirements will have a lot of influence on architectural
decisions you should know for every stakeholder what is really important to them,
concrete and measurable.
-
+
{% include example.md category="quality" %}
diff --git a/_pages/section-11.md b/_pages/section-11.md
index 1899ef5..baf09a4 100755
--- a/_pages/section-11.md
+++ b/_pages/section-11.md
@@ -20,7 +20,7 @@ This should be your motto for systematic detection and evaluation of risks and t
### Form
List of risks and/or technical debts, probably including suggested measures to minimize, mitigate or avoid risks or reduce technical debts.
-
+
{% include example.md category="risks" %}
diff --git a/_pages/section-12.md b/_pages/section-12.md
index 77d0b79..7e2d007 100755
--- a/_pages/section-12.md
+++ b/_pages/section-12.md
@@ -29,7 +29,7 @@ You should clearly define your terms, so that all stakeholders
| <Term-1> | <definition-1> |
| <Term-2> | <definition-2> |
-
+
{% include example.md category="glossary" %}
diff --git a/_pages/section-2.md b/_pages/section-2.md
index 3cbf1c8..4d66793 100755
--- a/_pages/section-2.md
+++ b/_pages/section-2.md
@@ -22,7 +22,7 @@ Constraints must always be dealt with; they may be negotiable, though.
### Form
Simple tables of constraints with explanations. If needed you can subdivide them into technical constraints, organizational and political constraints and conventions (e.g. programming or versioning guidelines, documentation or naming conventions)
-
+
{% include example.md category="constraints" %}
diff --git a/_pages/section-3.md b/_pages/section-3.md
index b749ad4..785670f 100755
--- a/_pages/section-3.md
+++ b/_pages/section-3.md
@@ -44,7 +44,7 @@ All kinds of diagrams that show the system as a black box and specify the domain
Alternatively (or additionally) you can use a table. The title of the table is the name of your system, the three columns contain the name of the communication partner, the inputs, and the outputs.
-
+
{% include example.md category="business-context" %}
@@ -68,7 +68,7 @@ Many stakeholders make architectural decision based on the technical interfaces
#### Form
E.g. UML deployment diagram describing channels to neighboring systems, together with a mapping table showing the relationships between channels and input/output.
-
+
{% include example.md category="technical-context" %}
diff --git a/_pages/section-4.md b/_pages/section-4.md
index a44faa8..d901dbf 100755
--- a/_pages/section-4.md
+++ b/_pages/section-4.md
@@ -35,7 +35,7 @@ You might use a list of solution-approaches or a table similar to the following:
| _<Q-goal 1>_ | _<Text>_ | _<Text>_ |_<Link>_ |
| _<Q-goal 2>_ | _<Text>_ | _<Text>_ |_<Link>_ |
-
+
{% include example.md category="solutionstrategy" %}
diff --git a/_pages/section-5.md b/_pages/section-5.md
index a824a03..cf4b431 100755
--- a/_pages/section-5.md
+++ b/_pages/section-5.md
@@ -32,7 +32,7 @@ The building block view is a hierarchial collection of black boxes and white box
Thus it contains the white box description of selected building blocks of level 1, together with black box descriptions of their internal building blocks.
* **Level 3** (not shown in the diagram above) zooms into details of selected building blocks of level 2, and so on.
-
+
{% include example.md category="building-block" %}
@@ -79,7 +79,7 @@ boxes with name and responsibility according to the following schema:
| _<black box 1>_ | _<Text>_ |
| _<black box 2>_ | _<Text>_ |
-If you use a list of black box decriptions then you fill in a separate black box template for every important building block .
+If you use a list of black box descriptions then you fill in a separate black box template for every important building block .
Its headline is the name of the black box.
@@ -139,7 +139,7 @@ _<black box template>_
Here you can specify the inner structure of (some) building blocks from level 1 as white boxes.
-You have to decide which building blocks of your system are important enough to justify such a detailed description. Please prefer relevance over completeness. Specify important, surprising, risky, compelx or volatile building blocks. Leave out normal, simple, boring or standardized parts of your system
+You have to decide which building blocks of your system are important enough to justify such a detailed description. Please prefer relevance over completeness. Specify important, surprising, risky, complex or volatile building blocks. Leave out normal, simple, boring or standardized parts of your system
diff --git a/_pages/section-6.md b/_pages/section-6.md
index 9b79296..bd73d5a 100755
--- a/_pages/section-6.md
+++ b/_pages/section-6.md
@@ -34,7 +34,7 @@ There are many notations for describing scenarios, e.g.
* state machines
* ...
-
+
{% include example.md category="runtime" %}
diff --git a/_pages/section-7.md b/_pages/section-7.md
index efb774c..9bb988d 100755
--- a/_pages/section-7.md
+++ b/_pages/section-7.md
@@ -43,7 +43,7 @@ nested diagrams, when your infrastructure is more complex.
* When your (hardware) stakeholders prefer other kinds of diagrams rather than UML
deployment diagram, let them use any kind that is able to show nodes and channels of the infrastructure.
-
+
{% include example.md category="deployment" %}
diff --git a/_pages/section-8.md b/_pages/section-8.md
index 28284e1..9c130e3 100755
--- a/_pages/section-8.md
+++ b/_pages/section-8.md
@@ -15,7 +15,7 @@ This section describes overall, principal regulations and solution ideas that ar
Such concepts are often related to multiple building blocks. They include many different topics, such as
* domain models
-* architectur patterns or design patterns
+* architectural patterns or design patterns
* rules for using specific technology
* principale, often technical decisions of overall decisions
* implementation rules
@@ -60,7 +60,7 @@ In the diagram below, logging concerns all three components, whereas security is
Some real-life examples:
-* Within a system, a common format for log-messages shall be established, combined with a common convention of chosing the appropriate log-destination.
+* Within a system, a common format for log-messages shall be established, combined with a common convention of choosing the appropriate log-destination.
These decisions, along with implementation examples, could be described as "logging-concept".
* A system has numerous backend services, that communicate among each other based upon remote procedure calls or http-based REST.
Calling services ("consumers") always need to authenticate themselves to the called service ("provider").
@@ -71,7 +71,7 @@ All (7+) checker components within the system are structured according to the st
-
+
{% include example.md category="concepts" %}
diff --git a/_pages/section-9.md b/_pages/section-9.md
index 2a70789..ecab3d3 100755
--- a/_pages/section-9.md
+++ b/_pages/section-9.md
@@ -49,7 +49,7 @@ You might follow the Nygard-structure, which works as follows:
You can find additional structures of ADR in the [ADR Github collection](https://adr.github.io/)
-
+
{% include example.md category="decisions" %}
diff --git a/_posts/05-buildingblocks/2016-03-02-t-5-16.md b/_posts/05-buildingblocks/2016-03-02-t-5-16.md
index c767571..9e695a0 100644
--- a/_posts/05-buildingblocks/2016-03-02-t-5-16.md
+++ b/_posts/05-buildingblocks/2016-03-02-t-5-16.md
@@ -23,6 +23,6 @@ cohesive building blocks (i.e. you implement parts of the building block
* If some of your frameworks/libraries or even used-products enforce
_other_ structuring of code... then you should comply to the suggestions
of your tools ("don't fight the platform"), but nevertheless create
-meaningful architectur building blocks.
+meaningful architectural building blocks.
* If the stuff located in the package/namespace/module is not cohesive
(see [tip 5-17 (cohesion is king)](/tips/5-17))