diff --git a/doc/manual/01-introduction.md b/doc/manual/01-introduction.md
new file mode 100644
index 0000000..9ab4a2d
--- /dev/null
+++ b/doc/manual/01-introduction.md
@@ -0,0 +1,27 @@
+# Introduction
+
+`lighthouse` is a library that manages suites of EDN files and the connections between them. It provides:
+
+  1. simple inheritance rules
+  2. ways to provide metadata at the manifest and directory levels
+  3. access to fns via `sci`
+
+`lighthouse` takes these files, builds a tree out of them, merges down into a single map, and renders that map on disk.
+
+# Rationale
+
+During the development of our Kubernetes cluster, our team found issues with Helm/YAML manifests when trying to organize our deployments. Among other things:
+
+- Helm has some really annoying/bad idiosyncrasies (again, among others):
+  - You cannot provide an image tag that's completely digits. Helm will refuse to parse this as anything other than a number
+  - Helm will always pull down all required charts, even if the versions haven't changed.
+  - Helm's inheritance / value structure gets REALLY complicated / obtuse if you have nested charts.
+- Templates + YAML is a really, REALLY bad pairing.
+
+  When writing templates you need to worry about whitespace. In other languages (JSON, EDN, etc) this isn't a problem since whitespace is ignored. However, YAML applies syntactic significance to whitespaces. Because of this, when developing Helm templates, extra care has to be taken to ensure that the data is indented the proper amount in the final rendered YAML document. This leads to either `indents` being thrown around everywhere or specifically indented (and thus brittle) template functions.
+
+  All of this compounds and eventually the making sure the indentation levels in your template matches properly takes longer than actually implementing the template change in the first place.
+
+All-in-all, Helm and Go templates had just become a labor to deal with and manage, so we started looking for options. We decided we just wanted to deal with plain manifests. However, YAML (as mentioned above) isn't the best data language so we didn't want to use it if we didn't have to. Eventually, we settled on using EDN structures and a small library to convert EDN into YAML. That "small" library has transformed into this library.
+
+[Installation :>](02-installation.md)
diff --git a/doc/manual/02-installation.md b/doc/manual/02-installation.md
new file mode 100644
index 0000000..87ae0a5
--- /dev/null
+++ b/doc/manual/02-installation.md
@@ -0,0 +1,37 @@
+# Installation
+
+## Static binary
+
+Download the latest binary from [Releases](https://github.com/barracudanetworks/lighthouse/releases)
+
+```
+$ wget https://github.com/barracudanetworks/lighthouse/releases/latest/download/lighthouse-native-linux-amd64.zip
+$ unzip lighthouse-native-linux-amd64.zip
+$ ./lh
+** ERROR: **
+No sub-command specified.
+
+
+NAME:
+ lh - A tool for reading and combining EDN hierarchies
+
+USAGE:
+ lh [global-options] command [command options] [arguments...]
+
+VERSION:
+ v2.0.1
+
+COMMANDS:
+   build                Generates output manifests for all provided files.
+   update               Updates 1-to-many values in 1-to-many given files
+   visualize            Renders a graphvis visualization of the provided file
+
+GLOBAL OPTIONS:
+   -?, --help
+```
+
+## Homebrew
+
+Coming soon.
+
+[<: Introduction](01-introduction.md) | [Tutorial :>](03-tutorial.md)
diff --git a/doc/manual/03-tutorial.md b/doc/manual/03-tutorial.md
new file mode 100644
index 0000000..269d3c5
--- /dev/null
+++ b/doc/manual/03-tutorial.md
@@ -0,0 +1,486 @@
+# Tutorial
+
+## Getting Started
+
+Lighthouse is a tool for merging data together and exporting that data to disk.
+This can sound a bit abstract, but it's quite useful when you see a few
+examples.
+
+### Extensible Data Notation
+
+Lighthouse's data is in the Extensible Data Notation (EDN) format, which is
+a subset of the Clojure syntax. It is to Clojure what JSON is to JavaScript.
+
+One useful benefit over JSON is that comments are supported.
+
+For a quick primer into the format, check out [this guide](https://learnxinyminutes.com/docs/edn/).
+
+### First manifest
+
+The most common task to automate with Lighthouse is generating Kubernetes
+manifests, so we'll start with a simple pod.
+
+First, make a directory for your Lighthouse data and change into it:
+
+```
+mkdir tutorial
+cd tutorial
+```
+
+#### Files
+
+Only two files are needed to generate the Kubernetes yaml for a pod.
+
+The first is the Lighthouse config itself. This file anchors the base of the
+Lighthouse data and is used as a reference point when searching for parent
+libraries to use.
+
+##### File 1: Lighthouse config file for Kubernetes
+
+Create the file `lighthouse.edn`:
+
+```clojure
+{:output-format :yaml}
+```
+
+This sets the output format to be YAML (as opposed to JSON or EDN).
+
+##### File 2: Library file for the pod itself
+
+Create the file `nginx.edn`:
+
+```clojure
+{:api-version "v1"
+ :kind "Pod"
+ :metadata {:name "nginx"}
+ :spec {:containers
+        {"nginx"
+         {:image "nginx:1.14.2"
+          :ports {:http {:container-port 80}}}}}}
+```
+
+#### Run Lighthouse
+
+Run the Lighthouse build subcommand to generate the manifest:
+
+```
+lh build nginx.edn
+```
+
+The resulting manifest will be in the `manifests/nginx.yaml`:
+
+```yaml
+# ------------------------------------------------------------
+# AUTO-GENERATED FILE. ANY MANUAL CHANGES WILL BE OVERWRITTEN.
+# ------------------------------------------------------------
+---
+apiVersion: v1
+kind: Pod
+metadata:
+  name: nginx
+spec:
+  containers:
+    nginx:
+      image: nginx:1.14.2
+      ports:
+        http:
+          containerPort: 80
+```
+
+You will notice that the above is not quite valid Kubernetes YAML. The
+containers and ports are both maps. The reason for this is that Lighthouse
+operates on nested maps, for reasons that will become evident later. For
+now, we need to convert those maps into collections, and to do that we need to
+enable the "kube" processor, which knows how to do the right conversion. Enable
+this processor by adding `:processor :kube` to the `lighthouse.edn` config
+file. So now it should look like this:
+
+```clojure
+{:output-format :yaml
+ :processor :kube}
+```
+
+Now, if you re-run the `lh build nginx.edn` command from above, the
+resulting `manifests/nginx.yaml` is now:
+
+```yaml
+# ------------------------------------------------------------
+# AUTO-GENERATED FILE. ANY MANUAL CHANGES WILL BE OVERWRITTEN.
+# ------------------------------------------------------------
+---
+apiVersion: v1
+kind: Pod
+metadata:
+  name: nginx
+spec:
+  containers:
+  - image: nginx:1.14.2
+    name: nginx
+    ports:
+    - containerPort: 80
+      name: http
+```
+
+That's more like it. Now we can take that manifest and submit it to Kubernetes.
+
+```
+$ kubectl get pod
+No resources found in default namespace.
+
+$ kubectl apply -f manifests/nginx.yaml
+pod/nginx created
+
+$ kubectl get pod
+NAME    READY   STATUS              RESTARTS   AGE
+nginx   0/1     ContainerCreating   0          5s
+
+$ kubectl get pod
+NAME    READY   STATUS    RESTARTS   AGE
+nginx   1/1     Running   0          28s
+
+$ kubectl delete -f manifests/nginx.yaml
+pod "nginx" deleted
+```
+
+## Parent Libraries
+
+In the previous section, the `nginx.edn` file is called a library. Parent
+libraries are common data that will be merged with the current library's data.
+
+Parent libraries are EDN files that are placed in a `lib` directory somewhere
+up the directory tree from the files being built.
+
+When a parent library is included, it's contents are deep merged in order with
+the current library data going last. Parent libraries can include other
+libraries and so create a hierarchy of data that can be overridden and
+specialized at each level.
+
+In the last section we created a single pod. Now, we'll create another pod and
+see how we can use parent libraries to share common structure.
+
+### Deep merging
+
+When Lighthouse merges data it does it deeply. Deep merging takes two maps of
+nested data and recursively merges the second into the first.
+
+A simple example to start. Take these two maps of data:
+
+```clojure
+{:simple-value 1
+ :map {:one :value}
+ :vector [1 2 3]}
+
+{:simple-value 3
+ :map {:two :other-value}
+ :vector [4 5 6]}
+```
+
+If you deep merge these two, this is the result:
+
+```clojure
+{:simple-value 3
+ :map {:one :value
+       :two :other-value}
+ :vector [1 2 3 4 5 6]}
+```
+
+As you can see `:simple-value` is overridden, the `:map` key has the result of
+merging the two value maps, and `:vector` is a concatenation of the value
+vectors.
+
+When the data is deeply nested, deep merge finds those values and merges them.
+Given these two:
+
+```clojure
+{:deep
+ {:one
+  {:two
+   {:three :value}}}}
+
+{:deep
+ {:one
+  {:two
+   {:three :other-value
+    :four :more-data}}}}
+```
+
+The result is:
+
+```clojure
+{:deep
+ {:one
+  {:two
+   {:three :other-value
+    :four :more-data}}}}
+```
+
+There are more nuances to the way Lighthouse deep merges, including the ability
+to arbitrarily replace data instead of merging, but the above is sufficient for
+now.
+
+### Adding a parent library for pods
+
+In the last section, there were two files (`lighthouse.edn` and `nginx.edn`).
+Now we'll extract a parent library for the common pod data.
+
+Create a `lib/` directory and put the following into a file called `lib/pod.edn`:
+
+```clojure
+{:api-version "v1"
+ :kind "Pod"}
+```
+
+Then update `nginx.edn` to look like this:
+
+```clojure
+{def/from ["pod"]
+ :metadata {:name "nginx"}
+ :spec {:containers
+        {"nginx"
+         {:image "nginx:1.14.2"
+          :ports {:http {:container-port 80}}}}}}
+```
+
+
+If you re-run the `lh build nginx.edn` command again, the manifest file
+`manifests/nginx.yaml` will still be the same:
+
+```yaml
+# ------------------------------------------------------------
+# AUTO-GENERATED FILE. ANY MANUAL CHANGES WILL BE OVERWRITTEN.
+# ------------------------------------------------------------
+---
+apiVersion: v1
+kind: Pod
+metadata:
+  name: nginx
+spec:
+  containers:
+  - image: nginx:1.14.2
+    name: nginx
+    ports:
+    - containerPort: 80
+      name: http
+```
+
+The power of parent libraries comes from their reuse. So, let's make another
+pod that leverages the same parent.
+
+Create another library called `echo.edn` with the following contents:
+
+```clojure
+{def/from ["pod"]
+ :metadata {:name "echo"}
+ :spec {:containers
+        {"echo"
+         {:image "hashicorp/http-echo:0.2.3"
+          :ports {:http {:container-port 5678}}}}}}
+```
+
+Building this (with `lh build echo.edn`) results in
+a `manifests/echo.yaml` that looks like this:
+
+```yaml
+# ------------------------------------------------------------
+# AUTO-GENERATED FILE. ANY MANUAL CHANGES WILL BE OVERWRITTEN.
+# ------------------------------------------------------------
+---
+apiVersion: v1
+kind: Pod
+metadata:
+  name: echo
+spec:
+  containers:
+  - image: hashicorp/http-echo:0.2.3
+    name: echo
+    ports:
+    - containerPort: 5678
+      name: http
+```
+
+There is still some structural duplication in `nginx.edn` and `echo.edn`. To
+refactor this out, we can leverage metadata.
+
+### Metadata
+
+Metadata is arbitrary out-of band data that can be used to populate the data
+that Lighthouse merges.
+
+For example, we can change the `nginx.edn` to look like this:
+
+```clojure
+{def/from ["pod"]
+ def/name "nginx"
+ :metadata {:name ref/name}
+ :spec {:containers
+        {ref/name
+         {:image "nginx:1.14.2"
+          :ports {:http {:container-port 80}}}}}}
+```
+
+The `def/name` line creates a new entry in the metadata map, and then the two
+places that the string "nginx" were have been replaced with `ref/name`, which
+looks up the value.
+
+Metadata can be used in parent library files as well. This is because all
+metadata for a given library and its parents is merged first and then each
+library (and itself) are processed before merging.
+
+So, if we change `lib/pod.edn` to contain this:
+
+```clojure
+{:api-version "v1"
+ :kind "Pod"
+ :metadata {:name ref/name}}
+```
+
+We can remove the `:metadata` key from each of `nginx.edn` and `echo.edn`:
+
+```clojure
+;; nginx.edn
+{def/from ["pod"]
+ def/name "nginx"
+ :spec {:containers
+        {ref/name
+         {:image "nginx:1.14.2"
+          :ports {:http {:container-port 80}}}}}}
+
+;; echo.edn
+{def/from ["pod"]
+ def/name "echo"
+ :spec {:containers
+        {ref/name
+         {:image "hashicorp/http-echo:0.2.3"
+          :ports {:http {:container-port 5678}}}}}}
+```
+
+And the output is identical to before.
+
+This shows that structure can be extracted into libraries and parameterized
+with metadata.
+
+
+## Directory Structure
+
+Up until this point, we have been dealing with a very simple directory
+structure. In the wild, Lighthouse trees usually have more depth, which grants
+more flexibility when constructing data for different environments.
+
+For instance, take this directory tree:
+
+```
+deploy/
+├── lighthouse.edn
+├── lib
+│   ├── nginx.edn
+│   └── pod.edn
+├── prod
+│   └── nginx.edn
+├── qa
+│   └── nginx.edn
+└── staging
+    └── nginx.edn
+```
+
+As before, the `lighthouse.edn` file anchors the root of the data files.
+
+There are several `nginx.edn` files. The one in the `lib` directory looks like this:
+
+```clojure
+{def/from ["pod"]
+ def/name "nginx"
+ :spec {:containers
+        {ref/name
+         {:image "nginx:1.14.2"
+          :ports {:http {:container-port 80}}}}}}
+```
+
+And the `nginx.edn` file in each environment directory (`prod`, `qa`,
+`staging`) looks like this:
+
+```clojure
+{def/from ["nginx"]}
+```
+
+Because there is usually so much sharing between environments, the "leaf"
+libraries tend to be very short and only contain metadata overrides.
+
+### Multiple lib directories
+
+Lighthouse looks for libraries at each level up the directory tree until it
+reaches the `lighthouse.edn` file.
+
+For instance, if we want the `nginx` pod to be in a different Kubernetes
+namespace in prod, we can accomplish this by adding a `lib` directory inside
+`prod` with a library with the same name as the base library (`nginx.edn`):
+
+```
+├── lib
+│   ├── nginx.edn
+│   └── pod.edn
+├── prod
+│   ├── lib
+│   │   └── nginx.edn
+│   └── nginx.edn
+```
+
+And if that `prod/lib/nginx.edn` file looks like this:
+
+```
+{:metadata {:namespace "prod-ns"}}
+```
+
+When the prod nginx is built (with `lh build prod/nginx.edn`), the
+resulting manifest is:
+
+```yaml
+# ------------------------------------------------------------
+# AUTO-GENERATED FILE. ANY MANUAL CHANGES WILL BE OVERWRITTEN.
+# ------------------------------------------------------------
+---
+apiVersion: v1
+kind: Pod
+metadata:
+  name: nginx
+  namespace: prod-ns   <-- new line added because of prod nginx library
+spec:
+  containers:
+  - image: nginx:1.14.2
+    name: nginx
+    ports:
+    - containerPort: 80
+      name: http
+```
+
+Lighthouse accomplished this by merging the data in this order:
+
+* `lib/pod.edn`
+* `lib/nginx.edn`
+* `prod/lib/nginx.edn`
+* `prod/nginx.edn`
+
+What if we wanted the namespace to be `prod-ns` for all pods in the `prod`
+environment? Well, then we could rename `prod/lib/nginx.edn` to
+`prod/lib/pod.edn`, and anything that specifies a parent library of `pod`
+(directly or transitively) will see that data merged in.
+
+In this case, the merging is in this order:
+
+* `lib/pod.edn`
+* `prod/lib/pod.edn`
+* `lib/nginx.edn`
+* `prod/nginx.edn`
+
+This highlights the fact that libraries of the same name at different levels
+are merged together, before they are merged into their child libraries.
+
+
+## Next steps
+
+Lighthouse provides more facilities for tuning the output, such as:
+
+* Running snippets of code to calculate values
+* Combining several library files into a single output manifest
+* Storing metadata in separate files
+
+[<: Installation](02-installation.md) | [CLI and Configuration :>](04-cli-and-config.md)
diff --git a/doc/manual/04-cli-and-config.md b/doc/manual/04-cli-and-config.md
new file mode 100644
index 0000000..13ab87f
--- /dev/null
+++ b/doc/manual/04-cli-and-config.md
@@ -0,0 +1,111 @@
+# CLI and Configuration
+
+The main way to interact with Lighthouse is via its CLI tool `lh`. This tool provides ways to:
+
+- build/render library or manifest files
+- visualize library or manifest files
+- update manifests in-place
+
+## Configuration
+
+For each file `lh` operates on, it will search up the directory tree for a `lighthouse.edn` file.
+
+These `lighthouse.edn` files are used to configure `lighthouse`. The defaults for this file can be found [here](/src/lh/config.clj).
+
+| Setting             | Description                                                                     |
+| ------------------- | ------------------------------------------------------------------------------- |
+| `:library-prefix`   | used to denote library files                                                    |
+| `:metadata-prefix`  | used to denote metadata files                                                   |
+| `:namespaces`       | defines all namespaces `lighthouse` uses                                        |
+| `:output-prefix`    | used to define where renderings get written to disk                             |
+| `:output-format`    | defines what serialization format the resulting manfiests will be serialized in |
+| `:processor`        | defines what (if any) processing should happen on the data                      |
+| `:processors`       | a map of config used to configure `:processor`                                  |
+
+TODO: link to Kube processor and its defaults
+
+## CLI
+
+Given [this structure](../sample/):
+
+```
+├── lib
+│   ├── echo.edn
+│   ├── nginx.edn
+│   └── pod.edn
+├── lighthouse.edn
+├── meta
+│   └── images.edn
+├── prod
+│   ├── echo.edn
+│   ├── lib
+│   │   ├── echo.edn
+│   │   └── pod.edn
+│   └── nginx.edn
+└── qa
+    ├── echo.edn
+    └── nginx.edn
+```
+
+### lh build
+
+This command builds manifests for the libraries specified.
+
+#### Examples
+
+If a whole directory is specified, then all libraries within will be built:
+
+```
+lh build prod/
+```
+
+To build just a single library, specify it directly:
+
+```
+lh build prod/nginx.edn
+```
+
+
+### lh update
+
+This command can be used to update metadata values automatically without needing to edit files.
+
+#### Examples
+
+In the example above, `meta/images.edn` is a file that contains image references used in the `echo.edn` and `nginx.edn` library files. To update the version of nginx from `1.24.0` to `1.25.3`, use the following command:
+
+```
+lh update -s nginx="nginx:1.25.3" meta/images.edn
+```
+
+And the `meta/images.edn` file goes from this:
+
+```
+{:echo "hashicorp/http-echo:0.2.3"
+ :nginx "nginx:1.24.0"}
+```
+
+to this:
+
+```
+{:echo "hashicorp/http-echo:0.2.3"
+ :nginx "nginx:1.25.3"}
+```
+
+### lh visualize
+
+Sometimes the library inheritance tree and merge order can be hard to remember. `lh visualize` renders out an image that shows this information visually.
+
+#### Examples
+
+In the above example, the `prod/echo.edn` library has some local (to prod) overrides. To see how those are merged, run the following:
+
+```
+lh visualize -o prod-echo.png prod/echo.edn
+```
+
+![prod echo.edn visualization](prod-echo.png)
+
+This image shows the tree of dependencies and the table at the top shows the merge order.
+
+[<: Tutorial](03-tutorial.md) | [Inheritance and Merging :>](05-inheritance.md)
diff --git a/doc/manual/05-inheritance.md b/doc/manual/05-inheritance.md
new file mode 100644
index 0000000..0d0f37d
--- /dev/null
+++ b/doc/manual/05-inheritance.md
@@ -0,0 +1,7 @@
+# Inheritance and Merging
+
+* Tree project structure
+* Merging logic
+* Deep merge examples
+
+[<: CLI and Configuration](04-cli-and-config.md) | [Metadata :>](06-metadata.md)
diff --git a/doc/manual/06-metadata.md b/doc/manual/06-metadata.md
new file mode 100644
index 0000000..4a47626
--- /dev/null
+++ b/doc/manual/06-metadata.md
@@ -0,0 +1,6 @@
+# Metadata
+
+* Metadata definition and use
+* Metadata in files
+
+[<: Inheritance and Merging](05-inheritance.md) | [Manifests :>](07-manifests.md)
diff --git a/doc/manual/07-manifests.md b/doc/manual/07-manifests.md
new file mode 100644
index 0000000..a8bf080
--- /dev/null
+++ b/doc/manual/07-manifests.md
@@ -0,0 +1,6 @@
+# Manifests
+
+* Rationale
+* Examples
+
+[<: Metadata](06-metadata.md) | [Processors :>](08-processors.md)
diff --git a/doc/manual/08-processors.md b/doc/manual/08-processors.md
new file mode 100644
index 0000000..14c5e3e
--- /dev/null
+++ b/doc/manual/08-processors.md
@@ -0,0 +1,11 @@
+# Processors
+
+* General information
+
+## Kubernetes (:kube)
+
+* Special metadata (tags)
+* Special vectors of maps
+* Environment handling
+
+[<: Manifests](07-manifests.md) | [Advanced Techniques :>](09-advanced.md)
diff --git a/doc/manual/09-advanced.md b/doc/manual/09-advanced.md
new file mode 100644
index 0000000..fd5bd8b
--- /dev/null
+++ b/doc/manual/09-advanced.md
@@ -0,0 +1,15 @@
+
+# Advanced Techniques
+
+## In-line Clojure
+
+* Intro to Clojure
+* Examples
+* Catalog of included libraries
+
+## Rolling out changes
+
+* Environment-specific override
+* Code conditional
+
+[<: Processors](08-processors.md)
diff --git a/doc/manual/prod-echo.png b/doc/manual/prod-echo.png
new file mode 100644
index 0000000..9c2d897
Binary files /dev/null and b/doc/manual/prod-echo.png differ
diff --git a/doc/sample/lib/echo.edn b/doc/sample/lib/echo.edn
new file mode 100644
index 0000000..5fa0b10
--- /dev/null
+++ b/doc/sample/lib/echo.edn
@@ -0,0 +1,6 @@
+{def/from ["pod"]
+ def/name "echo"
+ :spec {:containers
+        {ref/name
+         {:image :ref/images.echo
+          :ports {:http {:container-port 5678}}}}}}
diff --git a/doc/sample/lib/nginx.edn b/doc/sample/lib/nginx.edn
new file mode 100644
index 0000000..493688f
--- /dev/null
+++ b/doc/sample/lib/nginx.edn
@@ -0,0 +1,6 @@
+{def/from ["pod"]
+ def/name "nginx"
+ :spec {:containers
+        {ref/name
+         {:image :ref/images.nginx
+          :ports {:http {:container-port 80}}}}}}
diff --git a/doc/sample/lib/pod.edn b/doc/sample/lib/pod.edn
new file mode 100644
index 0000000..91cbfdf
--- /dev/null
+++ b/doc/sample/lib/pod.edn
@@ -0,0 +1,3 @@
+{:api-version "v1"
+ :kind "Pod"
+ :metadata {:name ref/name}}
diff --git a/doc/sample/lighthouse.edn b/doc/sample/lighthouse.edn
new file mode 100644
index 0000000..02bf580
--- /dev/null
+++ b/doc/sample/lighthouse.edn
@@ -0,0 +1,2 @@
+{:output-format :yaml
+ :processor :kube}
diff --git a/doc/sample/meta/images.edn b/doc/sample/meta/images.edn
new file mode 100644
index 0000000..abc935a
--- /dev/null
+++ b/doc/sample/meta/images.edn
@@ -0,0 +1,2 @@
+{:echo "hashicorp/http-echo:0.2.3"
+ :nginx "nginx:1.24.0"}
diff --git a/doc/sample/prod/echo.edn b/doc/sample/prod/echo.edn
new file mode 100644
index 0000000..4b969e1
--- /dev/null
+++ b/doc/sample/prod/echo.edn
@@ -0,0 +1 @@
+{def/from ["echo"]}
diff --git a/doc/sample/prod/lib/echo.edn b/doc/sample/prod/lib/echo.edn
new file mode 100644
index 0000000..9e4bad7
--- /dev/null
+++ b/doc/sample/prod/lib/echo.edn
@@ -0,0 +1 @@
+{:in/spec.containers {ref/name {:in/ports.http.container-port 5600}}}
diff --git a/doc/sample/prod/lib/pod.edn b/doc/sample/prod/lib/pod.edn
new file mode 100644
index 0000000..1d06125
--- /dev/null
+++ b/doc/sample/prod/lib/pod.edn
@@ -0,0 +1 @@
+{:metadata {:namespace "prod-ns"}}
diff --git a/doc/sample/prod/manifests/echo.yaml b/doc/sample/prod/manifests/echo.yaml
new file mode 100644
index 0000000..b20a389
--- /dev/null
+++ b/doc/sample/prod/manifests/echo.yaml
@@ -0,0 +1,16 @@
+# ------------------------------------------------------------
+# AUTO-GENERATED FILE. ANY MANUAL CHANGES WILL BE OVERWRITTEN.
+# ------------------------------------------------------------
+---
+apiVersion: v1
+kind: Pod
+metadata:
+  name: echo
+  namespace: prod-ns
+spec:
+  containers:
+  - image: hashicorp/http-echo:0.2.3
+    name: echo
+    ports:
+    - containerPort: 5600
+      name: http
diff --git a/doc/sample/prod/manifests/nginx.yaml b/doc/sample/prod/manifests/nginx.yaml
new file mode 100644
index 0000000..edcf3ba
--- /dev/null
+++ b/doc/sample/prod/manifests/nginx.yaml
@@ -0,0 +1,16 @@
+# ------------------------------------------------------------
+# AUTO-GENERATED FILE. ANY MANUAL CHANGES WILL BE OVERWRITTEN.
+# ------------------------------------------------------------
+---
+apiVersion: v1
+kind: Pod
+metadata:
+  name: nginx
+  namespace: prod-ns
+spec:
+  containers:
+  - image: nginx:1.24.0
+    name: nginx
+    ports:
+    - containerPort: 80
+      name: http
diff --git a/doc/sample/prod/nginx.edn b/doc/sample/prod/nginx.edn
new file mode 100644
index 0000000..61fcf2f
--- /dev/null
+++ b/doc/sample/prod/nginx.edn
@@ -0,0 +1 @@
+{def/from ["nginx"]}
diff --git a/doc/sample/qa/echo.edn b/doc/sample/qa/echo.edn
new file mode 100644
index 0000000..4b969e1
--- /dev/null
+++ b/doc/sample/qa/echo.edn
@@ -0,0 +1 @@
+{def/from ["echo"]}
diff --git a/doc/sample/qa/manifests/echo.yaml b/doc/sample/qa/manifests/echo.yaml
new file mode 100644
index 0000000..9945b14
--- /dev/null
+++ b/doc/sample/qa/manifests/echo.yaml
@@ -0,0 +1,15 @@
+# ------------------------------------------------------------
+# AUTO-GENERATED FILE. ANY MANUAL CHANGES WILL BE OVERWRITTEN.
+# ------------------------------------------------------------
+---
+apiVersion: v1
+kind: Pod
+metadata:
+  name: echo
+spec:
+  containers:
+  - image: hashicorp/http-echo:0.2.3
+    name: echo
+    ports:
+    - containerPort: 5678
+      name: http
diff --git a/doc/sample/qa/manifests/nginx.yaml b/doc/sample/qa/manifests/nginx.yaml
new file mode 100644
index 0000000..f86820d
--- /dev/null
+++ b/doc/sample/qa/manifests/nginx.yaml
@@ -0,0 +1,15 @@
+# ------------------------------------------------------------
+# AUTO-GENERATED FILE. ANY MANUAL CHANGES WILL BE OVERWRITTEN.
+# ------------------------------------------------------------
+---
+apiVersion: v1
+kind: Pod
+metadata:
+  name: nginx
+spec:
+  containers:
+  - image: nginx:1.24.0
+    name: nginx
+    ports:
+    - containerPort: 80
+      name: http
diff --git a/doc/sample/qa/nginx.edn b/doc/sample/qa/nginx.edn
new file mode 100644
index 0000000..61fcf2f
--- /dev/null
+++ b/doc/sample/qa/nginx.edn
@@ -0,0 +1 @@
+{def/from ["nginx"]}
diff --git a/new-manual.md b/new-manual.md
new file mode 100644
index 0000000..a403bf6
--- /dev/null
+++ b/new-manual.md
@@ -0,0 +1,118 @@
+Proposed outline of new documentation. Each heading is a page, with bullet
+points explaining content.
+
+Pages:
+
+<!-- MarkdownTOC -->
+
+* [Introduction](#introduction)
+* [Installation](#installation)
+* [Tutorial](#tutorial)
+    * [Getting Started](#getting-started)
+    * [Libraries](#libraries)
+    * [Directory Structure](#directory-structure)
+    * [Next Steps](#next-steps)
+* [Configuration and CLI](#configuration-and-cli)
+    * [build](#build)
+    * [update](#update)
+    * [visualize](#visualize)
+* [Inheritance and Merging](#inheritance-and-merging)
+* [Metadata](#metadata)
+* [Manifests](#manifests)
+* [Processors](#processors)
+    * [Kubernetes (:kube)](#kubernetes-kube)
+* [Advanced techniques](#advanced-techniques)
+    * [In-line Clojure](#in-line-clojure)
+    * [Rolling out changes](#rolling-out-changes)
+
+<!-- /MarkdownTOC -->
+
+# Introduction
+
+* Intro
+* Rationale
+
+# Installation
+
+* Comprehensive installation instructions
+
+# Tutorial
+
+## Getting Started
+
+* Installation
+* Intro to EDN
+* First run
+* 0 to first Kubernetes manifest generated
+
+## Libraries
+
+* Parent libraries
+* Deep merging overview and examples
+* Extracting out parent libraries
+* Intro to metadata
+
+## Directory Structure
+
+* Typical directory structure
+* Intro to inheritance
+
+## Next Steps
+
+* Links to remaining documentation
+
+# Configuration and CLI
+
+* Summary
+* Configuration
+
+## build
+
+* Examples
+
+## update
+
+* Examples
+
+## visualize
+
+* Examples
+
+# Inheritance and Merging
+
+* Tree project structure
+* Merging logic
+* Deep merge examples
+
+# Metadata
+
+* Metadata definition and use
+* Metadata in files
+
+# Manifests
+
+* Rationale
+* Examples
+
+# Processors
+
+* General information
+
+## Kubernetes (:kube)
+
+* Special metadata (tags)
+* Special vectors of maps
+* Environment handling
+
+# Advanced techniques
+
+## In-line Clojure
+
+* Intro to Clojure
+* Examples
+* Catalog of included libraries
+
+## Rolling out changes
+
+* Environment-specific override
+* Code conditional