Project Briefs

Overview

This page summarizes the proposed course projects. Use the links below to jump to each full project brief.

Before preparing Milestone 1, read your assigned project brief carefully and align your technical design with its proof-of-concept expectations.

The proof-of-concept expectations of your project are binding for Milestone 2.

Offline Translator For Low-Resource Languages

Proposed team size: 4 students.

Project lead: TBD.

Short Description

Build an offline or low-connectivity translation assistant for settings where people need to communicate across languages despite unreliable internet access.

Motivation

A person is traveling, working, or responding in a setting where they do not speak the local language and internet access is unreliable. Existing tools such as downloadable translation models already exist, but the project asks whether the interaction can be made more useful, trustworthy, and participatory.

The challenge is not only translation quality. The challenge is communication under uncertainty.

Intended Users

Potential users include:

• humanitarian workers;
• health workers;
• travelers in low-connectivity settings;
• field teams working across languages;
• people who need translation support but cannot rely on live internet access.

Possible Features

Possible features include:

• text input and translation;
• audio recording;
• speech-to-text before translation;
• forward and backward translation;
• a way for the conversation partner to check whether the translation seems faithful;
• interaction with an LLM to discuss possible translations;
• delayed review of recorded utterances in a quieter or safer context;
• collaborative translation across a multi-turn conversation.

The team should not attempt all features. The technical design should identify a core use case and a realistic proof-of-concept path.

Design Questions

Consider:

• How does the interface communicate uncertainty in the translation?
• How can a conversation partner provide feedback without needing to speak English fluently?
• When is backtranslation helpful, and when can it be misleading?
• What happens when the system cannot confidently translate?
• What should work offline, and what can require optional connectivity?
• How should recordings be stored, deleted, or protected?

Technical Directions

Possible technical components include:

• local or downloadable translation models;
• speech-to-text;
• text-to-speech;
• LLM-assisted translation refinement;
• language identification;
• confidence or uncertainty display;
• lightweight user interface for field use.

The system should be designed so that the core path can run reproducibly in the project repository.

Proof-Of-Concept Expectation

The proof of concept should demonstrate one thin vertical slice through the translation workflow.

Minimum convincing POC:

• the user records or enters one utterance;
• the system processes the utterance through the translation path;
• the translated result is displayed to the user;
• the interface provides at least one mechanism for verification or refinement, such as backtranslation, alternative translations, partner confirmation, or LLM-assisted discussion;
• the system clearly indicates what part is real and what part is simulated.

The POC may use a simplified language pair, a small model, or sample audio. It should not be only a static UI mock-up.

Evaluation Ideas

Possible evaluation approaches include:

• comparing translation outputs against reference translations for a small test set;
• measuring whether backtranslation catches obvious translation failures;
• qualitative review of interaction flows;
• testing whether the user can recover from an uncertain or wrong translation;
• latency and offline-readiness checks;
• privacy and data retention analysis for recordings.

Final Demo Target

The final demo should show a short conversation or exchange in which the system helps a user translate, verify, and refine meaning under constrained conditions.

Interactive Public Health Messenger

Proposed team size: 4 or 5 students.

Project lead: TBD.

Short Description

Build an interactive communication system that helps people understand public health or crisis instructions, asks lightweight understanding checks, and aggregates patterns of misunderstanding for responders.

Motivation

During a disaster, outbreak, or crisis, authorities may broadcast critical instructions about water safety, evacuation, disease prevention, or treatment-seeking behavior. The problem is not only whether information was sent. The problem is whether people actually understood it.

Small misunderstandings can have serious consequences. A useful system should help users clarify instructions and help responders detect which messages are being misunderstood.

Intended Users

Potential users include:

• affected community members;
• public health responders;
• emergency communication teams;
• local authorities;
• humanitarian organizations.

Possible Features

Possible features include:

• text or voice-based question answering;
• retrieval from trusted guidance documents;
• answers grounded in vetted sources;
• lightweight understanding checks;
• explain-back or scenario-based questions;
• detection of partial or dangerous misunderstandings;
• aggregation of misunderstanding patterns;
• dashboard for responders showing confusing guidance;
• suggestions for clearer alternative phrasing.

The team should choose a focused scenario and avoid building a generic chatbot without a clear communication loop.

Design Questions

Consider:

• How do you ask someone to demonstrate understanding without sounding like a test?
• How do you avoid encouraging users to repeat the exact wording they just saw?
• What makes an answer safely grounded in trusted sources?
• What counts as a dangerous misunderstanding?
• How should misunderstandings be aggregated without exposing individual users?
• What should happen when guidance is ambiguous or missing?

Technical Directions

Possible technical components include:

• retrieval-augmented generation over trusted documents;
• prompt design for clear public health explanations;
• comprehension checks;
• classification or clustering of misunderstanding patterns;
• low-connectivity-friendly interface design;
• responder dashboard;
• logging and privacy-aware aggregation.

Proof-Of-Concept Expectation

The proof of concept should demonstrate one complete communication loop.

Minimum convincing POC:

