Merge PR #1957: Finalize Volume I layout for full PDF draft

# Conflicts:
#	book/quarto/contents/vol1/ml_ops/ml_ops.qmd

Author: profvjreddi

book/quarto/contents/vol1/backmatter/appendix_dam.qmd

@@ -228,7 +228,7 @@ To move beyond qualitative guessing, the efficiency ratios in @tbl-dam-scorecard
 
 ```{=latex}
 \begingroup
-\renewcommand{\arraystretch}{2.5}
+\renewcommand{\arraystretch}{3}
 ```
 
 | **Axis**      | **Metric**        |                       **Definition**                       | **Failing Grade** | **Passing Grade** |

book/quarto/contents/vol1/backmatter/glossary/glossary.qmd

@@ -10,6 +10,17 @@ This glossary defines key terms used throughout this book and gathers them as a
 ```{=latex}
 \scriptsize\sloppy
 \setlength{\parskip}{1pt plus 0.5pt}
+\setlist[description]{
+  style=unboxed,
+  leftmargin=1.4em,
+  itemindent=-1.4em,
+  labelindent=0pt,
+  labelsep=0.5em,
+  font=\normalfont\bfseries,
+  itemsep=2pt,
+  parsep=0pt,
+  topsep=0pt
+}
 \begin{multicols}{3}
 ```
 
@@ -841,7 +852,7 @@ This glossary defines key terms used throughout this book and gathers them as a
 **Kolmogorov-Smirnov test (K-S test)**
 : A nonparametric test that measures the maximum distance between two cumulative distributions, often used to compare feature distributions for drift.
 
-**Kullback-Leibler divergence (KL divergence)**
+Kullback-Leibler divergence (KL divergence)
 : An asymmetric information-theoretic measure of how one probability distribution differs from another, used in monitoring and drift analysis.
 
 **KV cache**

book/quarto/contents/vol1/benchmarking/benchmarking.qmd

@@ -2264,6 +2264,11 @@ With perfect scaling, `{python} ScalingEfficiencyCalc.n_gpus_str` would complete
 
 **Step 3**: Account for the efficiency loss. @Tbl-benchmarking-scaling-efficiency-loss decomposes the "missing" `{python} ScalingEfficiencyCalc.loss_str` into measurable overhead categories—gradient synchronization, memory copy, load imbalance, and batch-size effects—each measurable through a distinct profiling signal.
 
+```{=latex}
+\begingroup
+\renewcommand{\arraystretch}{1.3}
+```
+
 | **Source**                   | **Example Contribution** | **Measurement**                     |
 |:-----------------------------|:------------------------:|:------------------------------------|
 | **Gradient synchronization** |          10-15%          | AllReduce time per step             |
