diff --git a/README.md b/README.md
index 3e9596d..d2dee99 100644
--- a/README.md
+++ b/README.md
@@ -47,7 +47,7 @@ To start using ADRs, talk with your teammates about these areas.
 
 2. Decision making
 
-    * A number of decision making technqiues exists, both general ones and software and software architecture specific ones, for instance, dialogue mapping. 
+    * A number of decision making techniques exists, both general ones and software and software architecture specific ones, for instance, dialogue mapping.
     * Group decision making is an active research topic.
 
 3. Decision documentation
@@ -58,7 +58,7 @@ To start using ADRs, talk with your teammates about these areas.
 
 4. Decision enactment and enforcement
 
-    * ADs are used in software design; hence they have to be communicated to, and accepted by, the stakeholders of the system that fund, deveop, and operate it. 
+    * ADs are used in software design; hence they have to be communicated to, and accepted by, the stakeholders of the system that fund, develop, and operate it.
     * Architecturally evident coding styles and code reviews that focus on architectural concerns and decisions are two related practices. 
     * ADs also have to be (re-)considered when modernizing a software sytem in software evolution.
 
diff --git a/adr_microservices_template_by_uber.md b/adr_microservices_template_by_uber.md
index 20ab26b..31a800e 100644
--- a/adr_microservices_template_by_uber.md
+++ b/adr_microservices_template_by_uber.md
@@ -7,7 +7,7 @@ See Production-Ready Microservices: Building Standardized Systems Across an Engi
 Each service defines these system quality attributes:
 
 * Stable
-* Reiable
+* Reliable
 * Scalable
 * Fault tolerant
 * Performant
diff --git a/adr_template_by_jeff_tyree_and_art_akerman.md b/adr_template_by_jeff_tyree_and_art_akerman.md
index d96361f..e02465f 100644
--- a/adr_template_by_jeff_tyree_and_art_akerman.md
+++ b/adr_template_by_jeff_tyree_and_art_akerman.md
@@ -8,7 +8,7 @@ This is the Architecture decision description template published in ["Architectu
 
 * **Status**: The decision’s status, such as pending, decided, or approved.
 
-* **Group**: You can use a simple grouping—such as integration, presentation, data, and so on—to help organize the set of decisions. You could also use a more sophisticated architecture ontology, such as John Kyaruzi and Jan van Katwijk’s, which includes more abstract categories such as event, calendar, and location.8 For example, using this ontology, you’d group decisions that deal with occurrences where the system requires information under event.
+* **Group**: You can use a simple grouping—such as integration, presentation, data, and so on—to help organize the set of decisions. You could also use a more sophisticated architecture ontology, such as John Kyaruzi and Jan van Katwijk’s, which includes more abstract categories such as event, calendar, and location. For example, using this ontology, you’d group decisions that deal with occurrences where the system requires information under event.
 
 * **Assumptions**: Clearly describe the underlying assumptions in the environment in which you’re making the decision—cost, schedule, technology, and so on. Note that environmental constraints (such as accepted technology standards, enterprise architecture, commonly employed patterns, and so on) might limit the alternatives you consider.