Remove research-questions callouts, fix ml_ops cascade figure, standardize figure font

Builds on the PR #1957 merge (Zeljko's Vol1 layout), otherwise byte-for-byte his version:

- Remove the end-of-chapter research-questions callouts from all chapters.
- ml_ops correction-cascade figure: keep Zeljko's Model A-D chain TikZ drawing,
  and rewrite the caption, alt-text, and lead-in to describe the chain (they
  carried a stale 'timeline' description that no longer matched the figure),
  plus an operations-impact line.
- Standardize the matplotlib figure font on a bundled TeX Gyre Heros (a free,
  redistributable Helvetica-metric clone) registered at runtime in
  book/tools/figures/style.py, so figures render with a real bold identically
  on macOS, Linux, and CI instead of falling back to DejaVu Sans or an
  unreachable macOS .ttc bold face.

Author: profvjreddi

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

@@ -4720,15 +4720,6 @@ What does a system that passes every benchmark fail to predict? Production reali
 
 <!-- This is here to make sure that quizzes are inserted properly before a part begins. -->
 
-::: {.callout-research-questions title="For further inquiry"}
-
-* What benchmark protocol makes comparisons fair across different hardware, models, data, and deployment assumptions?
-* When should micro, macro, and end-to-end benchmarks be combined, and what does each hide?
-* Which metric set prevents single-metric gaming across latency, tail latency, throughput, energy, accuracy, and calibration?
-* How should teams anticipate benchmark-production gaps from drift, dynamic load, thermal throttling, and input variation?
-
-:::
-
 ::: { .quiz-end }
 :::
 

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

@@ -1077,15 +1077,6 @@ The next frontier is scale. The same discipline of quantifying constraints and t
 \endgroup
 ```
 
-::: {.callout-research-questions title="For further inquiry"}
-
-* How does one deployment decision propagate across data, architecture, compression, hardware, serving, operations, and governance?
-* How does conservation of complexity explain why a local optimization becomes another layer's constraint?
-* Which quantitative invariants should be measured first when diagnosing a new ML system?
-* When a system boundary moves from one node to a fleet, which single-machine principles remain valid and which variables change?
-
-:::
-
 ::: { .quiz-end }
 :::
 

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

@@ -4748,15 +4748,6 @@ The dataset compiler has produced its output: a clean, versioned, optimized trai
 
 :::
 
-::: {.callout-research-questions title="For further inquiry"}
-
-* How does treating data as source code change acquisition, splitting, versioning, testing, and review?
-* How should quality, reliability, scalability, and governance be balanced in a keyword-spotting pipeline?
-* What pipeline architecture choices prevent training-serving skew, and what evidence would reveal skew in production?
-* When are more labels, scraped examples, or synthetic samples no longer worth their cost or governance risk?
-
-:::
-
 ::: { .quiz-end }
 :::
 

book/quarto/contents/vol1/data_selection/data_selection.qmd

@@ -4714,15 +4714,6 @@ With high-quality data in hand, we have optimized the source of the system. Even
 
 <!-- This is here to make sure that quizzes are inserted properly before a part begins. -->
 
-::: {.callout-research-questions title="For further inquiry"}
-
-* When can a curated subset outperform the full dataset, and what evidence separates learning signal from redundancy?
-* How should ICR and the selection inequality govern whether to use deduplication, coreset selection, or active learning?
-* What validation protocol prevents synthetic data from replacing the real distribution it is meant to supplement?
-* How should teams choose data-selection investments for data-starved versus compute-starved projects?
-
-:::
-
 ::: { .quiz-end }
 :::
 

book/quarto/contents/vol1/frameworks/frameworks.qmd

@@ -4746,14 +4746,5 @@ Frameworks are the software substrate that translates abstract architectures int
 
 :::
 
-::: {.callout-research-questions title="For further inquiry"}
-
-* How should a project choose between eager execution, graph execution, and compilation when debugging speed and production throughput conflict?
-* When does compilation overhead outweigh kernel-fusion or graph-optimization benefits?
-* How should automatic differentiation systems balance activation storage, recomputation, and gradient correctness?
-* Which framework abstractions are useful because they hide complexity, and which are risky because they hide cost?
-
-:::
-
 ::: { .quiz-end }
 :::

book/quarto/contents/vol1/hw_acceleration/hw_acceleration.qmd

@@ -5928,14 +5928,5 @@ We have now optimized the full D·A·M stack: data selection minimized training
 
 An accelerator is easy to mistake for a faster computer. It is better understood as a machine built to move less data per useful operation, because the cost it fights is fixed by physics; moving a byte takes far more time and energy than computing on it. Every technique in this chapter (tiling, kernel fusion, the memory hierarchy, the systolic array) exists to raise arithmetic intensity, the ratio of computation to data movement, and the roofline is the bookkeeping of that single fact. None of them repeals the cost; they only relocate the bottleneck between bandwidth and compute. This is the machine constraint made concrete: the accelerator cannot make a byte cheaper to move, only ensure that fewer bytes must move for each result worth keeping.
 
-::: {.callout-research-questions title="For further inquiry"}
-
-* How should roofline analysis decide whether to optimize bandwidth, compute, or software overhead?
-* When does specialized hardware fail to outperform a general-purpose alternative?
-* How do tiling, dataflow, and fusion relocate memory-movement cost rather than eliminate it?
-* What evidence should guide accelerator selection across throughput, bandwidth, capacity, energy, cost, and portability?
-
-:::
-
 ::: { .quiz-end }
 :::

book/quarto/contents/vol1/introduction/introduction.qmd

@@ -3321,15 +3321,6 @@ Where should an ML model actually run? Physical laws dictate what is possible. T
 
 :::
 
-::: {.callout-research-questions title="For further inquiry"}
-
-* How should an engineer diagnose whether an ML system failure comes from Data, Algorithm, Machine, or their interaction?
-* When does the bitter lesson stop being sufficient guidance because compute, energy, data, or deployment constraints dominate?
-* How should reliability targets be specified for systems whose behavior is learned from data and can drift after deployment?
-* When is a simpler, less accurate model the better production system once latency, energy, and lifecycle feedback are included?
-
-:::
-
 ::: { .quiz-end }
 :::
 

book/quarto/contents/vol1/ml_ops/ml_ops.qmd

@@ -512,11 +512,137 @@ The primary defense against boundary erosion is architectural: modularity and en
 
 If boundary erosion describes *how* ML systems lose their structural integrity, correction cascades describe *what* happens when teams attempt repairs. A correction cascade\index{Correction Cascade!sequential dependencies} occurs when fixing one component introduces problems elsewhere, requiring additional fixes that themselves cause further problems. In ML systems, these cascades are particularly severe because changes propagate through statistical dependencies rather than explicit code paths. Retraining a model to fix one failure mode may degrade performance on previously working cases. Adjusting thresholds to reduce false positives may increase false negatives. Adding features to address edge cases may introduce correlations that destabilize the entire system. Each correction triggers the need for more corrections, creating a cascade that can consume engineering resources far exceeding the original fix.
 
-@Fig-correction-cascades-flowchart makes the cascade structure visible as a chain of dependent models. Each model is trained to correct the errors of the one before it: model B compensates for model A's residual mistakes, model C compensates for model B's, and so on down the chain. The arrangement holds until an upstream model changes. When model A is retrained to fix one failure mode, every downstream model that was tuned to its previous behavior is invalidated at once, and each must be re-corrected. The red arcs trace this propagation, showing how a repair that looked local reaches across the entire chain.
+@Fig-correction-cascades-flowchart makes the cascade structure visible as a chain of dependent models. Each model is trained to correct the errors of the one before it: model B compensates for model A's residual mistakes, model C compensates for model B's, and so on down the chain. The arrangement holds until an upstream model changes. When model A is retrained to fix one failure mode, every downstream model that was tuned to its previous behavior is invalidated at once, and each must be re-corrected. The red arcs trace this propagation, showing how a repair that looked local reaches across the entire chain. A change near the top forces the most rework, while one near the bottom is nearly free. For an operations team, one change request can trigger a coordinated retraining of the chain.
 
-::: {#fig-correction-cascades-flowchart fig-env="figure" fig-pos="htb" fig-cap="**Correction Cascades**: Each model is trained to correct the errors of the model before it, forming a chain of dependencies. Changing an upstream model invalidates every downstream correction at once, turning one local fix into cascading rework across the chain." fig-alt="Four model boxes in a left-to-right chain labeled Model A through Model D, each trained to correct the previous one. A red change badge on Model A and red dashed arcs reaching Model B, C, and D show an upstream change propagating downstream, with must re-correct labels beneath the downstream models."}
+::: {#fig-correction-cascades-flowchart fig-env="figure" fig-pos="htb" fig-cap="**Correction Cascades**: Each model is trained to correct the errors of the model before it, forming a chain of dependencies. Changing an upstream model invalidates every downstream correction at once, turning one local fix into cascading rework across the chain, with each downstream fix demanding its own retraining cycle." fig-alt="Four model boxes in a left-to-right chain labeled Model A through Model D, each trained to correct the previous one. A red change badge on Model A and red dashed arcs reaching Model B, C, and D show an upstream change propagating downstream, with must re-correct labels beneath the downstream models."}
 
-![](images/svg/correction-cascade-chain.svg)
+```{.tikz}
+\begin{tikzpicture}[font=\small\usefont{T1}{phv}{m}{n}, >=stealth]
+\tikzset{
+Line/.style={line width=0.5pt,black!50,text=black},
+LineA/.style={-{Triangle[width=7pt,length=11pt]},line width=1pt,black!50,text=black},
+LineD/.style={-{Triangle[width=7pt,length=11pt]},crimson,line width=1.5pt,rounded corners=15pt,
+dashed,dash pattern=on 7pt off 5pt},
+Box/.style={align=center, inner xsep=2pt,draw=none, line width=1pt,fill=none,
+minimum width=30mm, minimum height=25mm,node distance=1.0},
+Box1/.style={align=center, inner sep=5pt,draw=none, line width=1pt,fill=crimson,text=white,
+ minimum width=18mm, minimum height=7mm,font=\small\usefont{T1}{phv}{b}{n},rounded corners=7pt},
+Text2/.style={font=\usefont{T1}{phv}{b}{n}\small,align=center},
+Text3/.style={font=\usefont{T1}{phv}{b}{n}\small,align=center,redd},
+}
+\definecolor{redd}{HTML}{A31F34}
+\definecolor{blueeD}{HTML}{4A90C4}
+\definecolor{blueeL}{HTML}{CFE2F3}
+
+%model
+\tikzset{%
+ pics/model/.style = {
+        code = {
+        \pgfkeys{/channel/.cd, #1}
+\begin{scope}[local bounding box=MODEL,scale=\scalefac, every node/.append style={transform shape}]
+\foreach \i in {1,...,3}{
+  \pgfmathsetmacro{\y}{(-\i)*0.37}
+  \node[circle,draw, minimum size=2.5mm,inner sep=0pt,fill=red](2K\i) at(0,\y){};
+}
+\foreach \i in {1,...,3}{
+  \pgfmathsetmacro{\y}{(-\i)*0.37}
+  \node[circle,draw, minimum size=2.5mm,inner sep=0pt,fill=brown](3K\i) at(0.6,\y){};
+}
+\foreach \i in {1,...,2}{
+  \pgfmathsetmacro{\y}{-(3.5-\i)*0.37}
+  \node[circle,draw, minimum size=2.5mm,inner sep=0pt,fill=cyan](1K\i) at(-0.6,\y){};
+}
+\foreach \i in {1}{
+  \pgfmathsetmacro{\y}{-(3.0-\i)*0.37}
+  \node[circle,draw, minimum size=2.5mm,inner sep=0pt,fill=green!40!black](4K\i) at(1.2,\y){};
+}
+\foreach \i in {1,...,2}{
+  \foreach \j in {1,...,3}{
+\draw[Line](1K\i)--(2K\j);
+}}
+\foreach \i in {1,...,3}{
+  \foreach \j in {1,...,3}{
+\draw[Line](2K\i)--(3K\j);
+}}\foreach \i in {1,...,3}{
+  \foreach \j in {1}{
+\draw[Line](3K\i)--(4K\j);
+}}
+ \end{scope}
+     }
+  }
+}
+\pgfkeys{
+  /channel/.cd,
+  scalefac/.store in=\scalefac,
+  scalefac=1,
+}
+
+\begin{scope}[local bounding box=mainfig]
+%Models
+\foreach \name/\x/\title/\subtitle/\picid in {
+  B1/0/{Model A}/{base predictions}/1,
+  B2/5.5/{Model B}/{corrects A}/2,
+  B3/11/{Model C}/{corrects B}/3,
+  B4/16.5/{Model D}/{corrects C}/4
+}{
+  % osnovni box
+  \node[Box] (\name) at (\x,0) {};
+
+  % gornji i donji fill
+  \fill[cyan!07] (\name.north west)
+    rectangle ($( \name.north east)!0.6!(\name.south east)$)
+    coordinate (\name DE);
+
+  \fill[cyan!20] (\name.south east)
+    rectangle ($( \name.north west)!0.6!(\name.south west)$)
+    coordinate (\name LE);
+
+  % spoljašnja linija / border
+  \node[Box,draw=blueeD] at (\name.center) {};
+
+  % tekst u box-u
+  \node[Text2] at ($(\name.south west)!0.5!(\name DE)$)
+    {\title\\
+    \textcolor{black!70}{\usefont{T1}{phv}{m}{n}\subtitle}};
+
+  % koordinata za ikonicu / pic
+  \coordinate (\name Q) at ($(\name.north west)!0.5!(\name DE)$);
+
+  % pic
+  \pic[shift={(-0.3,0.73)}] at (\name Q)
+    {model={scalefac=1.0}};
+}
+%%%
+\foreach \x in {2,3,4}{
+\node[below=3pt of B\x.south,Text3]{must re-correct};
+}
+%
+\draw[LineD](B1.north)--++(0,18.5mm)-|(B4.north);
+\draw[LineD](B1.north)--++(0,14.5mm)-|(B3.north);
+\draw[LineD](B1.north)--++(0,10.5mm)-|(B2.north);
+%
+\node[Box1,above=5pt of B1.north]{change};
+\end{scope}
+
+\draw[LineA](B1)--(B2);
+\draw[LineA](B2)--(B3);
+\draw[LineA](B3)--(B4);
+%
+\node[below =10mm of mainfig.south,font=\small\usefont{T1}{phv}{m}{it},
+black!70]{A single fix to an upstream model forces every
+downstream correction to be redone.};
+
+\coordinate(L1)at($(B2.south)+(-6mm,-12mm)$);
+
+\begin{scope}[local bounding box=MC,shift={($(L1)+(0,0)$)}]
+\node[](LT1) at(L1){correction dependency};
+\draw[LineA](LT1.west)+(180:15mm)--(LT1.west);
+
+\node[right=49mm of LT1](LT2) at(L1){change propagates downstream};
+\draw[LineD](LT2.west)+(180:15mm)--(LT2.west);
+\end{scope}
+\end{tikzpicture}
+```
 
 :::
 
@@ -4024,14 +4150,5 @@ We have built a system that is efficient, scalable, and reliable. A system can a
 
 :::
 
-::: {.callout-research-questions title="For further inquiry"}
-
-* How should an organization detect a model that is fully available but silently wrong?
-* Where should boundaries be drawn to limit correction cascades across data, model, infrastructure, and monitoring?
-* How should retraining triggers balance staleness cost, retraining cost, traffic value, and human oversight?
-* When do feature stores, registries, and CI/CD pipelines become justified infrastructure rather than premature process?
-
-:::
-
 ::: { .quiz-end }
 :::

book/quarto/contents/vol1/ml_systems/ml_systems.qmd

@@ -4357,14 +4357,5 @@ Choosing where a system runs settles its physics; it does not protect it from ti
 
 :::
 
-::: {.callout-research-questions title="For further inquiry"}
-
-* How should physical constraints determine deployment paradigm before model development begins?
-* When should a production system combine cloud, edge, mobile, or TinyML rather than choose one paradigm?
-* How should the iron law guide optimization when the same workload shifts bottlenecks between training and inference?
-* What evidence would show that total cost of ownership, not raw compute cost, determines the feasible deployment?
-
-:::
-
 ::: { .quiz-end }
 :::

book/quarto/contents/vol1/ml_workflow/ml_workflow.qmd

@@ -2258,14 +2258,5 @@ The workflow framework established here provides the organizing structure for ev
 
 Seen as a checklist, the lifecycle is a sequence of stages to clear in order. Seen correctly, it is a loop. A constraint discovered at deployment does not stay there; it propagates backward into model selection and forward into data collection, its cost compounding at every stage it survived undetected. A workflow is therefore a coupled system rather than a pipeline, the same coupling the D·A·M taxonomy describes in *space*, now unfolding in *time*. Optimizing one stage in isolation moves the failure instead of removing it, which is why the discipline is to see the whole map before touching any single part of it.
 
-::: {.callout-research-questions title="For further inquiry"}
-
-* How should problem definition force deployment constraints backward into data, model, and validation decisions?
-* Which stage interface contracts most reduce late rework in a specific ML application?
-* When can faster iteration with a smaller model outperform slower iteration with a larger model?
-* How should validation progress from offline tests to shadow mode, canary rollout, and A/B testing as deployment risk grows?
-
-:::
-
 ::: { .quiz-end }
 :::