diff --git a/docs/architecture/decision-records/README.md b/docs/architecture/README.md
similarity index 83%
rename from docs/architecture/decision-records/README.md
rename to docs/architecture/README.md
index 7c669566df6c..f010758a0b37 100644
--- a/docs/architecture/decision-records/README.md
+++ b/docs/architecture/README.md
@@ -1,8 +1,8 @@
 # Architecture Decision Records (ADR)
 
-This is a location to record all high-level architecture decisions in the cosmos-sdk project.
+This is a location to record all high-level architecture decisions in the Cosmos SDK project.
 
-You can read more about the ADR concept in this [blog post](https://product.reverb.com/documenting-architecture-decisions-the-reverb-way-a3563bb24bd0#.78xhdix6t).
+You can read more about the ADR concept in this [blog post](https://product.reverb.com/documenting-architecture-decisions-the-reverb-way-a3563bb24bd0#.78xhdix6t). See the [tendermint ADRs](https://github.com/tendermint/tendermint/tree/master/docs/architecture) for examples.
 
 An ADR should provide:
 
diff --git a/docs/architecture/decision-records/adr-001-message-counter.md b/docs/architecture/adr-001-message-counter.md
similarity index 100%
rename from docs/architecture/decision-records/adr-001-message-counter.md
rename to docs/architecture/adr-001-message-counter.md
diff --git a/docs/architecture/decision-records/adr-template.md b/docs/architecture/adr-template.md
similarity index 99%
rename from docs/architecture/decision-records/adr-template.md
rename to docs/architecture/adr-template.md
index 6153a9d1ee21..28a5ecfbbc73 100644
--- a/docs/architecture/decision-records/adr-template.md
+++ b/docs/architecture/adr-template.md
@@ -4,20 +4,23 @@
 * {date}: {changelog}
 
 ## Context
-> This section contains all the context one needs to understand the current state, and why there is a problem. It should be as succinct as possible and introduce the high level idea behind the solution. 
 
+> This section contains all the context one needs to understand the current state, and why there is a problem. It should be as succinct as possible and introduce the high level idea behind the solution. 
 ## Decision
+
 > This section explains all of the details of the proposed solution, including implementation details.
 It should also describe affects / corollary items that may need to be changed as a part of this.
 If the proposed change will be large, please also indicate a way to do the change to maximize ease of review.
 (e.g. the optimal split of things to do between separate PR's)
 
 ## Status
+
 > A decision may be "proposed" if it hasn't been agreed upon yet, or "accepted" once it is agreed upon. If a later ADR changes or reverses a decision, it may be marked as "deprecated" or "superseded" with a reference to its replacement.
 
 {Deprecated|Proposed|Accepted}
 
 ## Consequences
+
 > This section describes the consequences, after applying the decision. All consequences should be summarized here, not just the "positive" ones.
 
 ### Positive
@@ -27,6 +30,7 @@ If the proposed change will be large, please also indicate a way to do the chang
 ### Neutral
 
 ## References
+
 > Are there any relevant PR comments, issues that led up to this, or articles referrenced for why we made the given design choice? If so link them here!
 
 * {reference link}