The capstone: choosing and scoping a project

The capstone is where everything in the AI program comes together. Instead of exercises with known answers, your team takes a real problem from an initial idea to an evaluated, documented and demonstrated AI system, making the decisions that practicing machine learning engineers and data scientists make every day: what to build, what data to use, how to measure success, which approaches to try, how to check for harm, how to deploy and how to explain the result. Most capstone projects that struggle do so not because of technical difficulty but because of poor choices in the first few weeks: a problem that is too vague, data that does not exist or cannot be used, success criteria that cannot be measured, or a scope far larger than the time available. This first lesson explains the structure of the capstone, how to form a team, how to generate and evaluate project ideas, and how to scope a project that can be finished well.

What the capstone asks of you

Over the term, each team delivers a sequence of milestones, each covered by a lesson in this course:

• A project proposal with a problem statement, users, data sources, success metrics and risks (Lessons 1 and 2).
• A data report describing sources, permissions, quality, splits and documentation (Lessons 3 and 4).
• A baseline report showing simple approaches and an experiment plan (Lesson 5).
• A model development report with error analysis and, for systems using large language models, an evaluation of the full pipeline (Lessons 6 and 7).
• An evaluation report with statistical rigor, calibration and robustness (Lesson 8).
• A safety, fairness and risk review with a model card (Lesson 9).
• A deployed demonstration with monitoring and cost estimates (Lessons 10 and 11).
• A final technical report, code repository, presentation and reflection (Lesson 12).

Each milestone is reviewed by instructors and peers, and feedback should change what you do next. The grade rewards sound process and honest evaluation as much as final performance: a modest model with rigorous, well-documented evaluation earns more than an impressive-sounding system whose results cannot be trusted.

Forming a team

Capstone teams typically have three to five members. Good teams combine complementary skills, such as data engineering, modeling, software and deployment, user research and writing, and members who can commit similar amounts of time. At the first meeting, agree on how the team will work: meeting times, communication channels, how decisions are made, how work is divided and tracked, code review practices, and what happens if someone cannot deliver. Writing this down as a short team charter takes an hour and prevents many conflicts later. Rotate responsibilities such as meeting facilitation and milestone integration so that everyone understands the whole project.

Generating project ideas

Good capstone ideas usually come from a real need rather than from a technique looking for a problem. Sources include organizations that partner with the program, such as non-profits, local businesses, hospitals, municipalities and research labs; problems team members have encountered at work or in their communities; public datasets with an interesting unanswered question; open-source projects that need a component; and replications or extensions of published research. For each idea, ask who would use the result, what decision or task it would improve, how that is done today, and how you would know whether your system helps.

Evaluating candidate projects

Teams should compare several candidate projects before committing. Useful criteria include impact (does it matter to someone?), data availability (does suitable data exist, and may you use it?), feasibility within the term, clarity of evaluation (can success be measured objectively?), fit with the team's skills and interests, and manageability of risk, including privacy, safety and ethical risks. Weighting these criteria and scoring each candidate makes the comparison explicit and shows each project's weakest point, which is often where it would fail.

import numpy as np
# Scoring candidate capstone projects with a weighted rubric
criteria = ["impact", "data available", "feasible in 12 weeks", "evaluation clear", "team skills", "risk manageable"]
weights = np.array([0.20, 0.25, 0.20, 0.15, 0.10, 0.10])
projects = {
    "clinic triage chatbot":        [5, 2, 2, 3, 3, 1],
    "invoice field extraction":     [3, 5, 4, 5, 4, 4],
    "crop disease from phone photos": [4, 3, 4, 4, 3, 3],
    "general stock price predictor":  [3, 5, 3, 1, 4, 2],
}
for name, scores in sorted(projects.items(), key=lambda kv: -np.dot(weights, kv[1])):
    s = np.dot(weights, scores)
    weakest = criteria[int(np.argmin(scores))]
    print(f"{name:32s} score {s:4.2f}/5   weakest: {weakest}")
# Effort check: planned person-hours against capacity
team, weeks, hours_per_week = 4, 12, 8
capacity = team * weeks * hours_per_week
tasks = {"data collection and labeling": 120, "baselines": 40, "model building": 110, "evaluation and safety review": 60,
         "deployment demo": 50, "documentation and presentation": 40}
planned = sum(tasks.values())
print(f"capacity {capacity} h, planned {planned} h, buffer {capacity - planned} h ({(capacity - planned) / capacity:.0%})")

