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.

2 files changed, 7 insertions, 6 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*.
diff --git a/doc/manual/src/architecture/store/store.md b/doc/manual/src/architecture/store/store.md
index cbb5a4169..b03aa690e 100644
--- a/doc/manual/src/architecture/store/store.md
+++ b/doc/manual/src/architecture/store/store.md
@@ -2,10 +2,10 @@
 
 A Nix store is a collection of [store objects](objects.md) with associated operations.
 
-These store objects can hold arbitrary data, and Nix makes no distinction if they are used as build inputs, build results, or build plans.
+These store objects can hold arbitrary data, and Nix makes no distinction if they are used as build inputs, build results, or build rules.
 
 A Nix store allows adding, retrieving, and deleting store objects.
-It can perform builds, that is, transform build inputs using instructions from the build plans into build outputs.
+It can perform builds, that is, transform build inputs using instructions from the build rules into build outputs.
 It also keeps track of *references* between data and can therefore garbage-collect unused store objects.
 
 There exist different types of stores, which all follow this model.
@@ -28,7 +28,7 @@ generic build system | Nix | [Bazel](https://bazel.build/start/bazel-intro) | [B
 -- | -- | -- | -- | --
 data (build input, build result) | store object | [artifact](https://bazel.build/reference/glossary#artifact) | value | value
 build instructions | builder | ([depends on action type](https://docs.bazel.build/versions/main/skylark/lib/actions.html)) | function | function
-build step | derivation | [action](https://bazel.build/reference/glossary#action) | `Task` | [thunk](https://en.m.wikipedia.org/wiki/Thunk)
+build rule | derivation | [action](https://bazel.build/reference/glossary#action) | `Task` | [thunk](https://en.m.wikipedia.org/wiki/Thunk)
 build plan | derivation graph | [action graph](https://bazel.build/reference/glossary#action-graph), [build graph](https://bazel.build/reference/glossary#build-graph) | `Tasks` | [call graph](https://en.m.wikipedia.org/wiki/Call_graph)
 build | build | build | application of `Build` | evaluation
 persistence layer | store | [action cache](https://bazel.build/reference/glossary#action-cache) | `Store` | heap