diff --git a/doc/manual/redirects.json b/doc/manual/redirects.json
index 0a6c7150800..ecc6a96765e 100644
--- a/doc/manual/redirects.json
+++ b/doc/manual/redirects.json
@@ -337,7 +337,7 @@
         "string-literal": "string-literals.html"
     },
     "language/derivations.html": {
-        "builder-execution": "../store/building.html#builder-execution"
+        "builder-execution": "../store/building.html"
     },
     "installation/installing-binary.html": {
         "linux": "uninstall.html#linux",
diff --git a/doc/manual/source/SUMMARY.md.in b/doc/manual/source/SUMMARY.md.in
index 8b6b29f6a7f..833c5ac2a95 100644
--- a/doc/manual/source/SUMMARY.md.in
+++ b/doc/manual/source/SUMMARY.md.in
@@ -19,9 +19,10 @@
 - [Nix Store](store/index.md)
   - [File System Object](store/file-system-object.md)
     - [Content-Addressing File System Objects](store/file-system-object/content-address.md)
+    - [Exposing in OS File Systems](store/file-system-object/os-file-system.md)
   - [Store Object](store/store-object.md)
     - [Content-Addressing Store Objects](store/store-object/content-address.md)
-  - [Store Path](store/store-path.md)
+  - [Store Path and Store Directory](store/store-path.md)
   - [Store Derivation and Deriving Path](store/derivation/index.md)
     - [Derivation Outputs and Types of Derivations](store/derivation/outputs/index.md)
       - [Content-addressing derivation outputs](store/derivation/outputs/content-address.md)
diff --git a/doc/manual/source/glossary.md b/doc/manual/source/glossary.md
index 502e6d4de6b..a31263c6664 100644
--- a/doc/manual/source/glossary.md
+++ b/doc/manual/source/glossary.md
@@ -35,7 +35,7 @@
 
   A derivation can be thought of as a [pure function](https://en.wikipedia.org/wiki/Pure_function) that produces new [store objects][store object] from existing store objects.
 
-  Derivations are implemented as [operating system processes that run in a sandbox](@docroot@/store/building.md#builder-execution).
+  Derivations are implemented as [operating system processes that run in a sandbox](@docroot@/store/building.md).
   This sandbox by default only allows reading from store objects specified as inputs, and only allows writing to designated [outputs][output] to be [captured as store objects](@docroot@/store/building.md#processing-outputs).
 
   A derivation is typically specified as a [derivation expression] in the [Nix language], and [instantiated][instantiate] to a [store derivation].
diff --git a/doc/manual/source/protocols/json/schema/store-object-info-v2.yaml b/doc/manual/source/protocols/json/schema/store-object-info-v2.yaml
index 3ed7e99e28d..b5a6bed676c 100644
--- a/doc/manual/source/protocols/json/schema/store-object-info-v2.yaml
+++ b/doc/manual/source/protocols/json/schema/store-object-info-v2.yaml
@@ -107,7 +107,7 @@ $defs:
         type: string
         title: Store Directory
         description: |
-          The [store directory](@docroot@/store/store-path.md#store-directory) this store object belongs to (e.g. `/nix/store`).
+          The [path to the store directory](@docroot@/store/store-path.md#store-directory-path) this store object belongs within (e.g. `/nix/store`).
     additionalProperties: false
 
   impure:
diff --git a/doc/manual/source/protocols/store-path.md b/doc/manual/source/protocols/store-path.md
index 5be2355015f..ac89f3ce9ad 100644
--- a/doc/manual/source/protocols/store-path.md
+++ b/doc/manual/source/protocols/store-path.md
@@ -18,7 +18,7 @@ where
 
 - `name` = the name of the store object.
 
-- `store-dir` = the [store directory](@docroot@/store/store-path.md#store-directory)
+- `store-dir` = the [path of the store directory](@docroot@/store/store-path.md#store-directory-path)
 
 - `digest` = base-32 representation of the compressed to 160 bits [SHA-256] hash of `fingerprint`
 
diff --git a/doc/manual/source/store/building.md b/doc/manual/source/store/building.md
index 32e80012934..4d25417a356 100644
--- a/doc/manual/source/store/building.md
+++ b/doc/manual/source/store/building.md
@@ -1,72 +1,158 @@
 # Building
 
-## Normalizing derivation inputs
+As discussed in the [main page on derivations](./derivation/index.md):
 
-- Each input must be [realised] prior to building the derivation in question.
+> A derivation is a specification for running an executable on precisely defined input to produce one or more [store objects][store object].
 
-[realised]: @docroot@/glossary.md#gloss-realise
+This page describes *building* a derivation, which is to say following the instructions in the derivation to actually run the executable.
+Some elements of derivations are self-explanatory.
+For example, the arguments specified in the derivation really are the arguments passed to the executable.
+In other cases, however, there is additional procedure true for all derivations, which is therefore *not* specified in the derivation.
+This page specifies this invariant procedure that is true for all derivations, too.
+
+The chief design consideration for the building process is *determinism*.
+Conventional operating systems are typically not designed with determinism in mind.
+But determinism is needed to make Nix's build caching a transparent abstraction.
+
+> **Explanation**
+>
+> For example, no one wants to slightly modify a derivation, and then find that it no longer builds for an unrelated reason, because the original derivation *also* doesn't build anymore, but the cache hit on the original derivation was hiding this.
+> We want builds that succeed once to continue succeeding, to encourage fearless modification of old build recipes.
+> Determinism is what enables things that once worked to keep working.
+
+The life cycle of a build can be broken down into 3 parts:
+
+1. Spawn the builder process with the proper environment, including the correct process arguments, environment variables, and file system state.
+
+2. Wait for the standard output and error of the process to be closed and/or the process to exit.
+   (If the standard streams are closed but the process hasn't exited, Nix will kill the process.)
+
+   Nix also logs the standard output and error of the process, but this is just for human convenience and does not influence the behavior of the system.
+   (Builder processes have no idea what the consumer of their standard output and error does with those streams, only that they are indeed consumed so buffers do not fill up and writes to them will continue to succeed.)
+
+3. Processing the outputs after the builder has exited.
 
-- Once this is done, the derivation is *normalized*, replacing each input deriving path with its store path, which we now know from realising the input.
+   The builder process on exit should have left behind files for each output the derivation is supposed to produce.
+   The files must be processed to turn them into bona fide store objects.
+   If the processing succeeds, those store objects are associated with the derivation as (the results of) a successful build.
 
-## Builder Execution {#builder-execution}
+Step (3) happens externally, with just inert data since the process has exited or been killed by then.
+Step (1) however is best described not from Nix's perspective, but from the process's perspective.
+
+> **Explanation**
+>
+> Ultimately, what matters for determinism is the behavior of IO operations that the process attempts (whether these are successes or failures), because of how they affect the output files, and how they affect the further execution of the builder process.
+> From Nix (and the operating system)'s perspective, there are many, many different ways — different implementation strategies — of effecting the same I/O behavior.
+> But from the process's perspective, there is only one correct behavior.
+
+## What derivations can be built
+
+Actually only some derivations are ready to be built.
+In particular, only [*resolved*](./resolution.md) derivations can be built.
+That is to say, a derivation that depends on other derivations is not ready yet to be built, because those other derivations might not be built.
+If the other derivations are indeed built, we can witness this fact by resolving the derivation, and converting all the derivation's input references into plain store paths.
+
+> **Note**
+>
+> Note that [input-addressing](derivation/outputs/input-address.md) derivations are improperly resolved.
+> As discussed on the linked page, the current input-addressing algorithm does not respect resolution-equivalence of derivations (\\(\\sim_\mathrm{Drv}\\)).
+> That means that if Nix properly resolved an input-addressed derivation, the resolved derivation would have different input addresses, violating expectations.
+> Nix therefore improperly resolves the derivation, keeping its original input address output paths, creating an invalid derivation that is both resolved and instructed to create the outputs at the originally expected paths.
+
+## Environment of the builder process
 
 The [`builder`](./derivation/index.md#builder) is executed as follows:
 
-- A temporary directory is created where the build will take place. The
-  current directory is changed to this directory.
+### File system
+
+The builder should have access to a limited file system where only certain objects are available.
+The most important exposed files are the inputs (other store objects) of the (resolved) derivation.
+Additionally, some other files are exposed.
+
+#### Store inputs
+
+The builder will be run against a file system in which the [closure] of the inputs is mounted inside the [store directory][store directory path].
+In particular, consider a store that just contains this closure.
+That store may be exposed to the file system according to the rules specified in the [Exposing Store Objects in OS File Systems](./store-path.md#exposing) documentation.
+This precisely defines the file system layout of the store that should be visible to the builder process.
+
+> **Note**
+>
+> Historically, Nix exposed *at least* the following store contents to the builder, but also arbitrarily other store objects, due to limitations around operating systems' file system virtualization capabilities, and wanting to avoid copying or moving files.
+> It still can do this in so-called *unsandboxed* builds.
+>
+> Such builds should be considered an unsafe extension, but one that works less badly against non-malicious derivations than might be expected.
+> This is because store paths are relatively unpredictable, so a well-behaved program is unlikely to stumble upon a store object it wasn't supposed to know about.
+>
+> As operating systems developed better file system primitives, the need for disabling sandboxing has lessened greatly over the years, and this trend should continue into the future.
+
+[realised]: @docroot@/glossary.md#gloss-realise
+[closure]: @docroot@/glossary.md#gloss-closure
+[store directory path]: ./store-path.md#store-directory-path
+
+### Other file system state
+
+- The current working directory of the builder process will be a fresh temporary directory that is initially empty.
 
   See the per-store [`build-dir`](@docroot@/store/types/local-store.md#store-local-store-build-dir) setting for more information.
 
-- The environment is cleared and set to the derivation attributes, as
-  specified above.
+- Basic device nodes for essential operations (null device, random number generation, standard streams as a pseudo terminal)
+
+  (A pseudo terminal would not be strictly necessary since the standard streams are passively logging, not there to facilitate interaction.
+  But it is still useful to entice programs to do nicer logging with e.g. colors etc.)
+
+- On Linux: Process information via `/proc`
+
+- Minimal user and group identity information
 
-- In addition, the following variables are set:
+- A loopback-only network configuration with hostname set to `localhost`
 
-  - `NIX_BUILD_TOP` contains the path of the temporary directory for
-    this build.
+> **Note**
+>
+> Fixed-output derivations have access to additional operating system state to facilitate communication with the outside world, such as network name resolution and TLS certificate verification.
+> This is necessary because these derivations are allowed to access the network, unlike regular derivations which are fully sandboxed.
 
-  - Also, `TMPDIR`, `TEMPDIR`, `TMP`, `TEMP` are set to point to the
-    temporary directory. This is to prevent the builder from
-    accidentally writing temporary files anywhere else. Doing so
-    might cause interference by other processes.
+### Environment variables {#env-vars}
 
-  - `PATH` is set to `/path-not-set` to prevent shells from
-    initialising it to their built-in default value.
+The environment is cleared and set to the derivation attributes, as
+specified above.
 
-  - `HOME` is set to `/homeless-shelter` to prevent programs from
-    using `/etc/passwd` or the like to find the user's home
-    directory, which could cause impurity. Usually, when `HOME` is
-    set, it is used as the location of the home directory, even if
-    it points to a non-existent path.
+For most derivations types this must contain at least:
 
-  - `NIX_STORE` is set to the path of the top-level Nix store
-    directory (typically, `/nix/store`).
+- For each output declared in `outputs`, the corresponding environment variable is set to point to the intended path in the Nix store for that output.
+  Each output path is a concatenation of the cryptographic hash of all build inputs, the `name` attribute and the output name.
+  (The output name is omitted if it's `out`.)
 
-  - `NIX_ATTRS_JSON_FILE` & `NIX_ATTRS_SH_FILE` if `__structuredAttrs`
-    is set to `true` for the derivation. A detailed explanation of this
-    behavior can be found in the
-    [section about structured attrs](@docroot@/language/advanced-attributes.md#adv-attr-structuredAttrs).
+In addition, the following variables are set:
 
-  - For each output declared in `outputs`, the corresponding
-    environment variable is set to point to the intended path in the
-    Nix store for that output. Each output path is a concatenation
-    of the cryptographic hash of all build inputs, the `name`
-    attribute and the output name. (The output name is omitted if
-    it’s `out`.)
+- `NIX_BUILD_TOP` contains the path of the temporary directory for this build.
 
-- If an output path already exists, it is removed. Also, locks are
-  acquired to prevent multiple [Nix instances][Nix instance] from performing the same
-  build at the same time.
+- Also, `TMPDIR`, `TEMPDIR`, `TMP`, `TEMP` are set to point to the temporary directory.
+  This is to prevent the builder from accidentally writing temporary files anywhere else.
+  Doing so might cause interference by other processes.
 
-- A log of the combined standard output and error is written to
-  `/nix/var/log/nix`.
+- `PATH` is set to `/path-not-set` to prevent shells from initialising it to their built-in default value.
 
-- The builder is executed with the arguments specified by the
-  attribute `args`. If it exits with exit code 0, it is considered to
-  have succeeded.
+- `HOME` is set to `/homeless-shelter`.
+   (Without sandboxing, this serves as "soft sandboxing" --- it discourages programs from using `/etc/passwd` or the like to find the user's home directory, which could cause impurity.)
+   Usually, when `HOME` is set, it is used as the location of the home directory, even if it points to a non-existent path.
 
-- The temporary directory is removed (unless the `-K` option was
-  specified).
+- `NIX_STORE` is set to the path of the top-level Nix [store directory path] (typically, `/nix/store`).
+
+- `NIX_ATTRS_JSON_FILE` & `NIX_ATTRS_SH_FILE` if `__structuredAttrs` is set to `true` for the derivation.
+  A detailed explanation of this behavior can be found in the [section about structured attrs](@docroot@/language/advanced-attributes.md#adv-attr-structuredAttrs).
+
+## Builder Execution
+
+- If an output path already exists, it is removed.
+  Also, locks are acquired to prevent multiple [Nix instances][Nix instance] from performing the same build at the same time.
+
+- A log of the combined standard output and error is written to `/nix/var/log/nix`.
+
+- The builder is executed with the arguments specified by the attribute `args`.
+  If it exits with exit code 0, it is considered to have succeeded.
+
+- The temporary directory is removed (unless the [`--keep-failed`](@docroot@/command-ref/opt-common.md#opt-keep-failed) option was specified).
 
 ## Processing outputs
 
@@ -74,28 +160,28 @@ If the builder exited successfully, the following steps happen in order to turn
 
 - **Normalize the file permissions**
 
-  Nix sets the last-modified timestamp on all files
-  in the build result to 1 (00:00:01 1/1/1970 UTC), sets the group to
-  the default group, and sets the mode of the file to 0444 or 0555
-  (i.e., read-only, with execute permission enabled if the file was
-  originally executable). Any possible `setuid` and `setgid`
-  bits are cleared.
-
-  > **Note**
-  >
-  > Setuid and setgid programs are not currently supported by Nix.
-  > This is because the Nix archives used in deployment have no concept of ownership information,
-  > and because it makes the build result dependent on the user performing the build.
+  The files must conform to the model described in the [Exposing in OS file systems](./file-system-object/os-file-system.md) section.
+  For example, timestamps and permissions must be forced to sentinel values.
 
 - **Calculate the references**
 
-  Nix scans each output path for
-  references to input paths by looking for the hash parts of the input
-  paths. Since these are potential runtime dependencies, Nix registers
-  them as dependencies of the output paths.
+  Nix scans each output path for references to input store objects by looking for the store path digests of each input.
+  (The name part is ignored when scanning; an input's hash part that is not followed by a `-` and the correct name part still scans as a reference.
+  Likewise, a digest not preceded by the [store directory path] also still scans as a reference.)
+  Since these are potential runtime dependencies, Nix will register them as references of the output store object they occur in.
 
-  Nix also scans for references to other outputs' paths in the same way, because outputs are allowed to refer to each other.
+  Nix also scans for references from one output to another in the same way, because outputs are allowed to refer to each other.
   If the outputs' references to each other form a cycle, this is an error, because the references of store objects much be acyclic.
 
+  In the case of derivations with output paths that are fixed in advance (i.e. [input-addressing] derivations, or [fixed content-addressing] derivations), the actual final store path to each output is used during the build.
+  For [floating content-addressing] derivations, however, the final store path is not known in advance by definition.
+  Scratch store paths must therefore be used instead.
+  Scanning will use those scratch paths, but then any output-to-be that contains such a scanned scratch path must be rewritten to instead use the final (content-addressed) path of the output in question.
+
+At this point, the file system data is in the proper form, and the valid acyclic reference data for each output is also calculated, so the outputs can be registered as proper store objects, and associated with the derivation in the [build trace] in the record for a successful build.
 
 [Nix instance]: @docroot@/glossary.md#gloss-nix-instance
+[input-addressing]: ./derivation/outputs/input-address.md
+[fixed content-addressing]: ./derivation/outputs/content-address.md#fixed
+[floating content-addressing]: ./derivation/outputs/content-address.md#floating
+[build trace]: ./build-trace.md
diff --git a/doc/manual/source/store/file-system-object/os-file-system.md b/doc/manual/source/store/file-system-object/os-file-system.md
new file mode 100644
index 00000000000..155946d9a24
--- /dev/null
+++ b/doc/manual/source/store/file-system-object/os-file-system.md
@@ -0,0 +1,35 @@
+# Exposing in OS File Systems
+
+Nix's [file system object] data model is minimal and abstract.
+But to actually be used by software, file system objects need to be made available through the operating system's file system.
+This is sometimes called "mounting" or "exposing" the file system object, though do note it may or may not be implemented with what the operating system calls "mounting".
+
+[file system object]: ../file-system-object.md
+
+## Metadata normalization
+
+File systems typically contain other metadata that is outside Nix's data model.
+To avoid this other metadata being a side channel and source of nondeterminism, Nix is careful to normalize to fixed values.
+For example, on Unix, the following metadata normalization occurs:
+
+- The creation and last modification timestamps on all files are set to Unix Epoch 1s (00:00:01 1/1/1970 UTC)
+
+- The group is set to the default group
+
+- The Unix mode of the file to 0444 or 0555 (i.e., read-only, with execute permission enabled if the file was originally executable).
+
+- Any possible `setuid` and `setgid` bits are cleared.
+
+  > **Note**
+  >
+  > Setuid and setgid programs are not currently supported by Nix.
+  > This is because the Nix archives used in deployment have no concept of ownership information,
+  > and because it makes the build result dependent on the user performing the build.
+
+> **Explanation**
+>
+> As discussesed before, Nix essentially shares its file system object data model with other tools like Git.
+> But those tools tend to ignore this metadata in both directions --- when reading files, like Nix, but when writing files, timestamps are set organically, and the user is free to set other special permissions (setuid, setgid, sticky, etc.) however they like, with the proviso that since they are ignored by Git, Git will silently loose that information.
+> This metadata normalization for determinism is therefore what distinguishes Nix from other tools more than the data model itself.
+>
+> Nix's approach is motivated by deterministic building. Whereas Git can assume that humans running commands will simply ignore timestamps etc. as appropriate, understanding they are local and ephemeral, Nix aims to run software that was not necessarily designed with Nix in mind, and is unaware of whatever sandboxing/virtualization is in place.
diff --git a/doc/manual/source/store/index.md b/doc/manual/source/store/index.md
index f1e8f140298..d063fc4fdc0 100644
--- a/doc/manual/source/store/index.md
+++ b/doc/manual/source/store/index.md
@@ -2,4 +2,33 @@
 
 The *Nix store* is an abstraction to store immutable file system data (such as software packages) that can have dependencies on other such data.
 
-There are [multiple types of Nix stores](./types/index.md) with different capabilities, such as the default one on the [local filesystem](./types/local-store.md) (`/nix/store`) or [binary caches](./types/http-binary-cache-store.md).
+Concretely, albeit using concepts that are only defined in the rest of the chapter, a store consists of:
+
+- A set of [store objects][store object], the immutable file system data.
+
+  This can also be looked at as a map from [store paths][store path] to store objects.
+
+- A set of [derivations][derivation], instructions for building store objects.
+
+  This can also be looked at as a map from [store paths][store path] to derivations.
+  Since store paths to derivations always end in `.drv`, and store paths to other store objects never do, the two maps can also be combined into one.
+  Derivations can also be encoded as store objects too.
+
+- A [build trace], a record of which derivations have been built and what they produced.
+
+  > **Warning**
+  >
+  > The concept of a build trace is currently
+  > [**experimental**](@docroot@/development/experimental-features.md#xp-feature-ca-derivations)
+  > and subject to change.
+
+There are [multiple types of Nix stores][store type] with different capabilities, such as the default one on the [local file system][local store] (`/nix/store`) or [binary caches][binary cache].
+
+[store object]: ./store-object.md
+[store path]: ./store-path.md
+[derivation]: ./derivation/index.md
+[build trace]: ./build-trace.md
+
+[store type]: ./types/index.md
+[local store]: ./types/local-store.md
+[binary cache]: ./types/http-binary-cache-store.md
diff --git a/doc/manual/source/store/store-object/content-address.md b/doc/manual/source/store/store-object/content-address.md
index 7834ac51027..bf90fe4fce3 100644
--- a/doc/manual/source/store/store-object/content-address.md
+++ b/doc/manual/source/store/store-object/content-address.md
@@ -9,7 +9,7 @@ In particular, the content-addressing scheme will ensure that the digest of the
 
 - file system object graph (the root one and its children, if it has any)
 - references
-- [store directory](../store-path.md#store-directory)
+- [store directory path](../store-path.md#store-directory-path)
 - name
 
 of the store object, and not any other information, which would not be an intrinsic property of that store object.
diff --git a/doc/manual/source/store/store-path.md b/doc/manual/source/store/store-path.md
index 4061f3653f6..d87b7b90f70 100644
--- a/doc/manual/source/store/store-path.md
+++ b/doc/manual/source/store/store-path.md
@@ -1,21 +1,30 @@
-# Store Path
+# Store Path and Store Directory
 
-> **Example**
->
-> `/nix/store/a040m110amc4h71lds2jmr8qrkj2jhxd-git-2.38.1`
->
-> A rendered store path
+Nix's [store object] and [file system object] data models are minimal and abstract.
+But to actually be used by software, store objects need to be made available through the operating system's file system.
+
+This is done by exposing all the store objects in a single *[store directory][store directory path]*.
+Every entry in that directory is a *[store path base name]* pointing to a store object.
+Store objects exposed in this way can then be referenced by *[store paths][store path]*.
+
+[store object]: ./store-object.md
+[file system object]: ./file-system-object.md
+[store path]: #store-path
+[store path base name]: #store-path-base-name
+[store directory path]: #store-directory-path
 
-Nix implements references to [store objects](./store-object.md) as *store paths*.
+## Store Path Base Name
 
-Think of a store path as an [opaque], [unique identifier]:
-The only way to obtain store path is by adding or building store objects.
-A store path will always reference exactly one store object.
+Nix implements references to store objects as *store path base names*.
+
+Think of a store path base name as an [opaque], [unique identifier]:
+The only way to obtain a store path base name is by adding or building store objects.
+A store path base name will always reference exactly one store object.
 
 [opaque]: https://en.m.wikipedia.org/wiki/Opaque_data_type
 [unique identifier]: https://en.m.wikipedia.org/wiki/Unique_identifier
 
-Store paths are pairs of
+Store path base names are pairs of
 
 - A 20-byte digest for identification
 - A symbolic name for people to read
@@ -25,48 +34,96 @@ Store paths are pairs of
 > - Digest: `b6gvzjyb2pg0kjfwrjmg1vfhh54ad73z`
 > - Name:   `firefox-33.1`
 
-To make store objects accessible to operating system processes, stores have to expose store objects through the file system.
-
-A store path is rendered to a file system path as the concatenation of
+A store path base name is rendered to a string as the concatenation of
 
-- [Store directory](#store-directory) (typically `/nix/store`)
-- Path separator (`/`)
-- Digest rendered in a custom variant of [Base32](https://en.wikipedia.org/wiki/Base32) (20 arbitrary bytes become 32 ASCII characters)
+- Digest rendered in a custom variant of [Base32] (20 arbitrary bytes become 32 ASCII characters)
 - Hyphen (`-`)
 - Name
 
 > **Example**
 >
 > ```
->   /nix/store/b6gvzjyb2pg0kjfwrjmg1vfhh54ad73z-firefox-33.1
->   |--------| |------------------------------| |----------|
-> store directory            digest                 name
+> b6gvzjyb2pg0kjfwrjmg1vfhh54ad73z-firefox-33.1
+> |------------------------------| |----------|
+>               digest                 name
 > ```
 
-Exactly how the digest is calculated depends on the type of store path.
+[Base32]: https://en.wikipedia.org/wiki/Base32
+
+Exactly how the digest is calculated depends on the type of store object being referenced.
 Store path digests are *supposed* to be opaque, and so for most operations, it is not necessary to know the details.
 That said, the manual has a full [specification of store path digests](@docroot@/protocols/store-path.md).
 
-## Store Directory
-
-Every [Nix store](./index.md) has a store directory.
-
-Not every store can be accessed through the file system.
-But if the store has a file system representation, the store directory contains the store’s [file system objects], which can be addressed by [store paths](#store-path).
+## Store Directory Path
 
-[file system objects]: ./file-system-object.md
+Every [Nix store] has a store directory path.
+This is an absolute, lexically canonical (not containing any `..`, `.`, or similar) path which points to the directory where all store objects are to be found.
 
-This means a store path is not just derived from the referenced store object itself, but depends on the store that the store object is in.
+[Nix store]: ./index.md
 
 > **Note**
 >
 > The store directory defaults to `/nix/store`, but is in principle arbitrary.
 
-It is important which store a given store object belongs to:
+## Store Path
+
+A store path is the pair of a store directory path and a [store path base name].
+It is rendered to a file system path as the concatenation of
+
+- [Store directory] (typically `/nix/store`)
+- Path separator (`/`)
+- The [store path base name]
+
+> **Example**
+>
+> ```
+>   /nix/store/b6gvzjyb2pg0kjfwrjmg1vfhh54ad73z-firefox-33.1
+>   |--------| |------------------------------| |----------|
+> store directory            digest                 name
+> ```
+
+When we have fixed a given store, or given store directory path (that all the stores in use share), the abstract syntax for store paths and the abstract syntax for store path base names coincide: the store directory path is known from context, so only the other two fields vary from one store path to the next.
+
+## Exposing Store Objects in OS File Systems {#exposing}
+
+Not every store can be accessed through the file system.
+But if the store has a file system representation, the following should be true:
+
+- The store directory path is canonical: no prefix of the path (i.e. path of the first *n* path segments) points to a symlink.
+  (This is a separate condition in addition to "lexical canonicity", which is a property of just the path itself, whereas regular "canonicity" is an additional property about the path and the filesystem it navigates jointly.)
+
+- The store directory path in fact points to a directory.
+
+- The store directory contains, for every store object in the store, the [file system object] of that store object at the (rendered) [store path base name].
+  The permissions and other metadata for these files in the store directory is in the normal form described in [Exposing in OS file systems](./file-system-object/os-file-system.md).
+
+The above properties mean that the following file accesses will work.
+Suppose we have a store available on the file system per the above rules, and `b6gvzjyb2pg0kjfwrjmg1vfhh54ad73z-firefox-33.1` is the store path base name of a store object in that store.
+
+- Suppose that the store directory (path) is `/foo/bar`.
+  Then, `/foo/bar/b6gvzjyb2pg0kjfwrjmg1vfhh54ad73z-firefox-33.1` exists and is the file system object of that store object.
+
+- Suppose that we don't know what the store directory path of the store is, but we do have a capability `storeDir` to the store directory on the file system.
+  (This would be a "file descriptor" on Unix, or a "file handle" on Windows.)
+  Then (using the Unix notation for this):
+  ```
+  openat(storeDir, "b6gvzjyb2pg0kjfwrjmg1vfhh54ad73z-firefox-33.1", O_NOFOLLOW)
+  ```
+  will succeed (so long as the file system object is not a symlink), and the yielded capability will point to the file system object of that store object.
+
+  (The behavior for symlinks is harder to specify because of limitations in POSIX.)
+
+## Relocating store objects
+
+The inclusion of the store directory path in the full rendered store path means that it is not just derived from the referenced store object itself, but depends on the store that the store object is in.
+(And actually, many of the ways of computing the digest also depend on the store directory path.
+So this is also true even just for store path base names, in general.)
+
+It is therefore important to consider which store a given store object belongs to:
 Files in the store object can contain store paths, and processes may read these paths.
 Nix can only guarantee referential integrity if store paths do not cross store boundaries.
 
-Therefore one can only copy store objects to a different store if
+One can only copy store objects to a different store if
 
 - The source and target stores' directories match
 
diff --git a/src/libstore/include/nix/store/globals.hh b/src/libstore/include/nix/store/globals.hh
index 89e92d30e44..d46c7d69383 100644
--- a/src/libstore/include/nix/store/globals.hh
+++ b/src/libstore/include/nix/store/globals.hh
@@ -189,7 +189,7 @@ public:
         0,
         "cores",
         R"(
-          Sets the value of the `NIX_BUILD_CORES` environment variable in the [invocation of the `builder` executable](@docroot@/store/building.md#builder-execution) of a derivation.
+          Sets the value of the `NIX_BUILD_CORES` environment variable in the [invocation of the `builder` executable](@docroot@/store/building.md#env-vars) of a derivation.
           The `builder` executable can use this variable to control its own maximum amount of parallelism.
 
           <!--