Three batch case studies for the Applications chapter (DuPont batch PCA, SBR batch PLS, FMC multiblock batch PLS)

.github/workflows/check-code.yml

@@ -15,6 +15,11 @@ name: Check book code
 # It is a gate rather than advisory: if that pair stops resolving, the install
 # instructions the chapter gives its readers no longer work, which is a book
 # problem worth failing on.
+#
+# The whole chapter runs in that environment, so it needs every extra the
+# chapter's other pages use as well: the batch case studies read their data from
+# openmv.net workbooks, and the Excel reader lives in the [batch] extra. Neither
+# extra pins plotly, so the pair still resolves against pyoptex's plotly 5.
 
 on:
   push:
@@ -154,5 +159,5 @@ jobs:
         run: |
           make check-code-chapter \
             CHAPTER=product-development-product-improvement \
-            CHECK_WITH='process-improve[expt]' \
+            CHECK_WITH='process-improve[expt,batch]' \
             CHECK_ALSO=pyoptex

CITATION.cff

@@ -22,8 +22,8 @@ keywords:
   - multivariate data analysis
   - batch data analysis
 license: CC-BY-SA-4.0
-version: "2026.09.08"
-date-released: 2026-09-08
+version: "2026.09.10"
+date-released: 2026-09-10
 repository-code: "https://github.com/kgdunn/pid-book"
 url: "https://learnche.org/pid"
 identifiers:

CLAUDE.md

@@ -79,10 +79,68 @@ same edits do not have to be made again.
 - Do not refer to a table or figure before it appears in the text. If a
   forward reference is unavoidable, point to it explicitly as "below".
 
