mirror of
https://github.com/harvard-edge/cs249r_book.git
synced 2026-07-16 06:07:17 -05:00
1264 lines
73 KiB
HTML
1264 lines
73 KiB
HTML
<!doctype html>
|
|
<html lang="en">
|
|
<head>
|
|
<meta charset="utf-8">
|
|
<meta name="viewport" content="width=device-width, initial-scale=1">
|
|
<title>MLSysBook Lab Activity Blueprint</title>
|
|
<style>
|
|
:root {
|
|
color-scheme: light;
|
|
--ink: #172033;
|
|
--muted: #5c667a;
|
|
--line: #d9dee8;
|
|
--soft: #f5f7fb;
|
|
--panel: #ffffff;
|
|
--blue: #006395;
|
|
--green: #008f45;
|
|
--red: #cb202d;
|
|
--amber: #b85c00;
|
|
--purple: #6254b2;
|
|
--shadow: 0 1px 3px rgba(23, 32, 51, 0.08);
|
|
--radius: 8px;
|
|
}
|
|
|
|
* {
|
|
box-sizing: border-box;
|
|
}
|
|
|
|
body {
|
|
margin: 0;
|
|
font-family: Inter, ui-sans-serif, system-ui, -apple-system, BlinkMacSystemFont, "Segoe UI", sans-serif;
|
|
color: var(--ink);
|
|
background: #eef2f7;
|
|
line-height: 1.45;
|
|
}
|
|
|
|
a {
|
|
color: var(--blue);
|
|
}
|
|
|
|
.shell {
|
|
min-height: 100vh;
|
|
display: grid;
|
|
grid-template-columns: 260px minmax(0, 1fr);
|
|
}
|
|
|
|
aside {
|
|
position: sticky;
|
|
top: 0;
|
|
height: 100vh;
|
|
overflow: auto;
|
|
padding: 20px 16px;
|
|
background: #172033;
|
|
color: #f8fafc;
|
|
border-right: 1px solid #111827;
|
|
}
|
|
|
|
aside h1 {
|
|
margin: 0 0 8px;
|
|
font-size: 1rem;
|
|
letter-spacing: 0;
|
|
}
|
|
|
|
aside p {
|
|
margin: 0 0 20px;
|
|
color: #cbd5e1;
|
|
font-size: 0.86rem;
|
|
}
|
|
|
|
.nav-list {
|
|
display: grid;
|
|
gap: 6px;
|
|
}
|
|
|
|
.nav-list a {
|
|
display: block;
|
|
padding: 8px 10px;
|
|
color: #e5edf8;
|
|
text-decoration: none;
|
|
border-radius: var(--radius);
|
|
font-size: 0.9rem;
|
|
}
|
|
|
|
.nav-list a:hover {
|
|
background: rgba(255, 255, 255, 0.1);
|
|
}
|
|
|
|
main {
|
|
min-width: 0;
|
|
padding: 28px;
|
|
}
|
|
|
|
.hero {
|
|
background: var(--panel);
|
|
border: 1px solid var(--line);
|
|
border-radius: var(--radius);
|
|
box-shadow: var(--shadow);
|
|
padding: 24px;
|
|
margin-bottom: 18px;
|
|
}
|
|
|
|
.eyebrow {
|
|
margin: 0 0 8px;
|
|
color: var(--blue);
|
|
font-weight: 700;
|
|
font-size: 0.78rem;
|
|
text-transform: uppercase;
|
|
letter-spacing: 0.08em;
|
|
}
|
|
|
|
.hero h2 {
|
|
margin: 0;
|
|
font-size: clamp(1.6rem, 2.4vw, 2.35rem);
|
|
letter-spacing: 0;
|
|
line-height: 1.15;
|
|
}
|
|
|
|
.hero .lead {
|
|
max-width: 950px;
|
|
margin: 12px 0 0;
|
|
color: var(--muted);
|
|
font-size: 1rem;
|
|
}
|
|
|
|
.stat-grid {
|
|
display: grid;
|
|
grid-template-columns: repeat(4, minmax(0, 1fr));
|
|
gap: 12px;
|
|
margin-top: 18px;
|
|
}
|
|
|
|
.stat {
|
|
border: 1px solid var(--line);
|
|
border-radius: var(--radius);
|
|
padding: 12px;
|
|
background: var(--soft);
|
|
min-height: 88px;
|
|
}
|
|
|
|
.stat strong {
|
|
display: block;
|
|
font-size: 1.45rem;
|
|
line-height: 1.1;
|
|
}
|
|
|
|
.stat span {
|
|
display: block;
|
|
margin-top: 5px;
|
|
color: var(--muted);
|
|
font-size: 0.84rem;
|
|
}
|
|
|
|
section {
|
|
background: var(--panel);
|
|
border: 1px solid var(--line);
|
|
border-radius: var(--radius);
|
|
box-shadow: var(--shadow);
|
|
padding: 18px;
|
|
margin-bottom: 18px;
|
|
}
|
|
|
|
section h2 {
|
|
margin: 0 0 12px;
|
|
font-size: 1.12rem;
|
|
letter-spacing: 0;
|
|
}
|
|
|
|
.section-note {
|
|
margin: -4px 0 14px;
|
|
color: var(--muted);
|
|
font-size: 0.92rem;
|
|
}
|
|
|
|
.callout {
|
|
border-left: 4px solid var(--amber);
|
|
background: #fff7ed;
|
|
padding: 12px 14px;
|
|
border-radius: 0 var(--radius) var(--radius) 0;
|
|
color: #56340a;
|
|
margin: 12px 0;
|
|
}
|
|
|
|
.boundary-grid {
|
|
display: grid;
|
|
grid-template-columns: repeat(2, minmax(0, 1fr));
|
|
gap: 12px;
|
|
}
|
|
|
|
.boundary {
|
|
border: 1px solid var(--line);
|
|
border-radius: var(--radius);
|
|
padding: 14px;
|
|
background: var(--soft);
|
|
}
|
|
|
|
.boundary h3 {
|
|
margin: 0 0 8px;
|
|
font-size: 0.95rem;
|
|
}
|
|
|
|
.boundary ul {
|
|
margin: 0;
|
|
padding-left: 18px;
|
|
color: var(--muted);
|
|
font-size: 0.9rem;
|
|
}
|
|
|
|
.toolbar {
|
|
position: sticky;
|
|
top: 0;
|
|
z-index: 2;
|
|
display: grid;
|
|
grid-template-columns: minmax(220px, 1fr) auto auto;
|
|
gap: 10px;
|
|
align-items: center;
|
|
padding: 12px;
|
|
margin: -2px -2px 14px;
|
|
background: rgba(255, 255, 255, 0.96);
|
|
border: 1px solid var(--line);
|
|
border-radius: var(--radius);
|
|
}
|
|
|
|
input[type="search"],
|
|
select {
|
|
width: 100%;
|
|
min-height: 40px;
|
|
border: 1px solid var(--line);
|
|
border-radius: var(--radius);
|
|
padding: 8px 10px;
|
|
font: inherit;
|
|
color: var(--ink);
|
|
background: #fff;
|
|
}
|
|
|
|
.segmented {
|
|
display: flex;
|
|
border: 1px solid var(--line);
|
|
border-radius: var(--radius);
|
|
overflow: hidden;
|
|
background: #fff;
|
|
min-height: 40px;
|
|
}
|
|
|
|
.segmented button {
|
|
border: 0;
|
|
border-right: 1px solid var(--line);
|
|
padding: 0 12px;
|
|
background: #fff;
|
|
color: var(--muted);
|
|
font: inherit;
|
|
cursor: pointer;
|
|
white-space: nowrap;
|
|
}
|
|
|
|
.segmented button:last-child {
|
|
border-right: 0;
|
|
}
|
|
|
|
.segmented button[aria-pressed="true"] {
|
|
background: var(--blue);
|
|
color: #fff;
|
|
}
|
|
|
|
.count {
|
|
color: var(--muted);
|
|
font-size: 0.9rem;
|
|
white-space: nowrap;
|
|
}
|
|
|
|
table {
|
|
width: 100%;
|
|
border-collapse: collapse;
|
|
table-layout: fixed;
|
|
font-size: 0.9rem;
|
|
}
|
|
|
|
th,
|
|
td {
|
|
border-bottom: 1px solid var(--line);
|
|
padding: 10px;
|
|
vertical-align: top;
|
|
text-align: left;
|
|
}
|
|
|
|
th {
|
|
position: sticky;
|
|
top: 66px;
|
|
z-index: 1;
|
|
background: #f8fafc;
|
|
color: #334155;
|
|
font-size: 0.78rem;
|
|
text-transform: uppercase;
|
|
letter-spacing: 0.04em;
|
|
}
|
|
|
|
tbody tr:hover {
|
|
background: #f8fbff;
|
|
}
|
|
|
|
.tag {
|
|
display: inline-flex;
|
|
align-items: center;
|
|
min-height: 24px;
|
|
border-radius: 999px;
|
|
padding: 2px 8px;
|
|
font-weight: 700;
|
|
font-size: 0.75rem;
|
|
background: #e8eef7;
|
|
color: #334155;
|
|
white-space: nowrap;
|
|
}
|
|
|
|
.tag.v1 {
|
|
background: #e8f5ee;
|
|
color: #116b38;
|
|
}
|
|
|
|
.tag.v2 {
|
|
background: #edf0ff;
|
|
color: #4338ca;
|
|
}
|
|
|
|
.activity-name {
|
|
font-weight: 700;
|
|
color: var(--ink);
|
|
}
|
|
|
|
.chapter {
|
|
font-weight: 700;
|
|
}
|
|
|
|
.muted {
|
|
color: var(--muted);
|
|
}
|
|
|
|
code {
|
|
padding: 2px 5px;
|
|
border-radius: 5px;
|
|
background: #eef2f7;
|
|
color: #243047;
|
|
font-family: ui-monospace, SFMono-Regular, Menlo, Consolas, monospace;
|
|
font-size: 0.86em;
|
|
}
|
|
|
|
.api-grid {
|
|
display: grid;
|
|
grid-template-columns: repeat(2, minmax(0, 1fr));
|
|
gap: 10px;
|
|
}
|
|
|
|
.track-grid {
|
|
display: grid;
|
|
grid-template-columns: repeat(4, minmax(0, 1fr));
|
|
gap: 10px;
|
|
}
|
|
|
|
.track-card {
|
|
border: 1px solid var(--line);
|
|
border-radius: var(--radius);
|
|
padding: 12px;
|
|
background: var(--soft);
|
|
min-height: 220px;
|
|
}
|
|
|
|
.track-card h3 {
|
|
margin: 0 0 6px;
|
|
font-size: 0.98rem;
|
|
}
|
|
|
|
.track-card p {
|
|
margin: 8px 0 0;
|
|
color: var(--muted);
|
|
font-size: 0.88rem;
|
|
}
|
|
|
|
.track-card dl {
|
|
display: grid;
|
|
gap: 5px;
|
|
margin: 10px 0 0;
|
|
font-size: 0.82rem;
|
|
}
|
|
|
|
.track-card dt {
|
|
color: var(--muted);
|
|
font-weight: 700;
|
|
text-transform: uppercase;
|
|
letter-spacing: 0.04em;
|
|
font-size: 0.68rem;
|
|
}
|
|
|
|
.track-card dd {
|
|
margin: 0;
|
|
overflow-wrap: anywhere;
|
|
}
|
|
|
|
.api-item {
|
|
border: 1px solid var(--line);
|
|
border-radius: var(--radius);
|
|
padding: 12px;
|
|
background: var(--soft);
|
|
}
|
|
|
|
.api-item code {
|
|
font-weight: 700;
|
|
color: var(--blue);
|
|
background: #e7f2f9;
|
|
}
|
|
|
|
.api-item p {
|
|
margin: 8px 0 0;
|
|
color: var(--muted);
|
|
font-size: 0.9rem;
|
|
}
|
|
|
|
.empty {
|
|
padding: 28px;
|
|
text-align: center;
|
|
color: var(--muted);
|
|
border: 1px dashed var(--line);
|
|
border-radius: var(--radius);
|
|
background: var(--soft);
|
|
}
|
|
|
|
@media (max-width: 980px) {
|
|
.shell {
|
|
display: block;
|
|
}
|
|
|
|
aside {
|
|
position: static;
|
|
height: auto;
|
|
}
|
|
|
|
main {
|
|
padding: 16px;
|
|
}
|
|
|
|
.stat-grid,
|
|
.boundary-grid,
|
|
.track-grid,
|
|
.api-grid {
|
|
grid-template-columns: repeat(2, minmax(0, 1fr));
|
|
}
|
|
|
|
.toolbar {
|
|
grid-template-columns: 1fr;
|
|
}
|
|
|
|
th {
|
|
top: 0;
|
|
}
|
|
}
|
|
|
|
@media (max-width: 720px) {
|
|
.stat-grid,
|
|
.boundary-grid,
|
|
.track-grid,
|
|
.api-grid {
|
|
grid-template-columns: 1fr;
|
|
}
|
|
|
|
table,
|
|
thead,
|
|
tbody,
|
|
th,
|
|
td,
|
|
tr {
|
|
display: block;
|
|
}
|
|
|
|
thead {
|
|
display: none;
|
|
}
|
|
|
|
tbody tr {
|
|
border: 1px solid var(--line);
|
|
border-radius: var(--radius);
|
|
margin-bottom: 10px;
|
|
background: #fff;
|
|
overflow: hidden;
|
|
}
|
|
|
|
td {
|
|
border-bottom: 1px solid #edf0f5;
|
|
display: grid;
|
|
grid-template-columns: 120px minmax(0, 1fr);
|
|
gap: 10px;
|
|
}
|
|
|
|
td:last-child {
|
|
border-bottom: 0;
|
|
}
|
|
|
|
td::before {
|
|
content: attr(data-label);
|
|
color: var(--muted);
|
|
font-size: 0.75rem;
|
|
text-transform: uppercase;
|
|
letter-spacing: 0.04em;
|
|
font-weight: 700;
|
|
}
|
|
}
|
|
</style>
|
|
</head>
|
|
<body>
|
|
<div class="shell">
|
|
<aside>
|
|
<h1>MLSysBook Labs</h1>
|
|
<p>Readable activity blueprint for the trade-off labs.</p>
|
|
<nav class="nav-list" aria-label="Page sections">
|
|
<a href="#overview">Overview</a>
|
|
<a href="#depth">Depth And Narrative</a>
|
|
<a href="#tracks">Track Materialization</a>
|
|
<a href="#track-arcs">Track Arcs</a>
|
|
<a href="#coverage">Volume Coverage</a>
|
|
<a href="#concepts">Core Concepts</a>
|
|
<a href="#boundary">Package Boundary</a>
|
|
<a href="#experience">Experience System</a>
|
|
<a href="#devices">Interaction Devices</a>
|
|
<a href="#completeness">Design Completeness</a>
|
|
<a href="#adoption">Instructor Adoption</a>
|
|
<a href="#reports">Student Report</a>
|
|
<a href="#versioning">Versioning</a>
|
|
<a href="#activities">Activity Matrix</a>
|
|
<a href="#numbering">Volume 2 Mapping</a>
|
|
<a href="#engine">MLSysIM Engine Plan</a>
|
|
<a href="LAB_SYSTEM_SPECIFICATION.md">Open System Spec</a>
|
|
<a href="LAB_DESIGN_COMPLETENESS_CHECKLIST.md">Open Design Checklist</a>
|
|
<a href="LAB_INTERACTION_DEVICE_CATALOG.md">Open Device Catalog</a>
|
|
<a href="LAB_EXPERIENCE_AND_MLSYSIM_READINESS.md">Open Experience Plan</a>
|
|
<a href="MLSYSIM_LAB_ACTIVITY_BLUEPRINT.md">Open Markdown Blueprint</a>
|
|
<a href="TRADEOFF_LAB_IMPROVEMENT_PLAN.md">Open Full Plan</a>
|
|
</nav>
|
|
</aside>
|
|
|
|
<main>
|
|
<section id="overview" class="hero">
|
|
<p class="eyebrow">Interactive lab redesign</p>
|
|
<h2>Activity-Level MLSysIM Lab Blueprint</h2>
|
|
<p class="lead">
|
|
This page summarizes the implemented labs as ML systems trade-off environments.
|
|
Each lab opens with a chapter anchor and track-specific scenario, then walks through one or more learning nuggets.
|
|
Each nugget follows the same rhythm: predict, find the binding constraint, explore the trade-off surface, decide, and reflect.
|
|
</p>
|
|
<div class="stat-grid" aria-label="Plan summary">
|
|
<div class="stat"><strong>2</strong><span>Book volumes covered</span></div>
|
|
<div class="stat"><strong>34</strong><span>Track-aware labs across Volume I and Volume II</span></div>
|
|
<div class="stat"><strong>4</strong><span>Canonical tracks: iPhone, Oura Ring, RoboTaxi, Cloud Fleet</span></div>
|
|
<div class="stat"><strong>30-60</strong><span>Expected minutes per full lab, depending on assignment depth</span></div>
|
|
</div>
|
|
</section>
|
|
|
|
<section id="depth">
|
|
<h2>Depth And Narrative Contract</h2>
|
|
<p class="section-note">The labs are designed as substantial guided engineering activities, not quick demos. A compact run should take about 30 minutes; a full report-oriented assignment can reasonably take 45 to 60 minutes.</p>
|
|
<div class="api-grid">
|
|
<div class="api-item">
|
|
<code>Opening narrative</code>
|
|
<p>Every lab should start with volume, chapter, title, chapter recap, learning objectives, track context, scenario brief, and lab map.</p>
|
|
</div>
|
|
<div class="api-item">
|
|
<code>Chapter anchor</code>
|
|
<p>Each lab maps to a specific book chapter and turns that chapter into a systems decision: constraint, knob, evidence, and defensible choice.</p>
|
|
</div>
|
|
<div class="api-item">
|
|
<code>Time-on-task</code>
|
|
<p>Default path: 3 to 5 minutes orientation, 20 to 35 minutes prediction/evidence/decision work, 7 to 15 minutes report and reflection.</p>
|
|
</div>
|
|
<div class="api-item">
|
|
<code>Student artifact</code>
|
|
<p>The target artifact is a local Markdown report with track, scenario, predictions, evidence summary, final decision, residual risk, provenance/caveats, and result snapshot.</p>
|
|
</div>
|
|
</div>
|
|
</section>
|
|
|
|
<section id="tracks">
|
|
<h2>Canonical Track Materialization</h2>
|
|
<p class="section-note">Students pick one track and carry it through the labs. The track is not just a label: it changes stakeholder, device family, model family, metrics, guardrails, dominant constraints, narrative, and report framing.</p>
|
|
<div class="track-grid" id="trackGrid"></div>
|
|
</section>
|
|
|
|
<section id="track-arcs">
|
|
<h2>Volume Track Arcs</h2>
|
|
<p class="section-note">The same chapter goals repeat across all tracks, but the long-form narrative changes. Volume I teaches deployment feasibility for a selected context. Volume II scales that same context into fleet, operations, responsibility, and synthesis questions.</p>
|
|
<div class="track-grid" id="arcGrid"></div>
|
|
</section>
|
|
|
|
<section id="coverage">
|
|
<h2>Implemented Volume Coverage</h2>
|
|
<p class="section-note">This table shows what each lab is trying to teach, which book chapter it anchors to, and how the four tracks materialize the same pedagogy differently.</p>
|
|
<table>
|
|
<thead>
|
|
<tr>
|
|
<th style="width: 8%">Volume</th>
|
|
<th style="width: 18%">Lab</th>
|
|
<th style="width: 18%">Chapter anchor</th>
|
|
<th style="width: 20%">Core concept</th>
|
|
<th>Track materialization</th>
|
|
</tr>
|
|
</thead>
|
|
<tbody id="coverageBody"></tbody>
|
|
</table>
|
|
</section>
|
|
|
|
<section id="concepts">
|
|
<h2>Core Concepts</h2>
|
|
<p class="section-note">These are the cross-cutting ML systems ideas the labs should reinforce repeatedly.</p>
|
|
<table>
|
|
<thead>
|
|
<tr>
|
|
<th style="width: 23%">Concept</th>
|
|
<th>What students need to learn</th>
|
|
<th>MLSysIM responsibility</th>
|
|
</tr>
|
|
</thead>
|
|
<tbody id="conceptBody"></tbody>
|
|
</table>
|
|
</section>
|
|
|
|
<section id="boundary">
|
|
<h2>Package Boundary</h2>
|
|
<p class="section-note">MLSysIM is the reusable engine for both the textbook and labs. The lab helper layer owns pedagogy and UI.</p>
|
|
<div class="boundary-grid">
|
|
<div class="boundary">
|
|
<h3>MLSysIM should contain</h3>
|
|
<ul>
|
|
<li>Constants and registries used by the book and labs.</li>
|
|
<li>Hardware, model, workload, and scenario data.</li>
|
|
<li>Domain formulas, solvers, sweeps, and result schemas.</li>
|
|
<li>Book-friendly helpers for reproducible callouts and figures.</li>
|
|
</ul>
|
|
</div>
|
|
<div class="boundary">
|
|
<h3>Lab helper package should contain</h3>
|
|
<ul>
|
|
<li>Marimo UI components and layout.</li>
|
|
<li>Track selector and curriculum mapping.</li>
|
|
<li>Design ledger and browser persistence.</li>
|
|
<li>CSS, Plotly themes, prompts, and instructor-facing metadata.</li>
|
|
</ul>
|
|
</div>
|
|
</div>
|
|
<div class="callout">
|
|
Target import boundary:
|
|
<code>from mlsysim import Engine, Hardware, Models, Scenarios</code>
|
|
and
|
|
<code>from mlsysbook_labs import DesignLedger, track_selector, tradeoff_poster, decision_card</code>
|
|
</div>
|
|
</section>
|
|
|
|
<section id="experience">
|
|
<h2>Experience System</h2>
|
|
<p class="section-note">The labs need a consistent academic shell, not a dark dashboard banner. The interaction should support chapter reading, repeated learning nuggets, prediction, trade-off exploration, reflection, and decision-making.</p>
|
|
<div class="boundary-grid">
|
|
<div class="boundary">
|
|
<h3>Visual Direction</h3>
|
|
<ul>
|
|
<li>Light academic interface with restrained borders and readable spacing.</li>
|
|
<li>Volume I accent: Harvard Crimson <code>#A51C30</code>.</li>
|
|
<li>Volume II accent: ETH Blue <code>#1F407A</code>.</li>
|
|
<li>Replace inline dark gradients with a shared <code>lab_header()</code>.</li>
|
|
<li>Use status colors only for feasible, caution, violated, and selected states.</li>
|
|
</ul>
|
|
</div>
|
|
<div class="boundary">
|
|
<h3>Pedagogical Cycle</h3>
|
|
<ul>
|
|
<li>Lab wrapper: volume, chapter, mini recap, track, scenario, and nugget map.</li>
|
|
<li>Each nugget names one chapter idea and why it matters.</li>
|
|
<li>Prediction before instruments are revealed.</li>
|
|
<li>Binding constraint, trade-off surface, engineering decision.</li>
|
|
<li>Reflection prompt and design ledger update.</li>
|
|
</ul>
|
|
</div>
|
|
</div>
|
|
<div class="callout">
|
|
Scope target: one chapter, one selected track, one scenario family, one to three learning nuggets, one main trade-off visual per nugget, and one final synthesis decision. This is enough depth for a 30 to 45 minute learning experience without filling headers with rigid time badges.
|
|
</div>
|
|
</section>
|
|
|
|
<section id="devices">
|
|
<h2>Interaction Devices</h2>
|
|
<p class="section-note">The device catalog defines which Marimo controls and visuals to use for each pedagogical purpose, so widgets are selected intentionally.</p>
|
|
<div class="api-grid">
|
|
<div class="api-item">
|
|
<code>Control devices</code>
|
|
<p>Slider cards, range sliders, number predictions, radio/segmented strategy selectors, dropdowns, checklists, switches, and commit forms.</p>
|
|
</div>
|
|
<div class="api-item">
|
|
<code>Visual devices</code>
|
|
<p>Constraint budgets, stacked bars, curves, Pareto frontiers, heatmaps, rooflines, queueing charts, timelines, world maps, topology diagrams, and tables.</p>
|
|
</div>
|
|
<div class="api-item">
|
|
<code>Pedagogical devices</code>
|
|
<p>Prediction locks, method notes, failure boundary callouts, reflection cards, decision cards, before/after comparisons, and ledger timelines.</p>
|
|
</div>
|
|
<div class="api-item">
|
|
<code>Critical lens</code>
|
|
<p>Each device must help students identify a knob, constraint, trade-off, decision, assumption, or residual risk.</p>
|
|
</div>
|
|
</div>
|
|
</section>
|
|
|
|
<section id="completeness">
|
|
<h2>Design Completeness</h2>
|
|
<p class="section-note">Before implementation, each lab should capture the ML systems translation, thematic nuggets, misconceptions, student artifacts, rubrics, and instructor use.</p>
|
|
<div class="api-grid">
|
|
<div class="api-item">
|
|
<code>ML to systems</code>
|
|
<p>For every chapter: name the ML concept, systems translation, knob, binding resource, failure mode, and defensible decision.</p>
|
|
</div>
|
|
<div class="api-item">
|
|
<code>Thematic nuggets</code>
|
|
<p>Reinforce durable ideas: D.A.M coupling, Iron Law, resource budgets, bottleneck migration, data movement, tails, scale, reliability, and responsibility.</p>
|
|
</div>
|
|
<div class="api-item">
|
|
<code>Misconceptions</code>
|
|
<p>Each nugget should correct a specific wrong intuition, such as smaller is always faster or more GPUs always means linear speedup.</p>
|
|
</div>
|
|
<div class="api-item">
|
|
<code>Artifacts and rubric</code>
|
|
<p>Capture prediction, bottleneck diagnosis, trade-off interpretation, selected configuration, residual risk, chapter principle, and result snapshot.</p>
|
|
</div>
|
|
<div class="api-item">
|
|
<code>Downloadable report</code>
|
|
<p>Each lab should export a lightweight Markdown report and optional JSON ledger snapshot so students can submit evidence of completion.</p>
|
|
</div>
|
|
<div class="api-item">
|
|
<code>Instructor guide</code>
|
|
<p>Use one consolidated guide organized by volume and chapter, with optional local notes beside each lab for maintenance.</p>
|
|
</div>
|
|
</div>
|
|
</section>
|
|
|
|
<section id="adoption">
|
|
<h2>Instructor Adoption</h2>
|
|
<p class="section-note">The labs should be easy to adopt as global teaching material. An instructor should understand why to assign a lab, where it fits, what students submit, and how to evaluate the result.</p>
|
|
<div class="api-grid">
|
|
<div class="api-item">
|
|
<code>Mini recap</code>
|
|
<p>Every lab opens with the chapter emphasis, key terms, ML-to-systems translation, what to watch, and the common trap the lab corrects.</p>
|
|
</div>
|
|
<div class="api-item">
|
|
<code>Assignment-ready</code>
|
|
<p>Each lab should include copy-ready assignment text, expected report contents, and a lightweight rubric.</p>
|
|
</div>
|
|
<div class="api-item">
|
|
<code>Adoption modes</code>
|
|
<p>Standalone homework, lecture companion, module sequence, and capstone preparation should all be supported without redesigning the lab.</p>
|
|
</div>
|
|
<div class="api-item">
|
|
<code>Instructor value</code>
|
|
<p>Students practice ML systems judgment without requiring a custom cluster, hardware kit, long build project, or instructor-authored simulator.</p>
|
|
</div>
|
|
</div>
|
|
</section>
|
|
|
|
<section id="reports">
|
|
<h2>Student Report</h2>
|
|
<p class="section-note">Every lab should end with a simple downloadable artifact that a student can submit to show they completed the lab and made a reasoned ML systems decision.</p>
|
|
<div class="api-grid">
|
|
<div class="api-item">
|
|
<code>What it proves</code>
|
|
<p>The student selected a track, completed the nuggets, interpreted the binding constraints, and made a defensible engineering decision.</p>
|
|
</div>
|
|
<div class="api-item">
|
|
<code>Required fields</code>
|
|
<p>Student identifier, lab ID, volume/chapter, track, scenario, predictions, constraints, selected policy, trade-off interpretation, residual risk, timestamp, and MLSysIM version.</p>
|
|
</div>
|
|
<div class="api-item">
|
|
<code>Format</code>
|
|
<p>Markdown first for easy submission and inspection. JSON ledger snapshot is optional for automated checks. HTML can come later if polish is needed.</p>
|
|
</div>
|
|
<div class="api-item">
|
|
<code>Implementation boundary</code>
|
|
<p><code>mlsysbook_labs</code> builds and downloads the report. MLSysIM provides typed, serializable result snapshots from the core engine.</p>
|
|
</div>
|
|
</div>
|
|
<div class="callout">
|
|
This keeps completion evidence simple: the report is a lab artifact, not a grading platform. Advanced knobs may enrich the report when used, but they are never required for submission.
|
|
</div>
|
|
</section>
|
|
|
|
<section id="versioning">
|
|
<h2>Versioning</h2>
|
|
<p class="section-note">The labs should be versioned like instructional infrastructure so instructors can assign stable material and students can submit reports that identify exactly what they completed.</p>
|
|
<div class="api-grid">
|
|
<div class="api-item">
|
|
<code>Visible metadata</code>
|
|
<p>Each lab should expose lab ID, lab version, updated date, book anchor, MLSysIM version, helper package version, report schema version, and ledger schema version.</p>
|
|
</div>
|
|
<div class="api-item">
|
|
<code>Report provenance</code>
|
|
<p>Downloaded reports must include lab version, MLSysIM version, report schema version, timestamp, track, scenario, and result snapshot.</p>
|
|
</div>
|
|
<div class="api-item">
|
|
<code>Release channels</code>
|
|
<p>Stable for courses, preview for redesigned labs, and dev for active work. Stable releases need tests, changelog, instructor guide snapshot, and known limitations.</p>
|
|
</div>
|
|
<div class="api-item">
|
|
<code>Change policy</code>
|
|
<p>Major changes alter assignment meaning, minor changes add supported capability, and patch changes fix defects without changing learning objectives.</p>
|
|
</div>
|
|
</div>
|
|
</section>
|
|
|
|
<section id="activities">
|
|
<h2>Activity Matrix</h2>
|
|
<p class="section-note">Use the controls to filter by volume or search for concepts such as latency, compression, fairness, serving, or collective communication.</p>
|
|
<div class="toolbar">
|
|
<input id="searchBox" type="search" placeholder="Search chapter, activity, concept, or MLSysIM need" aria-label="Search activities">
|
|
<div class="segmented" aria-label="Volume filter">
|
|
<button type="button" data-volume="all" aria-pressed="true">All</button>
|
|
<button type="button" data-volume="V1" aria-pressed="false">Volume 1</button>
|
|
<button type="button" data-volume="V2" aria-pressed="false">Volume 2</button>
|
|
</div>
|
|
<div class="count" id="activityCount"></div>
|
|
</div>
|
|
<table>
|
|
<thead>
|
|
<tr>
|
|
<th style="width: 9%">Volume</th>
|
|
<th style="width: 23%">Chapter / Lab</th>
|
|
<th style="width: 18%">Activity</th>
|
|
<th>What will be covered</th>
|
|
<th>How it will be covered</th>
|
|
<th style="width: 18%">MLSysIM needs</th>
|
|
</tr>
|
|
</thead>
|
|
<tbody id="activityBody"></tbody>
|
|
</table>
|
|
<div class="empty" id="emptyState" hidden>No activities match the current filters.</div>
|
|
</section>
|
|
|
|
<section id="numbering">
|
|
<h2>Volume 2 Mapping Decision</h2>
|
|
<p class="section-note">Decision: Volume 2 should add a dedicated Collective Communication lab and realign downstream lab numbering with the book sequence.</p>
|
|
<table>
|
|
<thead>
|
|
<tr>
|
|
<th style="width: 20%">Option</th>
|
|
<th>What it means</th>
|
|
<th>Trade-off</th>
|
|
</tr>
|
|
</thead>
|
|
<tbody>
|
|
<tr>
|
|
<td data-label="Option"><span class="tag v2">Chosen</span></td>
|
|
<td data-label="What it means">Add a dedicated Collective Communication lab after Distributed Training and renumber downstream labs.</td>
|
|
<td data-label="Trade-off">Best chapter alignment and cleaner pedagogy. The implementation must update lab IDs, links, index entries, and ledger keys together.</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
</section>
|
|
|
|
<section id="engine">
|
|
<h2>MLSysIM Engine Plan</h2>
|
|
<p class="section-note">These APIs or model families should be added or consolidated so labs and textbook examples share one source of truth.</p>
|
|
<div class="api-grid" id="apiGrid"></div>
|
|
</section>
|
|
</main>
|
|
</div>
|
|
|
|
<script>
|
|
const concepts = [
|
|
["Data, algorithm/model, machine coupling", "ML system behavior depends on all three, not any one layer alone.", "Unified scenario/result object with data, model, workload, and hardware fields."],
|
|
["Resource budgets", "Memory, compute, bandwidth, storage, energy, carbon, cost, reliability, and human ops capacity are finite.", "Canonical budget calculators and feasibility checks."],
|
|
["Bottleneck attribution", "The system should explain why it fails or slows down.", "Solver output should name active constraint and next constraint."],
|
|
["Trade-off frontiers", "A good design is usually on a frontier, not at a single optimum.", "Sweep APIs returning Pareto points and dominated points."],
|
|
["Deployment context", "Mobile, TinyML, edge, and cloud/fleet settings change which knob matters.", "Scenario registry with track-compatible defaults."],
|
|
["Workload shape", "Request rate, sequence length, image resolution, stream count, and burstiness change feasibility.", "Workload models and distribution parameters."],
|
|
["Data movement", "Moving bytes often dominates arithmetic.", "Data transfer, storage, cache, network, and memory traffic models."],
|
|
["Memory hierarchy", "SRAM, DRAM, HBM, NVMe, network, and cache create cliffs.", "Hardware memory hierarchy models."],
|
|
["Queueing and tails", "Utilization and variability create nonlinear latency.", "Queueing models with p50/p95/p99 outputs."],
|
|
["Training scale", "Optimizer state, activations, sharding, and communication dominate training.", "Training memory and throughput solvers."],
|
|
["Serving scale", "Batching, caches, cold starts, routing, and autoscaling dominate inference systems.", "Serving solver with latency, cost, memory, and utilization outputs."],
|
|
["Reliability", "More nodes, devices, and time increase failure exposure.", "Reliability, checkpoint, recovery, and useful-work models."],
|
|
["Operations", "Drift, monitoring, canaries, alert fatigue, and retraining shape system quality after deployment.", "Monitoring, drift, rollout, and platform-cost models."],
|
|
["Responsible constraints", "Privacy, security, fairness, robustness, and sustainability are engineering constraints.", "Constraint models with measurable quality/cost/latency effects."]
|
|
];
|
|
|
|
const tracks = [
|
|
{
|
|
name: "iPhone",
|
|
category: "Mobile ML",
|
|
stakeholder: "Mobile product engineer",
|
|
hardware: "Hardware.Mobile.iPhone15Pro",
|
|
model: "Models.Vision.MobileNetV2",
|
|
metrics: "battery drain, thermal headroom, on-device latency, memory",
|
|
guardrails: "quality, privacy, responsiveness",
|
|
narrative: "Ship a responsive local model without overheating or draining the phone."
|
|
},
|
|
{
|
|
name: "Oura Ring",
|
|
category: "TinyML",
|
|
stakeholder: "Wearable firmware engineer",
|
|
hardware: "Hardware.Tiny.OuraRing",
|
|
model: "Models.Tiny.DS_CNN",
|
|
metrics: "energy per inference, SRAM/flash fit, duty cycle",
|
|
guardrails: "battery life, false alerts, OTA size",
|
|
narrative: "Fit sensing and inference inside a tiny battery and memory envelope."
|
|
},
|
|
{
|
|
name: "RoboTaxi",
|
|
category: "Edge AI",
|
|
stakeholder: "Autonomy systems engineer",
|
|
hardware: "Hardware.Edge.RoboTaxi",
|
|
model: "Models.Vision.YOLOv8_Nano",
|
|
metrics: "end-to-end p99 latency, sensor throughput, failover headroom",
|
|
guardrails: "safety, availability, robustness",
|
|
narrative: "Keep perception and decision support real-time under safety-critical edge constraints."
|
|
},
|
|
{
|
|
name: "Cloud Fleet",
|
|
category: "Cloud/Scale",
|
|
stakeholder: "Platform capacity engineer",
|
|
hardware: "Hardware.Cloud.H100",
|
|
model: "Models.Language.BERT_Base",
|
|
metrics: "throughput, p99 latency, cost per request, utilization",
|
|
guardrails: "SLA, reliability, security, carbon",
|
|
narrative: "Scale serving and training while controlling tail latency, cost, and fleet risk."
|
|
}
|
|
];
|
|
|
|
const trackArcs = [
|
|
{
|
|
name: "iPhone",
|
|
mission: "Ship a private on-device mobile ML feature.",
|
|
volume1: "Use each Volume I chapter to test whether the mobile feature still feels instant, private, battery-safe, and thermally sustainable.",
|
|
volume2: "Scale the same feature into a managed mobile fleet with updates, telemetry, privacy, robustness, sustainability, and fairness constraints.",
|
|
modelFamily: "MobileNet-class vision now; small local models when explicitly registered.",
|
|
carryForward: "Every lab should ask what preserves local UX under battery, thermal, memory, and latency limits."
|
|
},
|
|
{
|
|
name: "Oura Ring",
|
|
mission: "Fit sensing intelligence into a wearable power envelope.",
|
|
volume1: "Turn core systems ideas into SRAM, flash, OTA payload, duty-cycle, signal-quality, and battery decisions.",
|
|
volume2: "Treat the wearable as a constrained sensor fleet where privacy, reliability, updates, carbon, and fairness are bounded by tiny local resources.",
|
|
modelFamily: "DS-CNN, anomaly detection, and compact time-series classifiers.",
|
|
carryForward: "Every lab should make memory and energy feel concrete before students optimize accuracy."
|
|
},
|
|
{
|
|
name: "RoboTaxi",
|
|
mission: "Keep autonomous perception inside edge safety margins.",
|
|
volume1: "Use rare events, p99/p999 latency, sensor bandwidth, power, and fallback behavior to judge each deployment decision.",
|
|
volume2: "Scale from one vehicle to an autonomy fleet where orchestration, failure recovery, privacy, robustness, carbon, and fairness are safety-adjacent operations questions.",
|
|
modelFamily: "YOLOv8 Nano-class perception plus replay and rare-event workloads.",
|
|
carryForward: "Every lab should separate generic edge engineering from safety-critical autonomy validation."
|
|
},
|
|
{
|
|
name: "Cloud Fleet",
|
|
mission: "Operate a model service under fleet-scale constraints.",
|
|
volume1: "Translate each ML systems concept into throughput, p99 latency, cost/request, utilization, capacity, quality, and carbon trade-offs.",
|
|
volume2: "Follow the service as it scales through infrastructure, communication, storage, training, inference, operations, privacy, robustness, carbon, and responsibility.",
|
|
modelFamily: "BERT/GPT/Llama-class service workloads chosen to expose scale constraints.",
|
|
carryForward: "Every lab should distinguish a single accelerator result from a service-level operating decision."
|
|
}
|
|
];
|
|
|
|
const coverage = [
|
|
["V1", "V1-00 Architect's Portal", "Orientation", "Track selection and constraint framing", "Students pick one canonical track; scenario, device family, model family, metrics, guardrails, and report framing follow that choice."],
|
|
["V1", "V1-01 The AI Triad", "Chapter 1", "Data/model/machine coupling", "The same intervention is judged against mobile heat, TinyML memory, RoboTaxi latency/safety, or cloud throughput/cost."],
|
|
["V1", "V1-02 Physics of Deployment", "Chapter 2", "Physical feasibility limits", "Each track exposes a different first wall: phone battery, ring SRAM, vehicle p99 latency, or fleet capacity."],
|
|
["V1", "V1-03 Constraint Tax", "Chapter 3", "Workflow constraints", "The selected device changes validation cadence, release policy, rollback risk, and what counts as deployment-ready evidence."],
|
|
["V1", "V1-04 Data Gravity", "Chapter 4", "Pipeline throughput and data movement", "Track workloads change where bytes move, which cache matters, and whether storage, preprocessing, network, or sensor ingress binds."],
|
|
["V1", "V1-05 Activation Tax", "Chapter 5", "Operator cost and activation memory", "Shape, precision, and tiling decisions are evaluated against unified memory, MCU SRAM, edge accelerator memory, or HBM."],
|
|
["V1", "V1-06 Architecture Tax", "Chapter 6", "Architecture family trade-offs", "CNN, efficient vision, TinyML, and transformer choices are scored against each track's model family and dominant constraint."],
|
|
["V1", "V1-07 Framework Tax", "Chapter 7", "Runtime overhead and operator support", "Students compare delegate/runtime support: mobile NPU, embedded kernels, vehicle edge stack, or cloud compiler path."],
|
|
["V1", "V1-08 Training Gauntlet", "Chapter 8", "Training and adaptation feasibility", "Training choices become local adaptation, tiny calibration, autonomy validation, or distributed/cloud fine-tuning depending on track."],
|
|
["V1", "V1-09 Selection Paradox", "Chapter 9", "Data utility, coverage, and subgroup risk", "Track context changes rare-event cost: phone UX, wearable false alerts, road edge cases, or cloud cohort coverage."],
|
|
["V1", "V1-10 Compression Paradox", "Chapter 10", "Quantization, pruning, distillation, Pareto feasibility", "Compression recipes are accepted only if the selected hardware supports the speed/energy win and preserves the guardrail."],
|
|
["V1", "V1-11 Hardware Roofline", "Chapter 11", "Roofline and accelerator fit", "The workload point moves across NPU, MCU/DSP, edge GPU, or H100 rooflines; students explain the active regime."],
|
|
["V1", "V1-12 Benchmarking Trap", "Chapter 12", "Benchmark protocol design", "Benchmark realism changes by track: sustained phone use, ring duty cycle, safety-critical vehicle stream, or fleet SLA load."],
|
|
["V1", "V1-13 Tail Latency Trap", "Chapter 13", "Serving queues and capacity", "Students tune batching, cache, replicas, and admission against interactive latency, duty cycle, real-time edge, or cloud p99."],
|
|
["V1", "V1-14 Silent Degradation", "Chapter 14", "Monitoring, drift, retraining, rollback", "The monitor and response plan changes with local signals, wearable labels, autonomy incidents, or fleet observability."],
|
|
["V1", "V1-15 No Free Fairness", "Chapter 15", "Responsible constraints as systems constraints", "Fairness, privacy, robustness, carbon, and audit costs are evaluated under the selected track's deployment obligations."],
|
|
["V1", "V1-16 Architect's Audit", "Chapter 16", "End-to-end architecture memo", "The final Volume I ledger replays the chosen track and asks students to defend the most fragile system decision."],
|
|
["V2", "V2-01 Scale Illusion", "Volume II Chapter 1", "Scaling failure modes", "Track scale means device fleet, wearable population, autonomy fleet, or cloud cluster; useful work and coordination tax differ."],
|
|
["V2", "V2-02 Compute Wall", "Volume II Chapter 2", "Infrastructure capacity and procurement", "Hardware planning maps to local silicon limits, embedded bill of materials, vehicle edge compute, or accelerator fleet capacity."],
|
|
["V2", "V2-03 Fabric Design", "Volume II Chapter 3", "Network fabric and topology", "Communication is BLE/mobile uplink, wearable sync, vehicle sensor/fleet network, or cloud fabric and collective traffic."],
|
|
["V2", "V2-04 Data Pipeline Wall", "Volume II Chapter 4", "Storage and data pipeline architecture", "The bottleneck becomes local storage, tiny logs, sensor data lake ingress, or distributed object-store throughput."],
|
|
["V2", "V2-05 Parallelism Design", "Volume II Chapter 5", "Distributed training memory and parallelism", "Students choose whether the track calls for no training, local adaptation, edge retraining, or large-scale parallel training."],
|
|
["V2", "V2-06 Communication Lab", "Volume II Chapter 6", "Collective communication algorithms", "Payload, topology, and overlap choices are interpreted through device sync, edge/fleet aggregation, or cloud collective operations."],
|
|
["V2", "V2-07 Failure Budget Engineering", "Volume II Chapter 7", "Reliability, checkpointing, recovery", "Failure exposure is battery/session loss, wearable OTA risk, vehicle failover, or cloud job/fleet interruption."],
|
|
["V2", "V2-08 Scheduling Under Constraint", "Volume II Chapter 8", "Fleet orchestration and scheduling", "Schedulers manage on-device work, tiny duty cycles, edge compute contention, or cloud accelerator queue fairness."],
|
|
["V2", "V2-09 Optimization Trap", "Volume II Chapter 9", "Performance diagnosis and stop rules", "Optimization ladders stop when the next gain harms battery, memory, safety validation, reliability, or engineering cost."],
|
|
["V2", "V2-10 Serving Cost Inversion", "Volume II Chapter 10", "Inference economics", "Serving cost is local battery, wearable duty cycle, vehicle compute budget, or cloud request economics and utilization."],
|
|
["V2", "V2-11 Edge Thermodynamics", "Volume II Chapter 11", "Placement, adaptation, federation", "Students decide local, edge, cloud, or hybrid placement with track-specific latency, privacy, energy, and safety constraints."],
|
|
["V2", "V2-12 Silent Fleet", "Volume II Chapter 12", "Operations at scale", "Operational load changes from app rollout, wearable firmware, autonomy fleet monitoring, or cloud platform automation."],
|
|
["V2", "V2-13 Price of Privacy", "Volume II Chapter 13", "Security and privacy overhead", "Controls are chosen for phone privacy, wearable health data, vehicle safety/security, or cloud tenant protection."],
|
|
["V2", "V2-14 Robustness Budget", "Volume II Chapter 14", "Robustness and fallback design", "Robustness tax is judged against mobile UX, wearable false positives, autonomy edge cases, or cloud abuse/drift."],
|
|
["V2", "V2-15 Carbon Budget", "Volume II Chapter 15", "Energy, carbon, and placement", "Carbon and energy accounting spans device charging, tiny battery life, vehicle power, and cloud region/time-shift decisions."],
|
|
["V2", "V2-16 Fairness Budget", "Volume II Chapter 16", "Governance and feedback loops", "Governance plans differ by consumer app, health wearable, autonomous service, or cloud-scale product policy."],
|
|
["V2", "V2-17 Fleet Synthesis", "Volume II Chapter 17", "Final fleet design review", "The final report defends a track-specific architecture, top risk, validation plan, and residual system trade-off."]
|
|
];
|
|
|
|
const activities = [
|
|
["V1", "V1-00 Orientation, Architect's Portal", "Track and scenario", "Deployment tracks: Mobile ML, TinyML, Edge AI, Cloud/Scale", "Student selects a track and sees default model, hardware, workload, and constraints", "Scenario registry, track-compatible defaults, hardware/model/workload IDs"],
|
|
["V1", "V1-00 Orientation, Architect's Portal", "Part A: Constraint portrait", "How each track changes the dominant resource budget", "Radar or budget chart comparing memory, latency, energy, cost, reliability, privacy", "Track resource budget summaries"],
|
|
["V1", "V1-00 Orientation, Architect's Portal", "Part B: Same model, different world", "Same model can be feasible in one context and impossible in another", "Sweep one model across all tracks and show feasible/infeasible cells", "Feasibility solver over multiple scenarios"],
|
|
["V1", "V1-00 Orientation, Architect's Portal", "Part C: Engineering lens", "Student commits to a track and initial bottleneck hypothesis", "Save track, scenario seed, and expected constraint in ledger", "Lab layer ledger; MLSysIM scenario ID"],
|
|
["V1", "V1-01 Introduction, The AI Triad", "Part A: Diagnose data/model/machine", "D.A.M coupling and bottleneck attribution", "Sliders for data quality, model size, and hardware; solver names active bottleneck", "D.A.M scenario result with bottleneck field"],
|
|
["V1", "V1-01 Introduction, The AI Triad", "Part B: Intervention frontier", "Data investment versus model change versus hardware upgrade", "Fixed budget allocation produces accuracy, latency, and cost frontier", "Intervention sweep API and cost model"],
|
|
["V1", "V1-01 Introduction, The AI Triad", "Part C: Defensible fix", "Choosing the first system intervention", "Student selects intervention and records why alternatives are worse", "Ledger entry references MLSysIM result snapshot"],
|
|
["V1", "V1-02 ML Systems, Physics of Deployment", "Part A: First wall", "Memory, compute, bandwidth, power, energy, and distance limits", "Run scenario against track hardware and show first violated wall", "Physical feasibility and wall attribution model"],
|
|
["V1", "V1-02 ML Systems, Physics of Deployment", "Part B: Physics curve", "Workload scaling against physical limits", "Sweep batch, sequence length, image size, or distance; plot threshold crossings", "Compute/memory/bandwidth/energy/latency equations"],
|
|
["V1", "V1-02 ML Systems, Physics of Deployment", "Part C: Deployment choice", "Local, edge, or cloud placement under hard constraints", "Student chooses placement and mitigation for avoided wall", "Placement feasibility model"],
|
|
["V1", "V1-03 ML Workflow, Constraint Tax", "Part A: Constraint propagation", "Deployment constraints flow backward into data, training, validation, release", "Scenario graph highlights constrained workflow stages", "Workflow dependency and stage-cost model"],
|
|
["V1", "V1-03 ML Workflow, Constraint Tax", "Part B: Iteration frontier", "Iteration speed versus confidence/risk", "Sliders for validation depth, data size, automation, hardware; plot iteration/risk curve", "Iteration cost and risk model"],
|
|
["V1", "V1-03 ML Workflow, Constraint Tax", "Part C: Workflow policy", "Release and validation strategy as system design", "Student chooses validation, retraining, and release policy", "Ledger schema for workflow decisions"],
|
|
["V1", "V1-04 Data Engineering, Data Gravity", "Part A: Feed the model", "Ingest, preprocessing, transfer, and compute starvation", "Pipeline diagram with throughput at each stage and accelerator utilization", "Data pipeline throughput model"],
|
|
["V1", "V1-04 Data Engineering, Data Gravity", "Part B: Data movement frontier", "Move data, move compute, compress, cache, or sample less", "Compare placement and cache strategies on cost/latency frontier", "Data movement, storage, cache, and placement APIs"],
|
|
["V1", "V1-04 Data Engineering, Data Gravity", "Part C: Pipeline architecture", "Data architecture decision and residual failure mode", "Student chooses preprocessing location, cache policy, and retention", "Pipeline configuration result object"],
|
|
["V1", "V1-05 Neural Computation, Activation Tax", "Part A: Operation ledger", "Parameters, activations, MACs, and bytes moved", "Pick layer/network shape and see weights, activations, ops, memory traffic", "Operator cost model"],
|
|
["V1", "V1-05 Neural Computation, Activation Tax", "Part B: Memory cliff", "Activations can dominate weights and exceed memory", "Sweep width, resolution, sequence length, batch; show SRAM/DRAM/HBM cliffs", "Activation and memory hierarchy model"],
|
|
["V1", "V1-05 Neural Computation, Activation Tax", "Part C: Layer design", "Fit an operator to a deployment constraint", "Student chooses shape/precision/tiling and explains sacrifice", "Operator feasibility solver"],
|
|
["V1", "V1-06 Network Architectures, Architecture Tax", "Part A: Architecture signature", "CNN, MLP, RNN, transformer, efficient variants have different resource signatures", "Side-by-side cost table by architecture and track", "Architecture cost model"],
|
|
["V1", "V1-06 Network Architectures, Architecture Tax", "Part B: Scaling shape", "Linear, quadratic, width-squared, and resolution scaling", "Sweep the expensive variable and plot growth curves", "Architecture scaling functions"],
|
|
["V1", "V1-06 Network Architectures, Architecture Tax", "Part C: Architecture choice", "Choose architecture based on workload and constraint", "Student selects architecture and predicts next scaling failure", "Architecture feasibility and risk fields"],
|
|
["V1", "V1-07 ML Frameworks, Framework Tax", "Part A: Dispatch tax", "Eager execution, kernel launch, synchronization, and transfer overhead", "Many-small-ops versus fused-ops latency stack", "Runtime overhead model"],
|
|
["V1", "V1-07 ML Frameworks, Framework Tax", "Part B: Fusion and compile break-even", "Compilation/fusion pays off only after enough reuse", "Sweep inference count, shape dynamism, fusion depth; plot break-even", "Compile amortization and fusion model"],
|
|
["V1", "V1-07 ML Frameworks, Framework Tax", "Part C: Runtime choice", "Framework/runtime/delegate selection under deployment constraints", "Student chooses runtime path and notes portability/operator risk", "Runtime support registry"],
|
|
["V1", "V1-08 Model Training, Training Gauntlet", "Part A: Training memory budget", "Weights, gradients, optimizer state, activations, and data pipeline", "Stack chart shows memory components and infeasible pieces", "Training memory model"],
|
|
["V1", "V1-08 Model Training, Training Gauntlet", "Part B: Feasibility knobs", "Batch, precision, checkpointing, accumulation, optimizer", "Sweep knobs to produce speed versus memory frontier", "Training throughput/memory solver"],
|
|
["V1", "V1-08 Model Training, Training Gauntlet", "Part C: Training plan", "Choose fine-tuning/training/adaptation strategy", "Student records plan, convergence risk, and hidden cost", "Training plan result schema"],
|
|
["V1", "V1-09 Data Selection, Selection Paradox", "Part A: Quality versus quantity", "More data versus better data versus cheaper data", "Dataset size/noise/label quality sliders produce utility-cost frontier", "Data utility and training-cost model"],
|
|
["V1", "V1-09 Data Selection, Selection Paradox", "Part B: Coverage and inequality", "Overall accuracy can hide subgroup failure", "Selection policy changes subgroup heatmap and global metric", "Coverage/subgroup risk model"],
|
|
["V1", "V1-09 Data Selection, Selection Paradox", "Part C: Data policy", "Acquisition, curation, filtering, and rare-event policy", "Student chooses data policy and accepted bias/coverage risk", "Data policy schema for later responsible labs"],
|
|
["V1", "V1-10 Model Compression, Compression Paradox", "Part A: Compression feasibility", "Quantization, pruning, distillation, and hardware support", "Apply methods and see size, latency, energy, and quality deltas", "Compression model and kernel support registry"],
|
|
["V1", "V1-10 Model Compression, Compression Paradox", "Part B: Compression frontier", "Smaller can be slower or less robust if unsupported", "Sweep bit width/sparsity/student size; show Pareto frontier", "Compression-quality-runtime sweep"],
|
|
["V1", "V1-10 Model Compression, Compression Paradox", "Part C: Compression recipe", "Choose validated compression strategy", "Student selects recipe and validation test before deployment", "Compression result and validation schema"],
|
|
["V1", "V1-11 Hardware Acceleration, Hardware Roofline", "Part A: Roofline diagnosis", "Compute-bound, bandwidth-bound, and memory-bound regimes", "Plot workload point on roofline with active regime", "Roofline model"],
|
|
["V1", "V1-11 Hardware Acceleration, Hardware Roofline", "Part B: Move the point", "Tiling, fusion, batching, precision, and reuse", "Before/after roofline position plus latency/energy delta", "Arithmetic intensity and memory traffic transforms"],
|
|
["V1", "V1-11 Hardware Acceleration, Hardware Roofline", "Part C: Accelerator decision", "Choose CPU/GPU/NPU/TPU/MCU accelerator", "Student selects hardware and remaining limitation", "Hardware comparison and feasibility solver"],
|
|
["V1", "V1-12 Benchmarking, Benchmarking Trap", "Part A: Benchmark illusion", "Peak, component, warm, and deployment-like benchmarks disagree", "Compare easy benchmark to deployment workload", "Benchmark workload model"],
|
|
["V1", "V1-12 Benchmarking, Benchmarking Trap", "Part B: Multi-metric trade-off", "Throughput, latency, energy, accuracy, cost, and tails conflict", "Optimize one metric and watch others move", "Metric aggregation and queueing/thermal model"],
|
|
["V1", "V1-12 Benchmarking, Benchmarking Trap", "Part C: Benchmark protocol", "Design a benchmark that catches the real failure", "Student selects workload, duration, warmup, metrics, guardrails", "Benchmark protocol schema"],
|
|
["V1", "V1-13 Model Serving, Tail Latency Trap", "Part A: Queueing failure", "Utilization and burstiness explode tail latency", "Arrival/service sliders produce p50/p95/p99 curve", "Queueing model"],
|
|
["V1", "V1-13 Model Serving, Tail Latency Trap", "Part B: Serving knobs", "Batching, autoscaling, cache, replicas, cold starts", "Sweep policies to plot latency/cost/throughput frontier", "Serving solver"],
|
|
["V1", "V1-13 Model Serving, Tail Latency Trap", "Part C: Capacity plan", "Choose serving configuration and protected failure mode", "Student records batching, autoscaling, cache, and risk", "Serving configuration schema"],
|
|
["V1", "V1-14 ML Operations, Silent Degradation", "Part A: Drift visibility", "Drift may happen before labels or monitors notice it", "Timeline of true quality, observed signal, alert, damage", "Drift and monitoring model"],
|
|
["V1", "V1-14 ML Operations, Silent Degradation", "Part B: Retraining cadence", "Undertraining and overtraining both cost money/risk", "Retrain frequency sweep gives total cost curve", "Retraining cost/risk model"],
|
|
["V1", "V1-14 ML Operations, Silent Degradation", "Part C: Ops policy", "Monitoring, retraining, rollback, escalation", "Student chooses operational policy and residual blind spot", "Ops policy schema"],
|
|
["V1", "V1-15 Responsible Engineering, No Free Fairness", "Part A: Metric conflict", "Fairness metrics can be mutually incompatible", "Threshold sliders show accuracy, calibration, equality, subgroup error", "Fairness metric model"],
|
|
["V1", "V1-15 Responsible Engineering, No Free Fairness", "Part B: Responsibility budget", "Privacy, explainability, robustness, carbon add system overhead", "Add constraints and see quality/cost/latency/fairness stack", "Responsible constraint overhead models"],
|
|
["V1", "V1-15 Responsible Engineering, No Free Fairness", "Part C: Responsible decision", "Pick obligation, system change, cost, and evidence", "Student records responsible policy and audit signal", "Responsible decision schema"],
|
|
["V1", "V1-16 Conclusion, Architect's Audit", "Part A: Ledger replay", "Prior decisions imply an end-to-end architecture", "Load ledger or preset and render architecture map", "Lab ledger plus MLSysIM scenario solver"],
|
|
["V1", "V1-16 Conclusion, Architect's Audit", "Part B: Sensitivity audit", "Decisions break under workload, model, or constraint changes", "Perturb knobs and show fragility heatmap", "Sensitivity solver"],
|
|
["V1", "V1-16 Conclusion, Architect's Audit", "Part C: Architecture memo", "Revise one decision and state the principle", "Student writes final architecture decision and top risk", "Result snapshot export"],
|
|
["V2", "V2-01 Introduction, Scale Illusion", "Part A: Scaling illusion", "Linear assumptions fail as devices/users/accelerators grow", "Sweep fleet/cluster size and show reliability/cost collapse", "Scale reliability and cost model"],
|
|
["V2", "V2-01 Introduction, Scale Illusion", "Part B: Coordination tax", "Coordination reduces useful work", "Sliders for sync, monitoring, retries, heterogeneity; useful-work plot", "Coordination overhead model"],
|
|
["V2", "V2-01 Introduction, Scale Illusion", "Part C: Scale readiness", "Decide whether to scale, shard, specialize, or simplify", "Student chooses scale plan and first mitigation", "Scale decision schema"],
|
|
["V2", "V2-02 Compute Infrastructure, Compute Wall", "Part A: Node feasibility", "Hardware fit across memory, bandwidth, compute, power", "Run workload on candidate hardware and show active wall", "Hardware feasibility solver"],
|
|
["V2", "V2-02 Compute Infrastructure, Compute Wall", "Part B: Infrastructure frontier", "TCO, latency, throughput, utilization, power", "Sweep accelerator tier/node count/utilization and plot frontier", "Infrastructure TCO and capacity model"],
|
|
["V2", "V2-02 Compute Infrastructure, Compute Wall", "Part C: Procurement/placement", "Choose hardware tier and invalidation assumption", "Student records hardware plan and risk trigger", "Hardware plan schema"],
|
|
["V2", "V2-03 Network Fabrics, Fabric Design", "Part A: Fabric budget", "Link bandwidth, latency, topology, bisection cliff", "Compare HBM/NVLink/InfiniBand/Ethernet budgets", "Network fabric model"],
|
|
["V2", "V2-03 Network Fabrics, Fabric Design", "Part B: Topology frontier", "Fat tree, torus, dragonfly, Ethernet, InfiniBand, and hierarchy trade-offs", "Sweep node count, bisection bandwidth, hop count, and oversubscription", "Topology and network fabric model"],
|
|
["V2", "V2-03 Network Fabrics, Fabric Design", "Part C: Fabric decision", "Choose network fabric and placement assumption", "Student records topology, bandwidth assumption, placement constraint, and risk", "Fabric strategy schema"],
|
|
["V2", "V2-04 Data Storage, Data Pipeline Wall", "Part A: Storage-compute gap", "Storage bandwidth can starve accelerators", "Pipeline chart comparing storage/preprocess/compute demand", "Storage pipeline model"],
|
|
["V2", "V2-04 Data Storage, Data Pipeline Wall", "Part B: Sharding/cache frontier", "Shards, prefetch, cache, workers, locality", "Sweep storage strategy; plot stall rate versus cost", "Sharding/cache/contention model"],
|
|
["V2", "V2-04 Data Storage, Data Pipeline Wall", "Part C: Storage architecture", "Storage and checkpoint architecture decision", "Student chooses shard/cache/checkpoint policy", "Storage architecture schema"],
|
|
["V2", "V2-05 Distributed Training, Parallelism Design", "Part A: Memory fit", "Model states and activations force sharding", "Memory stack across weights, gradients, optimizer, activations", "Distributed training memory model"],
|
|
["V2", "V2-05 Distributed Training, Parallelism Design", "Part B: Parallelism frontier", "Data, tensor, pipeline, ZeRO/FSDP, hybrid 3D", "Sweep parallel degrees; plot memory/throughput/communication frontier", "Distributed training solver"],
|
|
["V2", "V2-05 Distributed Training, Parallelism Design", "Part C: Training architecture", "Pick parallelism plan and new bottleneck", "Student records plan, scaling limit, communication assumption", "Parallelism plan schema"],
|
|
["V2", "V2-06 Collective Communication, Communication Lab", "Part A: Collective operation anatomy", "AllReduce, AllGather, ReduceScatter, Broadcast", "Interactive operation diagram with bytes and rounds", "Collective operation primitives"],
|
|
["V2", "V2-06 Collective Communication, Communication Lab", "Part B: Algorithm/topology frontier", "Ring/tree/hierarchical algorithms under real topology", "Crossover plot with latency and bandwidth terms", "Alpha-beta topology model"],
|
|
["V2", "V2-06 Collective Communication, Communication Lab", "Part C: Overlap/compression decision", "Compression, overlap, hierarchy, and staleness trade-offs", "Student chooses communication optimization and residual risk", "Communication optimization schema"],
|
|
["V2", "V2-07 Fault Tolerance, Failure Budget Engineering", "Part A: Failure exposure", "Fleet size and job duration raise failure probability", "Sweep MTBF/fleet/job duration; probability of clean completion", "Reliability model"],
|
|
["V2", "V2-07 Fault Tolerance, Failure Budget Engineering", "Part B: Recovery frontier", "Checkpoint interval, async checkpoints, replication, retries", "Useful work versus recovery overhead curve", "Checkpoint/recovery model"],
|
|
["V2", "V2-07 Fault Tolerance, Failure Budget Engineering", "Part C: Resilience policy", "Choose failure budget and recovery strategy", "Student records covered and uncovered failures", "Resilience policy schema"],
|
|
["V2", "V2-08 Fleet Orchestration, Scheduling Under Constraint", "Part A: Queue/utilization wall", "High utilization increases wait and SLA failures", "Job arrival/size sliders produce queue and utilization chart", "Scheduler queueing model"],
|
|
["V2", "V2-08 Fleet Orchestration, Scheduling Under Constraint", "Part B: Fragmentation/preemption frontier", "Packing, fragmentation, preemption, heterogeneity conflict", "Simulate scheduler policies and rejected work", "Bin-packing and preemption model"],
|
|
["V2", "V2-08 Fleet Orchestration, Scheduling Under Constraint", "Part C: Fleet policy", "Choose scheduler, admission, preemption, priority", "Student records scheduling policy and fairness trade-off", "Scheduling policy schema"],
|
|
["V2", "V2-09 Performance Engineering, Optimization Trap", "Part A: Bottleneck diagnosis", "Roofline, memory wall, kernel overhead, communication", "Profile view with active bottleneck and time breakdown", "Performance diagnostic solver"],
|
|
["V2", "V2-09 Performance Engineering, Optimization Trap", "Part B: Optimization ladder", "Fusion, layout, precision, attention kernels, overlap", "Apply optimizations in sequence; waterfall and new bottleneck", "Optimization transform model"],
|
|
["V2", "V2-09 Performance Engineering, Optimization Trap", "Part C: Stop rule", "Stop when marginal gain is not worth cost/risk", "Student records optimization order and stop criterion", "Optimization decision schema"],
|
|
["V2", "V2-10 Inference at Scale, Serving Cost Inversion", "Part A: Cost inversion", "Inference can dominate training cost over demand", "Cumulative training versus inference cost curve", "Inference cost model"],
|
|
["V2", "V2-10 Inference at Scale, Serving Cost Inversion", "Part B: State/batching frontier", "KV cache, continuous batching, replicas, routing", "Sweep sequence/concurrency/cache/batch policy", "Inference serving solver"],
|
|
["V2", "V2-10 Inference at Scale, Serving Cost Inversion", "Part C: Serving fleet", "Choose local/edge/cloud/fleet serving architecture", "Student records batching/cache/capacity policy", "Serving fleet schema"],
|
|
["V2", "V2-11 Edge Intelligence, Edge Thermodynamics", "Part A: Placement feasibility", "Device-edge-cloud split under latency, privacy, energy", "Pipeline split diagram with latency and energy annotations", "Placement solver"],
|
|
["V2", "V2-11 Edge Intelligence, Edge Thermodynamics", "Part B: Adaptation/federation frontier", "Local adaptation, centralized retrain, federated learning", "Compare quality versus communication/energy/privacy", "Adaptation and federated communication model"],
|
|
["V2", "V2-11 Edge Intelligence, Edge Thermodynamics", "Part C: Edge architecture", "Choose local, edge, cloud, or hybrid architecture", "Student records placement, adaptation, and privacy assumption", "Edge architecture schema"],
|
|
["V2", "V2-12 Ops at Scale, Silent Fleet", "Part A: Complexity growth", "Models/sites/services outgrow manual operations", "Scale model count/site count; operational load chart", "Ops complexity model"],
|
|
["V2", "V2-12 Ops at Scale, Silent Fleet", "Part B: Canary/automation frontier", "Canary duration, false alerts, detection speed, platform ROI", "Sweep canary and alert thresholds; plot detection versus false alerts/cost", "Canary, alert, platform ROI models"],
|
|
["V2", "V2-12 Ops at Scale, Silent Fleet", "Part C: Ops architecture", "Monitoring, rollout, alerting, automation investment", "Student records ops policy and silent-failure risk", "Ops architecture schema"],
|
|
["V2", "V2-13 Security & Privacy, Price of Privacy", "Part A: Threat/privacy budget", "Attack surface and privacy budget across ML lifecycle", "Choose threat model/epsilon/logging; threat map updates", "Threat and privacy model"],
|
|
["V2", "V2-13 Security & Privacy, Price of Privacy", "Part B: Defense overhead frontier", "DP, encryption, secure aggregation, filtering, guardrails", "Add defenses; plot security/privacy strength versus quality/latency/cost", "Defense overhead model"],
|
|
["V2", "V2-13 Security & Privacy, Price of Privacy", "Part C: Security/privacy policy", "Pick controls and residual risk", "Student records controls, cost, residual attack/leakage", "Security/privacy schema"],
|
|
["V2", "V2-14 Robust AI, Robustness Budget", "Part A: Robustness tax", "Robust training, augmentation, ensembling, abstention cost", "Add defenses and see clean/robust accuracy, latency, cost", "Robustness cost model"],
|
|
["V2", "V2-14 Robust AI, Robustness Budget", "Part B: Drift/silent error timeline", "Distribution shift and silent errors before detection", "Drift timeline with monitors and accumulated harm/cost", "Drift/robustness model"],
|
|
["V2", "V2-14 Robust AI, Robustness Budget", "Part C: Defense stack", "Choose defenses, fallback, and monitoring signal", "Student records defense stack and expected tax", "Robust defense schema"],
|
|
["V2", "V2-15 Sustainable AI, Carbon Budget", "Part A: Energy/carbon measurement", "Operational energy and carbon by hardware/workload/region", "Energy/carbon budget stack", "Energy and carbon model"],
|
|
["V2", "V2-15 Sustainable AI, Carbon Budget", "Part B: Placement/lifecycle frontier", "Geography, time shifting, utilization, embodied carbon", "Carbon versus cost/latency/reliability frontier", "Lifecycle carbon and placement model"],
|
|
["V2", "V2-15 Sustainable AI, Carbon Budget", "Part C: Carbon-aware policy", "Scheduling, placement, compression, caps, rebound risk", "Student records carbon policy and accepted trade-off", "Carbon policy schema"],
|
|
["V2", "V2-16 Responsible AI, Fairness Budget", "Part A: Metric conflict and feedback", "Fairness impossibility and feedback loops at scale", "Threshold/policy sliders show metric conflict and feedback timeline", "Fairness/feedback model"],
|
|
["V2", "V2-16 Responsible AI, Fairness Budget", "Part B: Governance overhead", "Audit depth, approval gates, red-team review, incident response", "Risk reduction versus operational overhead frontier", "Governance cost/risk model"],
|
|
["V2", "V2-16 Responsible AI, Fairness Budget", "Part C: Responsible AI pipeline", "Choose audit/governance pipeline and unresolved conflict", "Student records metric, pipeline, overhead, conflict", "Governance pipeline schema"],
|
|
["V2", "V2-17 Conclusion, Fleet Synthesis", "Part A: Fleet ledger replay", "Prior decisions imply fleet architecture", "Load ledger/preset and render architecture map", "Lab ledger plus fleet solver"],
|
|
["V2", "V2-17 Conclusion, Fleet Synthesis", "Part B: Interaction map", "Constraints interact across compute/network/storage/ops/responsibility", "Perturb demand, failure, privacy, carbon; show interaction map", "Sensitivity and interaction solver"],
|
|
["V2", "V2-17 Conclusion, Fleet Synthesis", "Part C: Final design review", "Defensible fleet architecture and top risk", "Student records final blueprint, top risk, mitigation", "Result export schema"]
|
|
];
|
|
|
|
const apis = [
|
|
["Scenarios", "Track-compatible deployment scenarios, independent of curriculum wording.", "All labs and book examples"],
|
|
["Workloads", "Request, stream, training, storage, and data distributions.", "Serving, training, storage, benchmarking, ops"],
|
|
["Engine.solve()", "Common feasibility, bottleneck, latency, memory, energy, cost result.", "Most labs"],
|
|
["Engine.sweep()", "Produce trade-off curves/frontiers from parameter ranges.", "Every Part B"],
|
|
["BottleneckReport", "Name active constraint, next constraint, and violated budgets.", "Every Part A"],
|
|
["ParetoFrontier", "Mark dominated/non-dominated configurations.", "Every Part B"],
|
|
["SensitivityReport", "Show which design choices break under perturbation.", "Synthesis labs"],
|
|
["TrainingSystemModel", "Memory, throughput, parallelism, optimizer, checkpointing.", "V1 training, V2 distributed training"],
|
|
["ServingSystemModel", "Queueing, batching, cache, replicas, cold starts, cost.", "V1 serving, V2 inference"],
|
|
["CommunicationModel", "Fabric bandwidth/latency, collective algorithms, hierarchy.", "V2 network, collectives, training"],
|
|
["StoragePipelineModel", "Shards, cache, prefetch, checkpoint IO, accelerator starvation.", "V1 data, V2 storage"],
|
|
["ReliabilityModel", "MTBF, failure probability, recovery, useful work.", "V2 scale, fault tolerance, conclusion"],
|
|
["OpsModel", "Drift, monitoring, canary, alert fatigue, platform ROI.", "V1 MLOps, V2 Ops"],
|
|
["ResponsibleSystemsModel", "Fairness, privacy, security, robustness, carbon, governance overhead.", "Responsible, safety, sustainability labs"]
|
|
];
|
|
|
|
const state = {
|
|
volume: "all",
|
|
search: ""
|
|
};
|
|
|
|
function escapeHtml(value) {
|
|
return String(value)
|
|
.replaceAll("&", "&")
|
|
.replaceAll("<", "<")
|
|
.replaceAll(">", ">")
|
|
.replaceAll('"', """)
|
|
.replaceAll("'", "'");
|
|
}
|
|
|
|
function renderConcepts() {
|
|
const body = document.getElementById("conceptBody");
|
|
body.innerHTML = concepts.map(([concept, learn, responsibility]) => `
|
|
<tr>
|
|
<td data-label="Concept"><span class="chapter">${escapeHtml(concept)}</span></td>
|
|
<td data-label="What students need to learn">${escapeHtml(learn)}</td>
|
|
<td data-label="MLSysIM responsibility">${escapeHtml(responsibility)}</td>
|
|
</tr>
|
|
`).join("");
|
|
}
|
|
|
|
function renderTracks() {
|
|
const grid = document.getElementById("trackGrid");
|
|
grid.innerHTML = tracks.map((track) => `
|
|
<article class="track-card">
|
|
<h3>${escapeHtml(track.name)} <span class="muted">(${escapeHtml(track.category)})</span></h3>
|
|
<p>${escapeHtml(track.narrative)}</p>
|
|
<dl>
|
|
<dt>Stakeholder</dt>
|
|
<dd>${escapeHtml(track.stakeholder)}</dd>
|
|
<dt>Hardware</dt>
|
|
<dd><code>${escapeHtml(track.hardware)}</code></dd>
|
|
<dt>Model</dt>
|
|
<dd><code>${escapeHtml(track.model)}</code></dd>
|
|
<dt>Primary metrics</dt>
|
|
<dd>${escapeHtml(track.metrics)}</dd>
|
|
<dt>Guardrails</dt>
|
|
<dd>${escapeHtml(track.guardrails)}</dd>
|
|
</dl>
|
|
</article>
|
|
`).join("");
|
|
}
|
|
|
|
function renderTrackArcs() {
|
|
const grid = document.getElementById("arcGrid");
|
|
grid.innerHTML = trackArcs.map((arc) => `
|
|
<article class="track-card">
|
|
<h3>${escapeHtml(arc.name)}</h3>
|
|
<p>${escapeHtml(arc.mission)}</p>
|
|
<dl>
|
|
<dt>Volume I</dt>
|
|
<dd>${escapeHtml(arc.volume1)}</dd>
|
|
<dt>Volume II</dt>
|
|
<dd>${escapeHtml(arc.volume2)}</dd>
|
|
<dt>Model family</dt>
|
|
<dd>${escapeHtml(arc.modelFamily)}</dd>
|
|
<dt>Carry forward</dt>
|
|
<dd>${escapeHtml(arc.carryForward)}</dd>
|
|
</dl>
|
|
</article>
|
|
`).join("");
|
|
}
|
|
|
|
function renderCoverage() {
|
|
const body = document.getElementById("coverageBody");
|
|
body.innerHTML = coverage.map(([volume, lab, chapter, concept, materialization]) => `
|
|
<tr>
|
|
<td data-label="Volume"><span class="tag ${volume === "V1" ? "v1" : "v2"}">${escapeHtml(volume)}</span></td>
|
|
<td data-label="Lab"><span class="chapter">${escapeHtml(lab)}</span></td>
|
|
<td data-label="Chapter anchor">${escapeHtml(chapter)}</td>
|
|
<td data-label="Core concept"><span class="activity-name">${escapeHtml(concept)}</span></td>
|
|
<td data-label="Track materialization">${escapeHtml(materialization)}</td>
|
|
</tr>
|
|
`).join("");
|
|
}
|
|
|
|
function rowMatches(row) {
|
|
const volumeOk = state.volume === "all" || row[0] === state.volume;
|
|
if (!volumeOk) return false;
|
|
if (!state.search) return true;
|
|
return row.join(" ").toLowerCase().includes(state.search);
|
|
}
|
|
|
|
function renderActivities() {
|
|
const rows = activities.filter(rowMatches);
|
|
const body = document.getElementById("activityBody");
|
|
const empty = document.getElementById("emptyState");
|
|
const count = document.getElementById("activityCount");
|
|
|
|
count.textContent = `${rows.length} of ${activities.length} activities`;
|
|
empty.hidden = rows.length !== 0;
|
|
body.innerHTML = rows.map(([volume, chapter, activity, covered, how, needs]) => `
|
|
<tr>
|
|
<td data-label="Volume"><span class="tag ${volume === "V1" ? "v1" : "v2"}">${escapeHtml(volume)}</span></td>
|
|
<td data-label="Chapter / Lab"><span class="chapter">${escapeHtml(chapter)}</span></td>
|
|
<td data-label="Activity"><span class="activity-name">${escapeHtml(activity)}</span></td>
|
|
<td data-label="What will be covered">${escapeHtml(covered)}</td>
|
|
<td data-label="How it will be covered">${escapeHtml(how)}</td>
|
|
<td data-label="MLSysIM needs"><span class="muted">${escapeHtml(needs)}</span></td>
|
|
</tr>
|
|
`).join("");
|
|
}
|
|
|
|
function renderApis() {
|
|
const grid = document.getElementById("apiGrid");
|
|
grid.innerHTML = apis.map(([name, purpose, usedBy]) => `
|
|
<div class="api-item">
|
|
<code>${escapeHtml(name)}</code>
|
|
<p>${escapeHtml(purpose)}</p>
|
|
<p><strong>Used by:</strong> ${escapeHtml(usedBy)}</p>
|
|
</div>
|
|
`).join("");
|
|
}
|
|
|
|
function bindControls() {
|
|
document.getElementById("searchBox").addEventListener("input", (event) => {
|
|
state.search = event.target.value.trim().toLowerCase();
|
|
renderActivities();
|
|
});
|
|
|
|
document.querySelectorAll(".segmented button").forEach((button) => {
|
|
button.addEventListener("click", () => {
|
|
state.volume = button.dataset.volume;
|
|
document.querySelectorAll(".segmented button").forEach((other) => {
|
|
other.setAttribute("aria-pressed", String(other === button));
|
|
});
|
|
renderActivities();
|
|
});
|
|
});
|
|
}
|
|
|
|
renderConcepts();
|
|
renderTracks();
|
|
renderTrackArcs();
|
|
renderCoverage();
|
|
renderActivities();
|
|
renderApis();
|
|
bindControls();
|
|
</script>
|
|
</body>
|
|
</html>
|