diff --git a/doc/json-signing/json-signing.txt b/doc/json-signing/json-signing.txt
index b46452706..d5c688b41 100644
--- a/doc/json-signing/json-signing.txt
+++ b/doc/json-signing/json-signing.txt
@@ -35,7 +35,7 @@ worth the cost.
 Overall, though, the jchris approach's structure of the JSON file is
 good.
 
-Notably, it satisifies on of my other goals:
+Notably, it satisfies on of my other goals:
 
 GOAL #2) The document still be human-readable.
 
@@ -102,6 +102,8 @@ SIGNING
 
 -- the resulting string is 'C', the camli-signed JSON document.
 
+   (The output file is in doc/example/signing-after.camli)
+
 In review:
 
 O == the object to be signed
@@ -141,6 +143,6 @@ VERIFYING
 -- using 'camliSigner', a camli blobref, find the blob (cached, via
    camli/web lookup, etc) that represents a GPG public key.
 
--- use GnuPG or equivalent libraries to verify that the ASCI-armored
+-- use GnuPG or equivalent libraries to verify that the ASCII-armored
    GPG signature in "camliSig" signs the bytes in 'BP' using the
    GPG public key found via the 'camliSigner' blobref
diff --git a/doc/overview.txt b/doc/overview.txt
index 6852e9cee..821dc3599 100644
--- a/doc/overview.txt
+++ b/doc/overview.txt
@@ -49,7 +49,7 @@ Schema of files/objects in Layer 1:
 * Let's start by describing the storage of files that aren't self-describing,
   e.g. "some-notes.txt" (as opposed to a jpg file from a camera that might
   likely contain EXIF data, addressed later...).  This file, for reference,
-  is in doc/example/some-notes.txt
+  is in doc/json-signing/example/some-notes.txt
 
 * The bytes of file "some-notes.txt" are stored as-is in one blob,
   addressed as "sha1-8ba9e53cbc83c1be3835b94a3690c3b03de0b522".
@@ -68,20 +68,20 @@ Schema of files/objects in Layer 1:
   in-line.
 
   This file would thus be represented by a JSON file, as seen in
-  docs/examples/some-notes.txt.camli, and addressed as
-  "sha1-7e7960756b39cd7da614e7edbcf1fa7d696eb660", its sha1sum.
-  This identifier can be used in directory listings, etc.
-  Note that camli files do not have any magical filename, as they're
-  not typically stored with their filename.  (they are in the doc/examples/
-  directory just to separate them out, but that's a rare case.)
-  Instead, a camli JSON object is known as such if the bytes of the file
-  begin exactly with the bytes:
+  docs/json-signing/example/some-notes.txt.camli, and addressed as
+  "sha1-7e7960756b39cd7da614e7edbcf1fa7d696eb660", its sha1sum. This identifier
+  can be used in directory listings, etc. Note that camli files do not have any
+  magical filename, as they're not typically stored with their filename. (they
+  are in the doc/json-signing/examples/ directory just to separate them out, but
+  that's a rare case.) Instead, a camli JSON object is known as such if the
+  bytes of the file begin exactly with the bytes:
 
         {"camliVersion"
 
   ... which lets upper layers know what it is, and how to index it.
 
-  See spec.txt for details on Camli JSON objects and their schema.
+  See the doc/schema/ directory for details on Camli JSON objects and their
+  schema.
 
 * Note that camli files can represent: