diff --git a/docs/architecture.md b/docs/architecture.md
index f9f1d6fbe..975ae9b1c 100644
--- a/docs/architecture.md
+++ b/docs/architecture.md
@@ -34,9 +34,9 @@ In this section, we will look at the toolchain that powers the overall Mu archit
 
 ### Translation
 
-Now let us look at how a Mufile turns into a ready-to-run package.  This will not describe the precise translation and
-set of targets (that is available in the [metadata specification document](metadata.md)), instead focusing on the
-various bits of data and code involved, the plugin architecture, and overall translation process flow.
+Now let us look at how a Mufile turns into a ready-to-run package.  This will not describe the metadata and precise
+translation targets (those are available as separate docs [here](metadata.md) and [here](targets.md), respectively);
+instead, we will look at the tools, plugin architecture, and overall translation process.
 
 TODO(joe): write this section; just cover the overall structure and plugin model, not the details of each target.
 
diff --git a/docs/targets.md b/docs/targets.md
index e18064e23..06a687ff5 100644
--- a/docs/targets.md
+++ b/docs/targets.md
@@ -186,8 +186,9 @@ TODO(joe): perhaps we should have an `aws/cf/customresource` extension type for
 As we saw above, AWS services are available as Stacks.  Let us now look at how they are expressed in Mu metadata and,
 more interestingly, how they are transformed to underlying resource concepts.  It's important to remember that these
 aren't "higher level" abstractions in any sense of the word; instead, they map directly onto AWS resources.  (Of course,
-other higher level abstractions may compose these platform primitives into more interesting services.  The key primitive
-to making this direct mapping work is `mu/extension`.  A simplified S3 bucket Stack, for example, looks like this:
+other higher level abstractions may compose these platform primitives into more interesting services.)
+
+A simplified S3 bucket Stack, for example, looks like this:
 
     name: bucket
     parameters:
@@ -221,10 +222,11 @@ to making this direct mapping work is `mu/extension`.  A simplified S3 bucket St
                         }
                     }
 
-This simply leverages the abiliity to pass lifecycle events off to a provider, in this case `aws/cf/template`, along
-with some metadata, in this case a simple wrapper around the [AWS CloudFormation S3 Bucket specification format](
-http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-s3-bucket.html).  The provider manages
-generating metadata and interacting with the AWS services required for provisioning, updating, and destroying resources.
+The key primitive at play here is `mu/extension`.   This passes off lifecycle events to a provider, in this case
+`aws/cf/template`, along with some metadata, in this case a simple wrapper around the [AWS CloudFormation S3 Bucket
+specification format](
+http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-s3-bucket.html).  The provider generates
+metadata and knows how to interact with AWS services required for provisioning, updating, and destroying resources.
 
 TODO(joe): we need to specify how extensions work somewhere.