@@ -2273,6 +2278,10 @@ With perfect scaling, `{python} ScalingEfficiencyCalc.n_gpus_str` would complete
 
 : **Scaling Efficiency Loss Sources**: Illustrative decomposition of the missing efficiency budget into measurable overhead categories and the corresponding measurement signal used to attribute each loss. Actual percentages depend on model, interconnect, storage, batch schedule, and framework implementation. {#tbl-benchmarking-scaling-efficiency-loss}
 
+```{=latex}
+\endgroup
+```
+
 **Step 4**: The systems insight.
 <!-- lego-ok-block: typical strong-scaling efficiency ranges at different GPU counts -->
 Scaling efficiency decreases as $N_{\text{GPU}}$ grows because communication overhead scales with GPU count while per-GPU compute shrinks. In this worked example, eight GPUs reach 75 percent efficiency; at larger scales, the same arithmetic makes clear why sophisticated communication and input-pipeline optimization become necessary.
@@ -2699,15 +2708,15 @@ These metrics interact through unavoidable trade-offs. Optimizing for high throu
 
 Deployment scenario determines the priority order among those metrics. The operational constraints and success criteria vary dramatically across contexts, so metric priorities help engineers focus benchmarking effort and interpret results within the right decision framework. @Tbl-metric-priorities illustrates how performance priorities shift across five major deployment contexts, revealing the systematic relationship between operational constraints and optimization targets.
 
-| **Deployment Context**     | **Primary Priority**  | **Secondary Priority** | **Tertiary Priority** | **Key Design Constraint**                         |
-|:---------------------------|:----------------------|:-----------------------|:----------------------|:--------------------------------------------------|
-| **Real-Time Applications** | Latency (p95 < 50 ms) | Reliability (99.9%)    | Memory Footprint      | User experience demands immediate response        |
-| **Cloud-Scale Services**   | Throughput (QPS)      | Cost Efficiency        | Average Latency       | Business viability requires massive scale         |
-| **Edge/Mobile Devices**    | Power Consumption     | Memory Footprint       | Latency               | Battery life and resource limits dominate         |
-| **Training Workloads**     | Training Time         | GPU Utilization        | Memory Efficiency     | Research velocity enables faster experimentation  |
-| **Scientific/Medical**     | Accuracy              | Reliability            | Explainability        | Correctness cannot be compromised for performance |
+| **Deployment Context**     | **Primary Priority** | **Secondary Priority** | **Tertiary Priority** | **Key Design Constraint**                         |
+|:---------------------------|:---------------------|:-----------------------|:----------------------|:--------------------------------------------------|
+| **Real-Time Applications** | Latency (p95 < 50 ms)| Reliability (99.9%)    | Memory Footprint      | User experience demands immediate response        |
+| **Cloud-Scale Services**   | Throughput (QPS)     | Cost Efficiency        | Average Latency       | Business viability requires massive scale         |
+| **Edge/Mobile Devices**    | Power Consumption    | Memory Footprint       | Latency               | Battery life and resource limits dominate         |
+| **Training Workloads**     | Training Time        | GPU Utilization        | Memory Efficiency     | Research velocity enables faster experimentation  |
+| **Scientific/Medical**     | Accuracy             | Reliability            | Explainability        | Correctness cannot be compromised for performance |
 
-: **Performance Metric Priorities by Deployment Context**: Different operational environments demand distinct optimization focuses, reflecting varying constraints and success criteria. These priorities guide both benchmark selection and result interpretation. {#tbl-metric-priorities tbl-colwidths="[18,16,20,18,28]"}
+: **Performance Metric Priorities by Deployment Context**: Different operational environments demand distinct optimization focuses, reflecting varying constraints and success criteria. These priorities guide both benchmark selection and result interpretation. {#tbl-metric-priorities tbl-colwidths="[18,19,18,17,28]"}
 
 The key insight from @tbl-metric-priorities is that the same metric can be primary in one context and irrelevant in another. Latency ranks first for real-time applications (autonomous vehicles must process sensor data within strict timing deadlines) but tertiary for cloud services (which accept higher latency in exchange for cost efficiency per query). A smartphone AI assistant that improves throughput by 50 percent but increases power consumption by 30 percent represents a net regression since battery life directly impacts user satisfaction. Medical diagnostic systems prioritize accuracy as nonnegotiable—achieving 99.2 percent accuracy at 10 ms latency provides superior value compared to 98.8 percent at 5 ms. This context-dependence means that a 2$\times$ throughput improvement represents substantial value for cloud deployments but minimal benefit for battery-powered edge devices, where 20 percent power reduction delivers superior operational impact.
 

book/quarto/contents/vol1/conclusion/conclusion.qmd

@@ -95,6 +95,9 @@ The Lighthouse Models now become a constraint map for reasoning about ML systems
 
 The five Lighthouse Models\index{Lighthouse Model!bottleneck probe} introduced in @sec-introduction-iron-law-ml-systems-c32a made this constraint propagation concrete, serving as systems detectives throughout the book. Each revealed how different workloads expose different bottlenecks.
 
+```{=latex}
+\newpage
+```
 The five Lighthouse workloads expose distinct constraint regimes:
 
 - **ResNet-50**: Batch size can turn image inference from a memory-bound path into compute-bound throughput.

book/quarto/contents/vol1/data_engineering/data_engineering.qmd

@@ -422,7 +422,7 @@ Text2/.style={align=left,anchor=north west,font=\footnotesize\usefont{T1}{phv}{m
 \fill[black] (P\i) circle (2pt);
   }
 
-\draw[LineD,Red](P0)to[out=60,in=120](P6);
+\draw[LineD,Red,overlay](P0)to[out=60,in=120](P6);
 \draw[LineD,Red](P0)to[out=60,in=125](P5);
 \draw[LineD,Blue](P1)to[out=60,in=120](P6);
 \draw[LineD,Red](P1)to[out=50,in=125](P6);
@@ -1428,14 +1428,14 @@ pics/globe/.style = {
 %%%%%%%%%%%%%%%%%%
 \node[Box2,below=1.85 of B1](B2){};
 \draw[mygreen,  line width=2.75pt](B2.south west)--coordinate[pos=0.5](SR2)(B2.south east);
-\node[Box2,right= of B2](B3){};
+\node[Box2,right= 1.4 of B2](B3){};
 \draw[mygreen,  line width=2.75pt](B3.south west)--coordinate[pos=0.5](SR3)(B3.south east);
-\node[Box2,right= of B3](B4){};
+\node[Box2,right=1.4  of B3](B4){};
 \draw[mygreen,  line width=2.75pt](B4.south west)--coordinate[pos=0.5](SR4)(B4.south east);
 %
-\node[Box2,left= of B2](B5){};
+\node[Box2,left=1.4  of B2](B5){};
 \draw[mygreen,  line width=2.75pt](B5.south west)--coordinate[pos=0.5](SR5)(B5.south east);
-\node[Box2,left= of B5](B6){};
+\node[Box2,left=1.4  of B5](B6){};
 \draw[mygreen,  line width=2.75pt](B6.south west)--coordinate[pos=0.5](SR6)(B6.south east);
 
 \foreach \i  [count=\k from 2] in {C,D,E,B,A}{
@@ -1562,49 +1562,6 @@ Just as systems engineers memorize latency numbers, ML engineers should internal
 
 @Tbl-data-engineering-time-constants extends the picture with characteristic durations for labeling, training, and serving operations.
 
-```{python}
-#| echo: false
-#| label: data-engineering-time-constants-calc
-# ┌─────────────────────────────────────────────────────────────────────────────
-# │ DATA ENGINEERING TIME CONSTANTS SPAN
-# ├─────────────────────────────────────────────────────────────────────────────
-# │ Context: @tbl-data-engineering-time-constants caption
-# │
-# │ Goal: Compute the order-of-magnitude span shown in the table.
-# │ Show: Labeling weeks vs. feature-lookup milliseconds spans about 9 orders.
-# │ How: Compare the slowest listed labeling bound with the fastest lookup bound.
-# │
-# └─────────────────────────────────────────────────────────────────────────────
-from math import log10
-from mlsysim.fmt import fmt_int, fmt, fmt_count, check
-
-class DataEngineeringTimeConstants:
-    """Order-of-magnitude span for data-engineering operation durations."""
-
-    # ┌── 1. LOAD (Constants) ──────────────────────────────────────────────
-    fastest_lookup_s = 0.001
-    slowest_labeling_weeks = 4
-    seconds_per_week = 7 * 24 * 60 * 60
-
-    # ┌── 2. EXECUTE (The Compute) ────────────────────────────────────────
-    slowest_labeling_s = slowest_labeling_weeks * seconds_per_week
-    span_ratio = slowest_labeling_s / fastest_lookup_s
-    span_orders = log10(span_ratio)
-
-    # ┌── 3. GUARD (Invariants) ───────────────────────────────────────────
-    check(span_orders > 9, f"Time constants should span more than 9 orders, got {span_orders:.2f}.")
-
-    # ┌── 4. OUTPUT (Formatting) ──────────────────────────────────────────
-    span_orders_str = fmt_int(span_orders, commas=False)
-```
-
-| **Operation**                      | **Duration** | **Bottleneck**                      |
-|:-----------------------------------|:------------:|:------------------------------------|
-| **Label 1M images (crowdsourced)** |  2–4 weeks   | Annotation throughput               |
-| **Train ResNet-50 on ImageNet**    |  4–6 hours   | Compute (8$\times$ A100, optimized) |
-| **Feature store lookup**           |   1–10 ms    | Network + cache                     |
-
-: **Data Engineering Time Constants**: Characteristic durations for labeling, training, and serving operations span about `{python} DataEngineeringTimeConstants.span_orders_str` orders of magnitude. Human labeling sets the wall-clock floor for new datasets, making it the dominant scheduling constraint in production ML systems. {#tbl-data-engineering-time-constants tbl-colwidths="[40,34,36]"}
 
 ```{python}
 #| echo: false
@@ -1660,6 +1617,51 @@ class LabelingComputeRatio:
 
 The contrast matters: weeks for human labeling, hours for GPU training, milliseconds for serving. Labeling is the bottleneck. It often costs hundreds to more than a thousand times more than a single optimized training run: a `{python} LabelingComputeRatio.labeling_budget_str` labeling budget compares with `{python} LabelingComputeRatio.train_cost_low_str`--`{python} LabelingComputeRatio.train_cost_high_str` for one 8$\times$ A100 ResNet-50 run, a `{python} LabelingComputeRatio.ratio_low_mult_str`--`{python} LabelingComputeRatio.ratio_high_mult_str` ratio. Within that labeling spend, the effort distribution itself is skewed: `{python} LabelingComputeRatio.effort_majority_pct_str` of the work goes to `{python} LabelingComputeRatio.effort_minority_pct_str` of features—the long tail of edge cases, rare categories, and quality exceptions.
 
+```{python}
+#| echo: false
+#| label: data-engineering-time-constants-calc
+# ┌─────────────────────────────────────────────────────────────────────────────
+# │ DATA ENGINEERING TIME CONSTANTS SPAN
+# ├─────────────────────────────────────────────────────────────────────────────
+# │ Context: @tbl-data-engineering-time-constants caption
+# │
+# │ Goal: Compute the order-of-magnitude span shown in the table.
+# │ Show: Labeling weeks vs. feature-lookup milliseconds spans about 9 orders.
+# │ How: Compare the slowest listed labeling bound with the fastest lookup bound.
+# │
+# └─────────────────────────────────────────────────────────────────────────────
+from math import log10
+from mlsysim.fmt import fmt_int, fmt, fmt_count, check
+
+class DataEngineeringTimeConstants:
+    """Order-of-magnitude span for data-engineering operation durations."""
+
+    # ┌── 1. LOAD (Constants) ──────────────────────────────────────────────
+    fastest_lookup_s = 0.001
+    slowest_labeling_weeks = 4
+    seconds_per_week = 7 * 24 * 60 * 60
+
+    # ┌── 2. EXECUTE (The Compute) ────────────────────────────────────────
+    slowest_labeling_s = slowest_labeling_weeks * seconds_per_week
+    span_ratio = slowest_labeling_s / fastest_lookup_s
+    span_orders = log10(span_ratio)
+
+    # ┌── 3. GUARD (Invariants) ───────────────────────────────────────────
+    check(span_orders > 9, f"Time constants should span more than 9 orders, got {span_orders:.2f}.")
+
+    # ┌── 4. OUTPUT (Formatting) ──────────────────────────────────────────
+    span_orders_str = fmt_int(span_orders, commas=False)
+```
+
+| **Operation**                      | **Duration** | **Bottleneck**                      |
+|:-----------------------------------|:------------:|:------------------------------------|
+| **Label 1M images (crowdsourced)** |  2–4 weeks   | Annotation throughput               |
+| **Train ResNet-50 on ImageNet**    |  4–6 hours   | Compute (8$\times$ A100, optimized) |
+| **Feature store lookup**           |   1–10 ms    | Network + cache                     |
+
+: **Data Engineering Time Constants**: Characteristic durations for labeling, training, and serving operations span about `{python} DataEngineeringTimeConstants.span_orders_str` orders of magnitude. Human labeling sets the wall-clock floor for new datasets, making it the dominant scheduling constraint in production ML systems. {#tbl-data-engineering-time-constants tbl-colwidths="[40,34,36]"}
+
+
 All cost figures reflect approximate 2024 cloud provider rates and are intended to convey relative magnitudes rather than exact pricing.[^fn-pricing-cost-ratios] The consistent pattern across these numbers is that human labor (labeling, annotation, expert review) dominates hardware and storage costs by one to three orders of magnitude. A team that optimizes its labeling pipeline before scaling compute or storage addresses the largest cost term first.
 
 ```{python}