fix project documentation + one bit of domain->context transition

assets/site.css

@@ -346,6 +346,7 @@ pre code {
 .section {
     margin-bottom: 1.5rem;
     padding: 1.5rem;
+    scroll-margin-top: 1rem;
     border: 1px solid var(--color-light);
     border-radius: 16px;
     background-color: white;

build_site.py

@@ -42,7 +42,7 @@
     "student/pull-requests-and-reviews.md",
     "student/milestone-1-technical-design-and-repository.md",
     "student/milestone-2-proof-of-concept.md",
-    "student/week-10-checkpoint.md",
+    "student/week-11-checkpoint.md",
     "student/final-submission.md",
     "student/rubrics.md",
     "student/report-template.md",
@@ -54,6 +54,7 @@
     "projects/project-3-geospatial-intelligence.md",
     "projects/project-4-zoonotic-risk-prediction.md",
     "projects/project-5-rwanda-medical-assistant.md",
+    "projects/project-6-dengue-early-warning.md",
 ]
 
 PROJECT_DOCUMENTATION_ORDER = [
@@ -287,30 +288,33 @@ def parse_project_brief(path: Path) -> dict[str, str]:
 
 
 def build_project_brief_documents() -> list[dict[str, Any]]:
-    project_documents = []
+    project_sections = []
     for index, relative_path in enumerate(PROJECT_BRIEF_ORDER):
         content_path = PROJECT_DOCS_DIR / relative_path
         brief = parse_project_brief(content_path)
-        slug = slug_from_path(relative_path)
-        output_path = (
-            BUILD_DIR / "project-documentation" / "projects" / slug / "index.html"
-        )
-        project_documents.append(
+        _, body, _ = load_markdown_page(content_path)
+        title, body = extract_h1(body, brief["title"])
+        project_sections.append(
             {
-                "page_id": f"project-docs:{relative_path}",
-                "page_title": brief["title"],
-                "nav_title": brief["title"],
-                "page_heading": brief["title"],
-                "sidebar_group": "Project Briefs",
-                "content_path": content_path.relative_to(ROOT).as_posix(),
-                "output_path": output_path,
-                "order": 4 + index,
+                "title": title,
+                "anchor": slug_from_path(relative_path),
+                "html": render_markdown(body),
                 "lead": brief["lead"],
                 "team_size": brief["team_size"],
                 "short_description": brief["short_description"],
             }
         )
 
+    overview_section = {
+        "title": "Overview",
+        "anchor": "overview",
+        "html": render_markdown(build_project_brief_overview(project_sections)),
+    }
+    tabbed_documents = [overview_section, *project_sections]
+    for index, section in enumerate(tabbed_documents):
+        section["index"] = index
+        section["step"] = index + 1
+
     overview_output = BUILD_DIR / "project-documentation" / "projects" / "index.html"
     overview = {
         "page_id": "project-docs:briefs",
@@ -320,30 +324,41 @@ def build_project_brief_documents() -> list[dict[str, Any]]:
         "sidebar_group": "Project Briefs",
         "output_path": overview_output,
         "order": 3,
-        "body": build_project_brief_overview(project_documents, overview_output),
+        "tabbed_documents": tabbed_documents,
+        "no_pagination": True,
     }
-    return [overview, *project_documents]
+    return [overview]
 
 
-def build_project_brief_overview(
-    projects: list[dict[str, Any]], output_path: Path
-) -> str:
+def build_project_brief_overview(projects: list[dict[str, Any]]) -> str:
     rows = []
     for project in projects:
+        team_size = str(project.get("team_size", ""))
+        team_size = re.sub(r"\bstudents?\b", "", team_size, flags=re.IGNORECASE)
+        team_size = re.sub(r"\s+", " ", team_size).strip(" .,;")
+        project_number_match = re.match(r"Project\s+(\d+):", str(project["title"]))
+        project_label = (
+            f"Project {project_number_match.group(1)}"
+            if project_number_match
+            else str(project["title"])
+        )
         rows.append(
             (
-                f"[{project['page_title']}]({relative_url(output_path, project['output_path'])})",
-                str(project.get("lead", "")),
-                str(project.get("team_size", "")),
+                f"[{project_label}](#{project['anchor']})",
+                str(project["title"]),
+                team_size,
                 str(project.get("short_description", "")),
             )
         )
-    table = markdown_table(rows, ["Project", "Lead", "Team size", "Short description"])
+    table = markdown_table(
+        rows, ["Project", "Project title", "Team size", "Short description"]
+    )
     intro = (
-        "Each project has a full brief on its own page. "
-        "The table below summarizes all briefs."
+        "This page summarizes the proposed course projects. "
+        "Use the links below to jump to each full project brief. "
+        "Before writing Milestone 1, read your assigned project brief carefully and align your technical design with its proof-of-concept expectations."
     )
-    return f"{intro}\n\n{table}"
+    return f"{intro}\n\n{table}\n\nThe proof-of-concept expectations in your assigned brief are binding for Milestone 2."
 
 
 def markdown_table(rows: list[tuple[str, ...]], headers: list[str]) -> str:
@@ -570,6 +585,7 @@ def render_page(
         "page_heading": str(metadata.get("page_heading", "")),
         "sections": sections,
         "section_count": len(sections),
+        "no_pagination": bool(metadata.get("no_pagination")),
         "previous_week_url": (
             relative_url(output_path, previous_week["output_path"])
             if previous_week

content/pages/home.md

@@ -23,7 +23,7 @@ This course teaches the principles and practice of designing, building, and rigo
 
 ## Course Overview
 
-The course is organized into **three thematic blocks** plus a final symposium. Each teaching week pairs one domain lecture with one engineering lecture, then applies the week's ideas in a project studio.
+The course is organized into **three thematic blocks** plus a final symposium. Each teaching week pairs one context lecture with one engineering lecture, then applies the week's ideas in a project studio.
 
 {{ weeks_table }}
 
@@ -33,7 +33,7 @@ The course is organized into **three thematic blocks** plus a final symposium. E
 
 Students study humanitarian systems, community health, epidemics, and health systems, then translate these constraints into engineering decisions.
 
-**Domain themes**
+**Context themes**
 
 - Humanitarian systems
 - Community medicine
@@ -53,7 +53,7 @@ Students study humanitarian systems, community health, epidemics, and health sys
 
 Students explore how physicians reason, how decision support systems evolved, and why implementation is harder than engineering.
 
-**Domain themes**
+**Context themes**
 
 - Clinical reasoning
 - Diagnosis and triage
@@ -72,7 +72,7 @@ Students explore how physicians reason, how decision support systems evolved, an
 
 Students trace how medicine decided to trust systematic evidence over expert authority, from early clinical trials to the current crisis in clinical AI evaluation.
 
-**Domain themes**
+**Context themes**
 
 - Clinical trials
 - Implementation science
@@ -92,7 +92,7 @@ Students trace how medicine decided to trust systematic evidence over expert aut
 
 Students present final project outcomes and deployment-oriented documentation.
 
-**Domain themes**
+**Context themes**
 
 - Final synthesis
 - Project communication
@@ -108,7 +108,7 @@ Students present final project outcomes and deployment-oriented documentation.
 | Item | Description |
 |---|---|
 | Weeks | 14 |
-| Lectures | 24 paired lectures: 12 domain lectures and 12 technical lectures |
+| Lectures | 24 paired lectures: 12 context lectures and 12 engineering lectures |
 | Project studios | 10 studio sessions with senior engineers to guide AI system development |
 | Weekly workload | 2h lectures, 1h exercise, 12h project development, 1h independent study |
 | Presentations | Midterm presentation and final project presentation |
@@ -120,8 +120,8 @@ Students present final project outcomes and deployment-oriented documentation.
 
 | Session | Purpose |
 |---|---|
-| Domain lecture | What is the context of the problem we are solving? |
-| Engineering lecture | Translate domain concepts into engineering principles, algorithms, software, and deployment strategies. |
+| Context lecture | What is the context of the problem we are solving? |
+| Engineering lecture | Translate context concepts into engineering principles, algorithms, software, and deployment strategies. |
 | Studio | Apply the week's ideas to the semester-long project. |
 
 ## Assessment

content/project-documentation/README.md

@@ -11,22 +11,18 @@ This page collects the student-facing project documentation for the course.
 | [`student/pull-requests-and-reviews.md`](student/pull-requests-and-reviews.md) | Practical guide for PRs and teammate reviews |
 | [`student/milestone-1-technical-design-and-repository.md`](student/milestone-1-technical-design-and-repository.md) | Week 3 technical design and repository instructions and rubric |
 | [`student/milestone-2-proof-of-concept.md`](student/milestone-2-proof-of-concept.md) | Week 8 proof-of-concept instructions and rubric |
-| [`student/week-10-checkpoint.md`](student/week-10-checkpoint.md) | Non-graded checkpoint preparation guide |
+| [`student/week-11-checkpoint.md`](student/week-11-checkpoint.md) | Non-graded checkpoint preparation guide |
 | [`student/final-submission.md`](student/final-submission.md) | Week 14 final submission, report, and live demo requirements |
 | [`student/rubrics.md`](student/rubrics.md) | Consolidated project rubrics |
-| [`student/report-template.md`](student/report-template.md) | Suggested final report structure and individual contribution report guidance |
+| [`student/report-template.md`](student/report-template.md) | Suggested final report structure and contribution statement guidance |
 
 ## Project Briefs
 
-Each project brief has its own page. A quick summary of all briefs is shown on the Project Briefs overview page, which comes before the individual project pages.
+The Project Briefs page starts with an overview section that links to each project, followed by the full project briefs on the same page.
 
-| File | Project |
+| Page | Contents |
 |---|---|
-| [`projects/project-1-offline-translator.md`](projects/project-1-offline-translator.md) | Offline translator for low-resource languages |
-| [`projects/project-2-public-health-messenger.md`](projects/project-2-public-health-messenger.md) | Interactive public health messenger |
-| [`projects/project-3-geospatial-intelligence.md`](projects/project-3-geospatial-intelligence.md) | Geospatial intelligence for public health decisions |
-| [`projects/project-4-zoonotic-risk-prediction.md`](projects/project-4-zoonotic-risk-prediction.md) | AI-powered zoonotic disease risk prediction |
-| [`projects/project-5-rwanda-medical-assistant.md`](projects/project-5-rwanda-medical-assistant.md) | AI-powered medical assistant for health workers in Rwanda |
+| [`projects/`](projects/) | Overview and all project briefs |
 
 ## Confirmed Technical Baseline
 

content/project-documentation/projects/project-6-dengue-early-warning.md

@@ -0,0 +1,105 @@
+# Project 6: AI-Powered Dengue Early-Warning Platform
+
+Proposed team size: 5 students.
+
+Project lead: To be confirmed.
+
+Keywords: machine learning, time series forecasting, public health, data visualization, full-stack development, explainable AI.
+
+## Short Description
+
+Build an AI-powered dengue early-warning platform that predicts upcoming disease incidence and turns these forecasts into interpretable information that public health decision-makers can explore and use.
+
+## Motivation
+
+Dengue outbreaks can place substantial pressure on health systems. Anticipating increases in cases can help public health agencies prepare resources, plan interventions, and communicate risk earlier.
+
+This project is built around the DrivenData DengAI: Predicting Disease Spread challenge. The competition provides the machine-learning component, but the project goes beyond competition scoring. Students should develop rigorous temporal validation, compare forecasting approaches, and turn the model into a usable decision-support platform.
+
+The final prototype should demonstrate the complete pipeline from reproducible data processing and ML experimentation to an interpretable forecasting service that could support public-health decision-making.
+
+Challenge link: https://www.drivendata.org/competitions/44/dengai-predicting-disease-spread/
+
+## Intended Users
+
+Potential users include:
+
+- public health decision-makers;
+- epidemiological surveillance teams;
+- outbreak preparedness teams;
+- analysts comparing dengue risk across time and locations;
+- health agencies planning resources or interventions.
+
+## Possible Features
+
+Possible features include:
+
+- reproducible DengAI data ingestion and preprocessing;
+- temporal train, validation, and test splits;
+- comparison of baseline and stronger forecasting models;
+- backend endpoint serving forecasts;
+- interactive dashboard for historical incidence and forecasts;
+- visualization of environmental conditions;
+- uncertainty visualization;
+- explanation of factors influencing predictions;
+- forecast export or summary for decision-makers.
+
+The team should avoid treating the project as only a leaderboard exercise. The platform should make forecasts interpretable and usable.
+
+## Design Questions
+
+Consider:
+
+- What forecast horizon is most useful for a public health decision-maker?
+- What temporal validation strategy avoids future leakage?
+- Which baseline is meaningful for dengue incidence forecasting?
+- How should uncertainty be represented to non-technical users?
+- What environmental or seasonal factors appear to influence predictions?
+- How should the system distinguish historical observations from forecasts?
+- What action could a decision-maker take based on the dashboard?
+
+## Technical Directions
+
+Possible technical components include:
+
+- DrivenData DengAI dataset processing;
+- time series feature engineering;
+- baseline forecasting models;
+- machine learning models for incidence prediction;
+- temporal cross-validation or backtesting;
+- model explainability;
+- backend forecast service;
+- interactive dashboard;
+- visualization of historical cases, predicted cases, uncertainty, and drivers.
+
+## Proof-Of-Concept Expectation
+
+The proof of concept should demonstrate one valid dengue forecasting and decision-support path.
+
+Minimum convincing POC:
+
+- the system loads the DengAI data or a documented representative subset;
+- the team defines a clear forecast target, city, time unit, and forecast horizon;
+- the system uses a temporal split that avoids future leakage;
+- the system trains or runs at least one baseline forecasting model;
+- the system generates dengue incidence forecasts for a held-out period;
+- the forecasts are displayed in a simple dashboard or visualization alongside historical incidence;
+- the system shows at least one uncertainty, error, or explanation signal useful to a public health user.
+
+The POC may use one city, one baseline model, and a simple dashboard. It should not be only a competition notebook or only a static visualization without a reproducible forecasting path.
+
+## Evaluation Ideas
+
+Possible evaluation approaches include:
+
+- comparing against a seasonal or persistence baseline;
+- using temporal backtesting;
+- reporting the DrivenData metric and at least one interpretable error summary;
+- analyzing errors by season, city, or outbreak period;
+- evaluating calibration or uncertainty quality if uncertainty is provided;
+- checking whether explanations align with known temporal or environmental patterns;
+- testing whether the dashboard makes forecast limitations visible.
+
+## Final Demo Target
+
+The final demo should show the full path from data processing to forecast generation and dashboard exploration. A public health decision-maker should be able to inspect historical dengue incidence, predicted cases, uncertainty or error information, and explanations of important factors influencing the forecast.

content/project-documentation/student/final-submission.md

@@ -2,7 +2,7 @@
 
 Deadline: Friday of Week 14, December 18, 21:59.
 
-Weight: 40% of the course grade.
+Weight: 40% of the course grade, equivalent to 50% of the project grade.
 
 The final submission includes code, report, documentation, final presentation, and a live demo in front of the class.
 
@@ -17,7 +17,7 @@ Required final artifacts:
 - reproducibility instructions;
 - demo instructions;
 - final presentation material;
-- one individual contribution report per team member;
+- individual contribution statement signed by all team members;
 - handover or maintenance documentation.
 
 ## Final Report
@@ -40,22 +40,22 @@ The report should include:
 
 References and appendices do not count toward the 5-page limit. Appendices should support the report, not replace it.
 
-## Individual Contribution Reports
+## Individual Contribution Statement
 
-Your repository must include one short individual contribution report per team member.
+Your repository must include one signed team contribution statement.
 
-Each report should be written by the student whose contribution it describes. It should include:
+The statement should include:
 
-- main technical, design, evaluation, documentation, and presentation contributions;
+- each team member's main contributions;
+- major implementation, design, evaluation, writing, and presentation responsibilities;
 - links or references to relevant pull requests, issues, commits, experiments, or report sections;
-- decisions the student influenced and tradeoffs they handled;
-- parts of the project they reviewed, tested, debugged, or helped integrate;
-- any major blockers, handovers, or unfinished work relevant to their contribution.
+- any substantial deviations from the expected contribution distribution;
+- signatures or explicit signed approval from all team members.
 
 Recommended location:
 
 ```text
-docs/individual-reports/<student-name>.md
+docs/contribution-statement.md
 ```
 
 ## Final Presentation And Live Demo
@@ -127,4 +127,4 @@ Avoid:
 - reporting only successful examples;
 - hiding limitations;
 - making the report longer by moving core content to appendices;
-- submitting individual contribution reports that are vague or disconnected from repository evidence.
+- submitting a contribution statement that is vague, unsigned, or disconnected from repository evidence.