Refocus Discussion on ML systems education pedagogy

Replaced overly broad 'Transferable Design Principles' and 'Implications for Practice'
with focused 'Pedagogical Flexibility and Curriculum Configurations' subsection.

New content addresses practical ML systems education deployment:
- Multi-semester pathways (Foundation S1, Architecture S2)
- Single-tier focus with pre-built packages (import what you need)
- Progressive builds with intermediate validation (build, use, identify gaps)
- Hybrid build-and-use curriculum (TinyTorch modules + PyTorch projects)
- Selective depth based on student background (variable pacing)

This keeps Discussion focused on ML systems education rather than generalizing
to compilers, databases, OS courses. Complements (not overlaps) course deployment
section which covers technical infrastructure (JupyterHub, NBGrader, TA support).

Addresses feedback: Discussion should focus on how educators can actually use
TinyTorch in different pedagogical configurations, not abstract principles.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>

paper/paper.tex

@@ -1018,27 +1018,20 @@ TinyTorch's CPU-only, framework-internals-focused scope represents deliberate pe
 
 Similarly, distributed training (data parallelism, model parallelism, gradient synchronization) and production deployment (model serving, compilation, MLOps) introduce substantial additional complexity orthogonal to framework understanding. These topics remain important but beyond current pedagogical scope. Future extensions could address distributed systems through simulation-based pedagogy (\Cref{sec:future-work}), maintaining accessibility while teaching concepts.
 
-\subsection{Transferable Design Principles for Systems Education}
+\subsection{Pedagogical Flexibility and Curriculum Configurations}
+\label{subsec:flexibility}
 
-While TinyTorch targets ML framework education, five underlying principles generalize to systems courses broadly:
+TinyTorch's modular, tier-based structure enables diverse deployment configurations beyond full-curriculum completion. This flexibility addresses institutional constraints (semester credits, prerequisite chains, student backgrounds) while maintaining pedagogical coherence through progressive capability accumulation.
 
-\textbf{1. Delayed Abstraction Activation}: Rather than introducing features sequentially (Module 1 = tensors, Module 2 = autograd as separate system), embed capabilities early but activate later. Tensor.backward() exists from Module 01 but remains dormant until Module 05, when computational graphs make gradients meaningful. This maintains conceptual unity (students work with ONE Tensor class) while managing cognitive load (early modules avoid gradient tracking overhead). \textbf{Applicability}: Compiler courses could expose semantic analysis infrastructure early (dormant) but activate after parser completion. Database courses could show transaction mechanisms before concurrency module. Operating systems could introduce virtual memory concepts before paging implementation.
+\textbf{Multi-semester pathways}: The three-tier structure (Foundation, Architecture, Optimization) naturally partitions into semester-long units. Students could complete Foundation (Modules 01--07: tensors through training loops) in Semester 1, then Architecture (Modules 08--13: CNNs through transformers) in Semester 2. Each semester delivers standalone value: Foundation students can train simple networks and understand framework internals; Architecture students gain modern deep learning implementation experience. This progression mirrors typical ML education: introductory ML $\rightarrow$ TinyTorch Foundation $\rightarrow$ TinyTorch Architecture $\rightarrow$ advanced ML systems. Two-semester deployment reduces per-semester cognitive load while enabling deeper engagement with each tier.
 
-\textbf{2. Historical Validation as Correctness Proof}: Using historical benchmarks (1958 Perceptron $\rightarrow$ 2017 Transformer) provides non-synthetic validation that implementations compose correctly. If student autograd trains XOR successfully (1986 milestone), backpropagation likely works; if attention generates coherent text (2017 milestone), transformer implementation succeeded. Historical framing also motivates learning: students "prove Minsky wrong" about neural networks, not just "complete Exercise 3." \textbf{Applicability}: Compiler courses recreate C $\rightarrow$ C++ $\rightarrow$ Rust language features historically. Graphics courses progress from wireframe rendering (1960s) through Phong shading (1970s) to physically-based rendering (2000s). Network courses implement TCP variants chronologically (Tahoe, Reno, CUBIC).
+\textbf{Single-tier focus with pre-built packages}: Educators targeting specific learning objectives can use completed modules as dependencies. Students focusing exclusively on optimization techniques (quantization, pruning, distillation in Modules 14--18) could import pre-built \texttt{tinytorch.nn} and \texttt{tinytorch.optim} packages covering Foundation and Architecture tiers, then implement only optimization modules. This "build what you're learning, import what you need" approach enables targeted depth without requiring full-curriculum time investment. Similarly, students studying CNNs could focus on Architecture tier (Modules 08--10) using Foundation as dependency, or students exploring transformers could import everything through Module 09 to concentrate on attention mechanisms (Modules 11--13).
 
-\textbf{3. Systems-First, Not Systems-After}: Embed profiling and measurement from Module 01 rather than deferring to "advanced topics." Students calculate \texttt{tensor.nbytes} before matrix multiplication, predict Conv2d memory before implementation, profile attention complexity before optimization. This prevents "correct but unusable" implementations where students build functional systems without understanding resource constraints. \textbf{Applicability}: Database courses measure query execution time and index memory overhead from first SELECT statement. Operating systems courses profile context switch latency and memory footprint before threading module. Compiler courses track parse table size and optimization pass runtime from initial implementation.
+\textbf{Progressive builds with intermediate validation}: Rather than attempting entire tiers sequentially, students could alternate building and using. After implementing Foundation tier (Modules 01--07), students might spend 2--3 weeks using their framework for traditional ML projects (image classification, sentiment analysis) before proceeding to Architecture tier. This consolidation period validates understanding through application: Can students debug their own autograd? Profile their own training loops? Fix their own optimizer bugs? Productive struggle with self-built tools reveals gaps requiring review before advancing. This rhythm---build foundation, use extensively, identify gaps, build next tier---mirrors professional learning cycles where implementation precedes mastery.
 
-\textbf{4. Unified Implementation Model}: Students maintain ONE codebase that grows (not 20 separate assignments). Module 13 transformers import Module 11 embeddings, Module 12 attention, and Module 03 layers---integration tests validate cross-module composition. This mirrors professional practice (multi-month projects, not throw-away exercises) and enables compound learning (later modules depend on earlier correctness). \textbf{Applicability}: Distributed systems courses build consensus protocol (Raft/Paxos) then key-value store using that protocol. Compiler courses implement frontend (lexer, parser), then midend (optimizations), then backend (code generation) as unified pipeline. Database courses build storage layer, then query processor using that storage.
+\textbf{Hybrid build-and-use curriculum}: TinyTorch modules could integrate with PyTorch-first courses by revealing internals alongside application. Students learning CNNs with PyTorch could implement TinyTorch Module 09 (convolution) to understand \texttt{torch.nn.Conv2d} internals, then continue using PyTorch for projects. This parallel construction---"here's how PyTorch works inside, here's how you build equivalent functionality"---bridges black-box usage and systems understanding. Critical modules for hybrid integration include: Module 05 (autograd, revealing \texttt{loss.backward()}), Module 09 (convolution, explaining GPU kernel complexity), Module 12 (attention, demystifying transformer libraries).
 
-\textbf{5. Accessibility Through Simplicity Trades Performance}: CPU-only, pure Python enables global access but sacrifices speed. This trade-off prioritizes pedagogical transparency---students read every line of TinyTorch without encountering C++ template metaprogramming or CUDA intrinsics. \textbf{Applicability}: Educational operating systems (xv6, Pintos) use simplified designs versus production complexity (Linux, Windows). Teaching compilers (MiniJava, Tiger) omit production optimizations (LLVM's 100+ passes). Pedagogical databases (SimpleDB, MiniBase) favor understandability over PostgreSQL's performance sophistication.
-
-\subsection{Implications for Practice}
-
-\textbf{For ML educators}: TinyTorch enables three adoption pathways: (1) \textbf{Standalone course}: Dedicate 3-4 credits (60-80 hours) to complete systems curriculum, targeting juniors/seniors post-algorithms and introductory ML. (2) \textbf{Integrated track}: Pair TinyTorch modules with PyTorch usage---Module 05 autograd implementation alongside PyTorch \texttt{loss.backward()} usage, revealing internals through parallel construction. (3) \textbf{Selective modules}: Extract foundation tier (Modules 01-07) as half-semester unit, or architecture tier (Modules 08-13) for advanced students. Modular structure supports flexible integration based on institutional constraints and student backgrounds.
-
-\textbf{For curriculum designers}: TinyTorch positions ML systems education between CS fundamentals and specialized ML coursework. Prerequisites include data structures (tensor operations), algorithms (complexity analysis), and introductory ML (gradient descent, loss functions). Post-TinyTorch pathways include advanced ML systems (CMU Deep Learning Systems, distributed training), ML theory (statistical learning, optimization), or production deployment (MLOps, model serving). The 60-80 hour scope fits 3-credit semester course, intensive 2-week bootcamp, or self-paced professional development.
-
-\textbf{For students and learners}: Completing TinyTorch develops three transferable competencies distinguishing ML systems engineers from ML application developers: (1) \textbf{Framework internals knowledge} enabling production debugging (diagnosing gradient flow issues, profiling memory bottlenecks, understanding optimizer state management). (2) \textbf{Systems thinking} for resource-constrained deployment (calculating memory requirements before training, predicting inference latency, reasoning about hardware trade-offs). (3) \textbf{Implementation skills} for rapid prototyping (building custom layers, modifying optimizers, experimenting with novel architectures). Career pathways include ML infrastructure engineering, framework development, compiler optimization for ML accelerators, and edge deployment for TinyML systems.
+\textbf{Selective depth based on student background}: Advanced students with strong systems background might accelerate through Foundation tier (treating it as review with implementation practice) to reach Architecture and Optimization tiers where novel learning concentrates. Conversely, students from non-CS backgrounds (statistics, domain sciences) might spend extended time on Foundation tier to build systems intuition before architecture complexity. Variable pacing accommodates heterogeneous classrooms without prescriptive timelines---depth of understanding matters more than completion speed. Optional scaffolding modules (numerical gradient checking, scalar autograd prototypes) provide additional support for students requiring intermediate steps.
 
 \subsection{Limitations}