diff --git a/README.md b/README.md
index cd4bb3b063..e40ad9d8e9 100644
--- a/README.md
+++ b/README.md
@@ -1,7 +1,7 @@
 # "CIRCT" / Circuit IR Compilers and Tools
 
 This is an experimental repository, applying the MLIR/LLVM approach to building
-modular tools for hardware design.
+modular tools for hardware design.  A longer [charter document is here](docs/Charter.md).
 
 "CIRCT" stands for "Circuit IR Compilers and Tools".  One might also interpret
 it as the recursively as "CIRCT IR Compiler and Tools".  The T can be further
@@ -84,8 +84,9 @@ The project is small so there are few formal process yet.  We generally follow
 the LLVM and MLIR community practices, but we currently use pull requests and
 GitHub issues.  Here are some high-level guidelines:
 
- * Please use clang-format in the LLVM style.  There are good plugins for common
-   editors like VSCode, Atom, etc, or you can run it manually.  This makes code
+ * Please use clang-format in the LLVM style.  There are good plugins
+   for common editors like VSCode, Atom, etc, or you can run it
+   manually.  This makes code easier to read and understand.
  
  * Beyond mechanical formatting issues, please follow the [LLVM Coding 
    Standards](https://llvm.org/docs/CodingStandards.html).
diff --git a/docs/Motivation.md b/docs/Charter.md
similarity index 95%
rename from docs/Motivation.md
rename to docs/Charter.md
index 5dd63c81b3..71c497348e 100644
--- a/docs/Motivation.md
+++ b/docs/Charter.md
@@ -1,3 +1,18 @@
+Abstract
+========
+
+Recent trends in computer architecture have resulted in two core problems.
+Firstly, how do we design complex, heterogenous systems-on-chip mixing
+general purpose and specialized components?  Secondly, how do we
+program them?  We believe that design tools that represent and
+manipulate a wide variety of abstractions are central to solving these
+problems.  This projects is focused on using LLVM/MLIR to express
+these abstractions and to build useable open-source flows based on
+those abstractions to solve the design problems of the next decade.
+
+Introduction
+============
+
 With the slowing rate of scaling in semiconductor process technology,
 there has become a widespread shift to develop more specialized
 architectures. Circuits implementing these specialized architectures are
@@ -41,7 +56,7 @@ to the process of *programming* them. Furthermore, unifying the
 abstractions for accelerator design and accelerator programming is a key
 step towards enabling programming for arbitrary accelerators.
 
-Dialects for Hardware Design {#sec:dialects}
+Dialects for Hardware Design
 ============================
 
 In existing systems, we see the use of a wide variety of abstractions
@@ -75,7 +90,7 @@ lowering between dialects. Many existing systems span multiple
 abstractions, but we've tried here to focus on the most significant
 internal representations used in each tool.
 
-Structural Circuit Netlists {#sec:netlists}
+Structural Circuit Netlists
 ---------------------------
 
 Netlists are a longstanding abstraction used for circuit design,
@@ -94,7 +109,7 @@ different times!) drive a signal onto the same wire. Alternatively, a
 single component may sometimes use a wire as an input and at other times
 use the same wire for output.
 
-Register-transfer level (RTL) {#sec:rtl}
+Register-transfer level (RTL)
 -----------------------------
 
 The Register-transfer level is has been commonly used to describe logic
@@ -120,7 +135,7 @@ combinational aspects. Modern circuit analysis techniques often consider
 the behavior across synchronous boundaries. Retiming is a common
 transformation performed on RTL descriptions.
 
-Finite-State Machine + Datapath (FSMD) {#sec:fsmd}
+Finite-State Machine + Datapath (FSMD)
 --------------------------------------
 
 High-Level synthesis(HLS) of RTL designs from C code has become a common
@@ -150,7 +165,7 @@ internal representation. A recent effort in this area is Futil,
 which implements an intermediate representation leveraged by the Dahlia
 system.
 
-[Dataflow/handshake](Dialects/Handshake.md) {#sec:handshake}
+[Dataflow/handshake](Dialects/Handshake.md)
 ------------------
 
 Dataflow models have long been used to represent parallel computation.
@@ -182,7 +197,7 @@ hardware design to be inserted where RTL does not yet exist.  By
 mapping the dataflow model back to hardware in a non-cycle accurate
 way, very fast emulation can be built quickly.
 
-IP composition {#sec:ipi}
+IP composition
 --------------
 
 IP composition has become a key methodology for most FPGA and ASIC
@@ -209,7 +224,7 @@ verbose and difficult for humans to interact with. DUH is a recent
 open-source effort based on JSON formats also focusing on IP
 composition.
 
-Tool Flows {#sec:flows}
+Tool Flows
 ==========
 
 Although it is important to have appropriate abstractions to build with,
@@ -217,7 +232,7 @@ those abstractions are simply a means to support transformations of
 designs. Although many flows are potentially interested, we highlight
 some of the most interesting flows.
 
-High-Level Synthesis (HLS) {#sec:HLS}
+High-Level Synthesis (HLS)
 --------------------------
 
 A common toolflow is to synthesize circuits from sequential algorithmic
@@ -260,7 +275,7 @@ VHDL, enabling implementation using vendor tools. Alternatively, these
 models could be further lowered to more hardware-specific dialects in
 MLIR.
 
-Dataflow-based Multicore Programming {#sec:dataflowmulticore}
+Dataflow-based Multicore Programming
 ------------------------------------
 
 Multicore programming is commonly done using Single-Program