The Final Report is a slide deck with written presenter notes. There is no template, no abstract and no page count.
Pitch it as you would to an executive team: sparse text, strong graphics, and slides that are short and illustrative rather than dense. If a slide needs a paragraph to make sense, the paragraph belongs in the presenter notes.
Your completed analysis: the question, the data, the models, what you found, and what you would not claim. Both halves are graded.
Carry the visuals and the takeaways. A slide should make one point, and the graphic should make it before the text does.
Carry the reasoning. This is where you justify choices, report the numbers a slide cannot hold, and address what does not fit the story.
There is no separate code submission. Whatever is in your group GitHub repository at the deadline (Dec 13, 2026, 11:59 PM US Eastern Time) is what gets graded, and it should be the analysis behind the presentation you just handed in.
Do not paste code into the deck.
Roughly 20–40 slides. Treat that as a shape, not a quota — many short, illustrative slides beat a few crowded ones.
Presentation carries 18 of 50 — graphics 8, clarity 7, presenter notes 3. How it reads is not a finishing touch.
Critical insight carries 15: handling complexity and ambiguity, depth of interpretation, and honest limitations. That is where strong decks separate themselves. The analysis itself carries 17.
Who cares about the answer, and what changes if you find one. Include the brief prior work — what is known, what is still open.
Notes should carry the sources and the reasoning; the slide carries the question.
Where it came from, its shape, its key variables, and what you had to do to make it usable. Meets the data requirements.
Notes should cover cleaning decisions and anything you dropped, with counts.
Carry forward what your Deliverable 1 exploration found, updated with anything you learned since. Do not re-run the whole EDA — show the parts that shaped the modelling.
Your 3 models, each a specific instance of an analysis, with 10+ predictors. Say why each fits this question and this data — not what the method is in general.
You may change the outcome variable between models. Picking a different response is often the cleanest route to a different model family — a count outcome for Poisson, a binary one for Logistic — even when your first model was MLR on something else entirely. The models should still speak to the same research question.
Notes should carry specification choices, variable selection, and the train/validation/test split.
Coefficients, fit statistics, diagnostics, test-set performance. Graphics should do the work here.
Notes should interpret the numbers, not restate them.
Which assumptions held, which did not, and what you did about it. What your analysis cannot support. This section is where strong projects separate themselves — a confident overclaim costs more than an honest limitation.
What you now believe, how strongly, and what you would do next with more time or better data.
In a deck the figure carries the point and the text supports it — the reverse of a paper. Give every figure a title, labelled axes with units, and a caption stating the takeaway.
Submit a single PDF. A normal "export to PDF" throws your presenter notes away — export using the notes layout instead, so each page shows a slide with its notes underneath.
Open the PDF before you submit and confirm your notes are actually in it. Every semester someone submits slides only.
How the Final Report is graded, out of 50.