36-614 · Two-Project Build and Handoff

Source. Project requirements are based on Professor McGovern's Data Engineering Assignment Instructions (July 6, 2026). The build/receive structure also adapts the paired handoff in Alex Reinhart's Project: Data Pipeline.

The course has two distinct projects. Each team builds one system, transfers it, and then operates the other system. They are only loosely related: both support location- aware infrastructure or risk decisions, but their clients, sources, schemas, and evidence are different.

Climate team ──build──► climate system ──KT──► EV team operates it
EV team      ──build──► EV system      ──KT──► climate team operates it

Project A · Climate Risk Analytics & P&C Insurance Underwriting

Decision-maker: an insurance underwriting or portfolio-risk team.
Database: PostgreSQL.

Core sources

NOAA Storm Events
HURDAT2 Atlantic hurricane best tracks
GHCN-Daily weather observations
NWS API

Enrichment options

Census ACS
Zillow ZHVI
Census Geocoder
xView2 where useful and feasible

Questions the system should support

Is changing flood loss driven by event frequency, severity, or both?
Where and when is hail exposure most concentrated, and what might that mean for pricing?
How has the frequency of very high-loss events changed over time?
Which storm types show a mismatch between measured property loss and harm to people?

Project B · Predictive EV Fleet Siting & Grid Capacity Optimization

Decision-maker: a commercial fleet, charging-network planner, or utility partner.
Database: PostgreSQL or DuckDB; PostgreSQL is preferred for the shared course server.

Core sources

EIA bulk power data
NREL Alternative Fuels Data Center
FHWA freight data

Enrichment options

EPA eGRID
Census ACS
OpenStreetMap and TIGER geography

Questions the system should support

Where do freight demand and existing charging gaps overlap?
What could a 24-hour charging schedule look like under stated demand assumptions?
Which corridors or grid areas deserve more detailed upgrade study?
Which high-traffic locations have plausible site context?

Evidence boundary for the EV project

The listed public sources do not establish transformer or substation capacity. eGRID is an annual emissions/resource-mix dataset, not a real-time grid feed, and OSM building footprints are not parcel acreage. Unless authoritative client data are supplied, the project may rank candidates and identify data gaps, but must not claim that a substation is above a measured capacity threshold. Proxy variables must be named as proxies.

Timeline

Date	Role	Evidence due
Oct 19–28	Builder	source inventory, driving questions, ER diagram, schema v1
Nov 2–4	Builder	client query library, windows/index evidence
Nov 9	Builder	refresh dry run, validation checks, known failures
Nov 11	Builder	parameterized Python entry point and complete draft handoff pack
Nov 13	Handoff	live KT, access transfer, receiver connection test
Nov 16–30	Receiver	cold-start log, reproduction, new query, tested improvement
Dec 1	Both roles	Professor McGovern Parts I and II due
Dec 2	Receiver	acceptance test and presentation rehearsal
Finals week	Both roles	client readout
Dec 11	Optional	statistical-analysis extra credit

Builder acceptance criteria

The receiving team must be able to find and run:

a source inventory with license/access notes and update cadence;
an ER diagram and data dictionary with grain, units, keys, and provenance;
schema creation and ingestion commands;
rerun-safe loading with validation, logging, and explicit transaction behavior;
at least eight non-trivial, client-relevant SQL queries;
at least one parameterized Python report or query command;
a runbook covering connection, refresh, expected output, failure, and recovery;
known issues, assumptions, proxy measures, and limitations; and
no credentials committed to the repository.

Receiver acceptance criteria

Without private oral instructions after the KT session, the receiving team must:

connect with the provided role and locate the documented entry points;
reproduce one builder result and compare row counts/checksums or other evidence;
answer a new client question with its own tested query;
add one scoped improvement from the second-half course topics;
document every blockage and the exact missing or misleading instruction; and
explain what this experience changes about its own future handoffs.

Knowledge-transfer agenda · 20 minutes

3 min: client, decision, and system boundary
4 min: sources, schema, grain, and important caveats
5 min: connect and run the smallest successful workflow
4 min: refresh, validation, failure, and recovery
4 min: receiver performs the first cold-start step while builders observe

The recording is supporting evidence; it does not replace the runbook.

Project assessment

Component	Points	Full-credit evidence
Architecture and source reasoning	15	client question, feasible evidence, coherent schema
Database and ingestion	15	reproducible load, rerun safety, validation, transactions
Query/report layer	15	eight useful queries and a safe Python entry point
Documentation pack	20	a receiver can operate the system from it
Knowledge transfer	10	concise, accurate, receiver-centered session
Receiver cold start and extension	15	reproduction, new result, and tested improvement
Client readout	10	decisions, evidence, limits, and clear demo

Required final readout

The presentation must distinguish the two roles. First, show what the team built and how well it transferred. Then show what the team inherited, what it could reproduce cold, what it improved, and what remained uncertain. A polished demo is useful; an honest account of system boundaries and transfer failures is more important than theatrical certainty.