invoice field extraction         score 4.20/5   weakest: impact
crop disease from phone photos   score 3.55/5   weakest: data available
general stock price predictor    score 3.20/5   weakest: evaluation clear
clinic triage chatbot            score 2.75/5   weakest: risk manageable
capacity 384 h, planned 420 h, buffer -36 h (-9%)

The scores show a common pattern. The clinic triage chatbot has high impact but scores poorly on data, feasibility and risk: medical advice systems need clinical data, expert evaluation and careful safety work beyond a term project. The stock predictor has plenty of data but no clear way to show real value. The invoice extraction project is less glamorous but has data, a clear metric and manageable risk, which makes it a strong capstone. The effort check reveals a second common problem: the planned work exceeds the team's capacity, with no buffer for the surprises every project encounters. The plan must be cut back before it starts.

Scoping

Scoping means deciding what the project will and will not include. A well-scoped capstone has a single primary objective, a defined user and use case, a primary metric with a target, a list of features in order of priority, and an explicit list of things that are out of scope. Techniques that help include:

• Defining a minimum viable system: the smallest version that delivers value end to end, from input to useful output, which you build first.
• Ordering stretch goals: additional features or improvements to attempt only if time allows.
• Time-boxing exploration: setting a fixed period for trying an approach before deciding whether to continue.
• Planning for a buffer: reserving 15 to 25 % of capacity for problems, rework and integration.

The project proposal

The first milestone is a two- to four-page proposal covering: the problem and why it matters; the intended users and how they would use the system; the data sources, with evidence that you can obtain and use them; the primary success metric and target, and secondary metrics; a baseline you expect to beat; the planned approach and alternatives; a timeline with milestones; risks, including technical, data, ethical and schedule risks, with mitigation plans; and team roles. A good proposal is specific enough that a reviewer could tell, at the end of the term, whether the project succeeded.

Working with partners

Many capstone projects have an external partner who provides the problem, data or domain expertise. Partners bring realism and motivation but also obligations. Agree early on what the partner expects, how often you will meet, who owns the code and results, what data may be used and how it must be protected, and whether results can be published or presented publicly. A written agreement, often provided by the program, covers intellectual property, confidentiality and data handling. Manage expectations honestly: a term project is a prototype and an evaluation, not a production system, and partners appreciate clear communication about what is and is not realistic.

Project management

Even small teams benefit from lightweight project management. Keep tasks in a shared tracker with owners and dates, hold short weekly meetings to review progress against milestones, keep a decision log recording important choices and their reasons, and use version control for code, configuration and documentation from the first day. Plan the term backwards from the final deadline, leaving the last two weeks for integration, documentation and rehearsal rather than new development. Teams that begin writing their final report in week 3 and update it as they go produce far better reports than those that start in the final week.

Examples of strong capstone projects

Strong capstone projects share a pattern: a specific user, a measurable task, data the team can legally use, and an evaluation that can be completed within the term. Examples from AI programs include a classifier that routes municipal service requests to the right department, evaluated against the city's historical routing; an extraction system that pulls dosage information from drug labels into a structured database, checked by a pharmacist; a retrieval assistant that answers questions about a university's academic regulations with citations, evaluated on questions collected from student advisors; a model that predicts equipment failures from maintenance logs for a manufacturing partner, evaluated on a temporal split; and a tool that flags accessibility problems in website screenshots, evaluated against expert audits. None of these is the largest possible project in its area; each is a well-defined slice that can be built, evaluated and explained properly.

Projects to approach with caution

Some project ideas are attractive but rarely succeed as capstones. Systems that give medical, legal or financial advice to the public carry risks that a term project cannot adequately manage. Predicting markets, elections or individual behavior often lacks a meaningful evaluation or raises ethical concerns. Projects that depend on scraping websites whose terms forbid it, or on personal data the team cannot lawfully obtain, stall in their first weeks. Projects that need very large amounts of compute, such as training a large model from scratch, exceed the resources available. A useful test is to ask whether the team could explain, in the final presentation, exactly how well the system works and why that matters; if not, the project should be reshaped.

Milestone reviews and feedback

Milestone reviews are opportunities, not just assessments. Prepare for each review with a short summary of progress against the plan, the main open questions and the decisions the team needs input on. Record the feedback received and how the team responded, either by changing the plan or by explaining why not, in the decision log. Instructors and partners often notice problems, such as an unrealistic scope or a leaky evaluation design, that are cheap to fix early and expensive later.