• the user submits one public health question;
• the system retrieves at least one relevant trusted passage;
• the system generates or displays an answer grounded in that source;
• the system asks one understanding check;
• the user response is captured as a comprehension or misunderstanding signal;
• at least one aggregate signal is displayed, logged, or shown in a simple responder view.

The POC may use a small trusted document set and a simple dashboard. It should not be only a chatbot that answers questions without checking understanding.

Evaluation Ideas

Possible evaluation approaches include:

• checking whether generated answers are supported by retrieved sources;
• testing understanding-check prompts on example user responses;
• measuring whether known misconceptions are detected;
• evaluating whether the dashboard highlights recurring issues;
• reviewing privacy risks in interaction logs;
• comparing alternative phrasings for clarity.

Final Demo Target

The final demo should show a user asking for guidance, receiving a grounded explanation, responding to an understanding check, and the responder view updating with a meaningful misunderstanding or comprehension signal.

Geospatial Intelligence For Public Health Decisions

Proposed team size: 4 students, or 3 if needed.

Project lead: TBD.

Keywords: geospatial intelligence, public health decision support, LLMs, structured evidence.

Short Description

Build a working prototype of a geospatial intelligence system that supports public health decision-making using structured and verifiable spatial evidence.

Motivation

Public health decisions are often spatial decisions. Agencies need to know which services are missing, where vulnerable populations may live, and which environmental or infrastructural risks matter in particular locations.

LLMs are often unreliable for this use case because they do not reason well over maps and visual spatial data. This project should connect language-based interaction to open-source geospatial analysis tools, so answers are supported by structured evidence rather than only by an LLM's internal knowledge.

Intended Users

Potential users include:

• public health agencies;
• humanitarian coordination teams;
• responders planning service deployment;
• analysts without deep GIS expertise;
• decision makers who need spatial evidence quickly.

Example Query

An example query could be:

Where is the best place to deploy a mobile clinic in Freetown within Sierra Leone to best tackle the current increase in Ebola cases?

The system should identify relevant data, run spatial analysis, and produce a specific and evidence-backed response.

Possible Features

Possible features include:

• natural-language query input;
• geospatial data retrieval or loading;
• connection to open-source geospatial analysis tools;
• map display;
• structured evidence table;
• explanation of assumptions;
• LLM-generated summary grounded in spatial outputs;
• uncertainty or missing-data warnings.

Design Questions

Consider:

• What spatial operation is needed to answer the query?
• What data is required, and is it available?
• What should the LLM do, and what should deterministic geospatial tools do?
• How can the system make its evidence verifiable?
• How should missing, stale, or low-resolution data be communicated?
• What makes a recommendation actionable for public health planning?

Technical Directions

Possible technical components include:

• geospatial data loading with public datasets;
• spatial joins, buffers, distance calculations, or accessibility analysis;
• map visualization;
• LLM orchestration around tool outputs;
• structured report generation;
• reproducible query examples.

Proof-Of-Concept Expectation

The proof of concept should demonstrate one evidence-backed geospatial query.

Minimum convincing POC:

• the user submits one predefined public health query;
• the system loads or retrieves at least one relevant geospatial dataset;
• the system runs at least one verifiable spatial operation;
• the result is shown on a map or in a structured spatial output;
• the system produces an answer that cites or displays the evidence used;
• the system clearly separates geospatial computation from LLM-generated explanation.

The POC may use a simplified region, a small dataset, or a predefined query. It should not be only an LLM response to a map-related question.

Evaluation Ideas

Possible evaluation approaches include:

• checking whether the spatial operation is appropriate for the query;
• validating outputs against known examples or manual GIS analysis;
• inspecting whether the LLM summary matches the computed evidence;
• testing sensitivity to missing or noisy data;
• measuring reproducibility of query execution;
• reviewing whether recommendations are specific and actionable.

Final Demo Target

The final demo should show a public health query, spatial data processing, map or evidence output, and a grounded recommendation that can be traced back to the underlying geospatial analysis.

AI-Powered Zoonotic Disease Risk Prediction

Proposed team size: 5 students, or 4 if needed.

Project lead: TBD.

Keywords: machine learning, disease risk prediction, geospatial intelligence, explainable AI.

Short Description

Build an AI-powered disease risk prediction system that integrates human, animal, and environmental data to identify and visualize areas at high risk of zoonotic disease outbreaks.

Motivation

Emerging infectious diseases are increasingly driven by interactions between humans, animals, and the environment. Data from these domains are often collected separately, which makes it difficult for public health agencies to detect emerging threats early enough to respond effectively.

Existing surveillance systems may also require significant GIS and statistical expertise. This project should make risk analysis more accessible through a working prototype that integrates heterogeneous data, predicts or scores risk, visualizes hotspots, and explains the factors contributing to risk.

Intended Users

Potential users include:

• public health agencies;
• epidemic preparedness teams;
• zoonotic disease surveillance teams;
• environmental health analysts;
• decision makers planning interventions.

Possible Features

Possible features include:

• data ingestion from human, animal, and environmental sources;
• spatial and temporal feature engineering;
• baseline disease risk model;
• risk maps;
• hotspot detection;
• interpretable explanation of risk factors;
• comparison of regions;
• evidence export for decision makers.

Design Questions

Consider:

• What is the prediction target?
• What time and location unit defines a prediction?
• Which data sources are available and compatible?
• How will the split avoid temporal and spatial leakage?
• What baseline is meaningful?
• How should uncertainty be shown on the map?
• What explanations are useful to a public health user?

Technical Directions

Possible technical components include:

• geospatial data harmonization;
• temporal feature engineering;
• baseline machine learning model;
• valid train, validation, and test split;
• explainability method;
• interactive or static risk map;
• error analysis by geography or time.

Proof-Of-Concept Expectation

The proof of concept should demonstrate one valid risk-prediction path.

Minimum convincing POC:

• the system loads a small multi-source dataset or a representative sample;
• the team defines a clear prediction target and spatial/temporal unit;
• the system trains or runs a baseline model;
• the system generates risk predictions or scores;
• the predictions are displayed on a map or spatial visualization;
• the system provides at least one explanation signal for the prediction;
• the evaluation uses a split that is appropriate for the target and does not leak future information.

The POC may use a limited region or simplified dataset. It should not be only a map visualization without a prediction target and baseline.

Evaluation Ideas

Possible evaluation approaches include:

• comparing against a simple baseline;
• using temporal validation where appropriate;
• measuring predictive performance with a justified metric;
• checking calibration or ranking quality;
• evaluating performance across regions;
• analyzing false positives and false negatives;
• testing whether explanations align with known risk factors.

Final Demo Target

The final demo should show data ingestion, risk prediction, hotspot visualization, explanation of selected high-risk areas, and a discussion of model limitations for public health decision-making.

AI-Powered Medical Assistant For Health Workers In Rwanda

Proposed team size: 5 students.

Project lead: Fabrice.

Keywords: machine learning, UX, multilingual AI, medical assistant.

Short Description

Build an AI-powered medical assistant for health workers in Rwanda that supports questions in Kinyarwanda, English, and French through text or voice interaction.

Motivation

Health workers may need access to medical guidance through interfaces that match their language, workflow, and connectivity constraints. This project aims to build a multilingual assistant that can receive a typed or spoken question, route it through a medical language-model pipeline, display an answer, generate audio output, and support multi-turn conversation.

The project should pay careful attention to language support, medical safety, UX, and the limitations of AI-generated medical answers.

Intended Users

Potential users include:

• health workers in Rwanda;
• clinicians or community health workers who use Kinyarwanda, English, or French;
• supervisors evaluating multilingual medical support tools;
• teams exploring language adaptation for medical LLMs.

Possible Features

Possible features include:

• text question input in Kinyarwanda, English, or French;
• voice recording;
• speech-to-text;
• medical LLM response generation;
• translation or language adaptation for Kinyarwanda with English medical terms;
• French support;
• audio generation of the answer;
• multi-turn conversation;
• safety warnings and uncertainty display;
• source or rationale display where possible.

The team should define which language and modality path is core for the final system and which are stretch goals.

Design Questions

Consider:

• Which language paths must work for the proof of concept?
• How will the system handle mixed Kinyarwanda and English medical terms?
• What medical questions are in scope and out of scope?
• How should the assistant refuse unsafe requests?
• What should be displayed when confidence is low?
• How should audio input and output fit into the health worker workflow?
• What safety disclaimers or escalation guidance are needed?

Technical Directions

Possible technical components include:

• multilingual text interface;
• speech-to-text;
• text-to-speech;
• medical LLM integration;
• translation model adaptation;
• fine-tuning or adaptation of a medical LLM such as MeditronFO;
• prompt and safety layer;
• conversation state management;
• evaluation examples in Kinyarwanda, English, and French.

Proof-Of-Concept Expectation

The proof of concept should demonstrate one complete multilingual medical-assistant path.

Minimum convincing POC:

• the user submits one medical question through text or voice;
• the question passes through the language/model/interface pipeline;
• the system displays a medical assistant response;
• the system supports at least minimal multi-turn context;
• the system generates audio output or provides a clearly simulated audio-output path;
• the team clearly identifies which languages are fully working and which are simulated or partial;
• the system includes at least one safety or limitation behavior.

The POC may start with one primary language path. It should not be only a generic LLM chat interface without the multilingual and medical workflow being attempted.

Evaluation Ideas

Possible evaluation approaches include:

• testing a small set of medical questions across supported languages;
• comparing translations or answers against reference examples;
• checking whether medical terminology is preserved;
• evaluating refusal or safety behavior on out-of-scope questions;
• measuring latency for text and voice paths;
• qualitative review of UI clarity for health workers;
• error analysis on mixed-language inputs.

Final Demo Target

The final demo should show a health worker asking a question, receiving a multilingual medical response, continuing the conversation, hearing or generating audio output, and seeing clear safety or limitation cues.

AI-Powered Dengue Early-Warning Platform

Proposed team size: 5 students.

Project lead: TBD.

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.