+**Length and focus**
+
+- Say it once, briefly. A passage that restates what a figure, a caption
+  or a printed result already shows is cut, not trimmed. A first draft of
+  a paragraph is usually two to five times too long; keep the claim, its
+  reason and its consequence, and stop.
+- Do not repeat numbers the reader can read off a plot or a table. Quote a
+  number only when it is not on a figure (an average over several curves,
+  the sample at which a curve crosses a threshold), and print it in the
+  code with the value echoed in a comment, so the checker verifies it.
+- Explain a principle in general terms and keep case-specific numbers for
+  the results. "The early estimates scatter more widely than the final
+  scores" belongs in the explanation; "fourteen times more after four
+  samples" does not.
+- Use bullets for a sequence of steps or a set of parallel facts, and do
+  not dive into detail inside them.
+- Cut method history, alternative methods and "prior experience" asides
+  that the point does not need. The book is self-contained: never refer to
+  course notes or other material the reader does not have.
+- One metric where one will do (the leave-one-batch-out RMSEP, not RMSEE
+  and RMSEP side by side).
+- After describing a result, state its practical value in one or two
+  sentences, with the number that carries it, then stop.
+
+**Paragraph construction**
+
+- One idea per paragraph: claim, reason, consequence. Do not splice a
+  second idea on with a colon or a semicolon.
+- Keep the example fixed inside an argument: not "ten samples" in one
+  sentence and "four samples" in the next for the same point.
+- Reconcile statements a careful reader would set against each other (a
+  list that "is not used to build the model" while its batches sit in the
+  training set): say precisely what is used, and for what.
+- A heading says what the section does for the reader ("The final model,
+  used to verify the unusual batches detected above"), not its topic.
+
+**Figures and captions**
+
+- Every score plot carries the percent of variance explained per component
+  on its axes, in square brackets.
+- Annotate on the figure the thing the text discusses: an arrow for a
+  contribution direction, with a marker at its origin; a batch marked and
+  labelled when a later section uses it. Keep annotation text small.
+- Markers must read on every background they cross (white face and dark
+  edge on top of bars). Labels never sit on other points: move them to the
+  other side of the marker, or onto a short leader line. Legends go where
+  the data are not.
+- Beside a derived statistic, show the raw data (raw trajectories in a 2x2
+  panel beside contribution bars) rather than a second derived panel.
+- Integer axis ticks for integer-like quantities; a band of one error, not
+  two, unless the text says why.
+- A caption says what the reader should see and what it means ("Dots help
+  show how consistent each batch in the cluster is with the group").
+- When the text claims that a quantity behaves in a certain way, show it
+  in a figure.
+
 **Process**
 
 - When a wording or style fix may recur elsewhere in the file, ask before
   changing the other occurrences rather than assuming.
+- For content edits, run `make text` and the code checker; do not run
+  `make html` or rebuild a review rendering unless asked.
 
 ## Every Python case in the book runs in CI
 
@@ -110,10 +168,12 @@ The contract, which any new or edited code must satisfy:
   moves with it; do not paper over the warning.
 - **Echoed results are checked, and a mismatch fails.** A comment right after a
   `print(...)` that repeats its output (`# [0.255, 0.367, ...]`) is compared with
-  what the block printed. `make check-code` and CI run with `--strict-output`, so
-  a number that stops reproducing fails the chapter even though the code still
-  runs; the bare CLI reports mismatches without failing, which is easier to work
-  through when several are in flight. Use this idiom for every number the prose
+  what the block printed. Every `make check-code…` target and CI run with
+  `--strict-output`, so a number that stops reproducing fails the chapter even
+  though the code still runs, and a per-chapter or per-file run is as trustworthy
+  as the full one; invoking `tools/check_code_blocks.py` directly without the flag
+  reports mismatches without failing, which is easier to work through when several
+  are in flight. Use this idiom for every number the prose
   then quotes. Print the value in the shape the comment claims: a dict repr drops
   a trailing zero, and a Series or array repr carries full precision, so
   `print(f"{value:.2f}")` beats `print(value)` when the prose quotes two decimals.

Makefile

@@ -89,10 +89,10 @@ check-code:	## Execute every Python case in the book (all chapters in parallel)
 	$(CHECK_RUN) pytest tests -n auto
 
 check-code-chapter:	## One chapter, verbose: make check-code-chapter CHAPTER=least-squares-modelling
-	$(CHECK_RUN) python tools/check_code_blocks.py --chapter $(CHAPTER) -v
+	$(CHECK_RUN) python tools/check_code_blocks.py --chapter $(CHAPTER) --strict-output -v
 
 check-code-file:	## One RST file, run after the files that precede it in its chapter
-	$(CHECK_RUN) python tools/check_code_blocks.py --file $(FILE) -v
+	$(CHECK_RUN) python tools/check_code_blocks.py --file $(FILE) --strict-output -v
 
 html:
 	$(SPHINXBUILD) -b html $(ALLSPHINXOPTS) $(BUILDDIR)/html

latent-variable-modelling/principal-component-analysis/latent-variable-contribution-plots.rst

@@ -1,3 +1,5 @@
+.. _LVM_contribution_plots:
+
 Latent variable contribution plots
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 

latent-variable-modelling/projection-to-latent-structures/pls-model-inversion-and-the-orthogonal-space.rst

@@ -493,7 +493,7 @@ How well is that direction determined?
 
 This is the caveat promised earlier. Every number quoted so far comes from one model fitted to 26
 cheeses, and the direction of the null
-space rests on the second :math:`y`-loading, :math:`q_2 = -0.262`. That component was the one
+space is set by the second :math:`y`-loading, :math:`q_2 = -0.262`. That component was the one
 cross-validation did not keep. It adds 3.0% to :math:`R^2Y`, against 64.3% for the first. It is worth
 asking how much of the geometry survives if the 26 cheeses had come out slightly differently.
 
@@ -998,8 +998,8 @@ deviation is a distance in the input space, measured between the two recipes the
 Reading down the :math:`T^2` of the design, the moderate tastes near the middle of the calibration
 range give designs with small :math:`T^2`, while the more extreme tastes push the design further from
 the data: asking for a taste of 47.9 gives the largest value, 4.82. A large :math:`T^2` does not make
-a design wrong, but it flags that the model is extrapolating and that the predicted taste rests on
-less support from the data.
+a design wrong, but it flags that the model is extrapolating and that less data stand behind
+the predicted taste.
 All four are well inside the 99% limit of 12.14.
 
 The input-space deviation compares each design with the cheese that actually had that taste. Cheese 2 is