build step -> build rule

"step" sounds atomic, while "rule" hints at internal structure, which in
our case consists of mapping inputs to outputs using build instructions.

1 files changed, 4 insertions, 3 deletions

diff --git a/doc/manual/src/architecture/architecture.md b/doc/manual/src/architecture/architecture.md
index a0aa713f3..81348c570 100644
--- a/doc/manual/src/architecture/architecture.md
+++ b/doc/manual/src/architecture/architecture.md
@@ -27,7 +27,7 @@ Nix consists of hierarchical [layers](https://en.m.wikipedia.org/wiki/Multitier_
 At the top is the *command line interface*, translating from invocations of Nix executables to interactions with the underlying layers.
 
 Below that is the *Nix language*, a [purely functional](https://en.m.wikipedia.org/wiki/Purely_functional_programming) configuration language.
-It is used to compose expressions which ultimately evaluate to self-contained *build plans*, used to derive *build results* from referenced *build inputs*.
+It is used to compose expressions which ultimately evaluate to self-contained *build rules*, used to derive *build results* from referenced *build inputs*.
 
 ::: {.note}
 The Nix language itself does not have a notion of *packages* or *configurations*.
@@ -37,6 +37,7 @@ In practice this amounts to a set of files in a file system.
 
 The command line and Nix language are what users interact with most.
 
-Underlying everything is the *Nix store*, a mechanism to keep track of build plans, data, and references between them.
-It can also execute *build instructions*, captured in the build plans, to produce new data.
+Underlying everything is the *Nix store*, a mechanism to keep track of build rules, data, and references between them.
+It can also execute *build instructions*, captured in the build rules, to produce new data.
 
+A series of build rules is a *build plan*.