These AI capstone project ideas help U.S. college seniors and master's students choose a system they can build, test, and defend. Each idea includes a data approach, a baseline, and an evaluation plan. Start with the question you can measure, then choose the model and interface.
What makes a strong artificial intelligence capstone?
An AI capstone project develops or evaluates a system that performs tasks such as classification, perception, retrieval, planning, or language generation. Your contribution might be an evaluation, workflow improvement, or reliability study using an existing model.
AI is broader than machine learning. An AI capstone can study planning, retrieval, or tool use; a machine learning capstone usually emphasizes learning patterns from data and evaluating the resulting model. The categories overlap. An existing model can support an original AI project when you contribute a justified design change or a careful evaluation.
Start with one user, one task, and one primary metric. Use FileMakr's capstone scope guide to bound the MVP. Your department's rubric determines whether the proposed contribution is sufficient.
Compare ten project options
These are proposed project designs, not reported FileMakr experiments. Difficulty assumes the narrow scope described below and is an editorial estimate. For every option, build one complete workflow before adding features.
| Idea | Difficulty | Starting baseline | Main evaluation |
|---|---|---|---|
| Campus document assistant | Intermediate | Keyword retrieval | Complete supported answers and citation coverage |
| IT ticket triage | Beginner–intermediate | TF-IDF plus logistic regression | Macro-F1 and category recall |
| Receipt extraction | Intermediate | OCR plus fixed rules | Field precision and recall |
| Clothing image classifier | Beginner–intermediate | Linear classifier | Macro-F1 and confusion matrix |
| Plain-language text simplifier | Intermediate | Original passage | Meaning preservation; optional comprehension study |
| Conflict-free scheduler | Intermediate | Greedy allocation | Constraint violations and schedule quality |
| City-service anomaly explorer | Intermediate | Seasonal count rule | Agreement with a documented review set |
| Concept-practice tutor | Intermediate | Fixed hints | Hint correctness and optional task-completion study |
| Read-only data analyst | Advanced | Fixed query templates | Correct answers and blocked writes |
| Prompt-injection testbed | Advanced | Undefended assistant | Attack success and benign-task completion |
Macro-F1 gives each class equal weight when averaging F1 scores. A baseline is your comparator under identical test conditions. For ticket triage, majority prediction is a basic sanity check; TF-IDF plus logistic regression is the practical baseline to improve.
| Your priority | Start by testing | First feasibility check |
|---|---|---|
| Basic Python and CPU-first work | Ticket triage | Run TF-IDF and logistic regression locally |
| Planning without a language model | Constrained scheduling | Solve a small feasible and an impossible instance |
| Generative AI with traceable answers | Campus document assistant | Check corpus permissions, retrieval, and inference access |
| A visible review workflow | Receipt extraction | Test OCR on several unseen layouts |
| Advanced reliability work | Data agent or injection testbed | Enforce tool restrictions outside the model |
For hosted models, measure pilot usage and set spending limits. For local models, test memory and latency on your own hardware; “runs locally” does not mean every laptop can handle the chosen model.
1. Build a campus document assistant that cites sources
Use campus documents with suitable reuse permissions, or author a handbook. Build retrieval-augmented generation (RAG): retrieve relevant passages, then generate an answer grounded in them. Python, SQLite, a text index, and a web interface can support the MVP.
Compare keyword retrieval with your chosen retrieval method while keeping the corpus, generator, answer prompt, and retrieval budget fixed. Create held-out questions with expected source passages, including unanswerable questions. Score retrieval success, supported claims, valid citations, and correct abstention separately. Display the source and document version. A citation alone does not prove an answer is supported.
MVP output: A question screen showing the answer, cited passage, document version, and an explicit unanswered state.
2. Route IT support tickets into clear categories
Create fictional help-desk tickets about password access, connectivity, and software installation. Label consistently; author test tickets separately and avoid splitting paraphrases across training and testing.
Start with majority prediction, then establish TF-IDF text features and logistic regression as a practical baseline using scikit-learn. Compare any further improvement on the same held-out tickets. Report macro-F1, category recall, and errors on ambiguous tickets. Add a review queue for uncertain predictions, with its threshold selected on validation data. Synthetic tickets demonstrate your pipeline, not accuracy on an actual university help desk.
MVP output: A predicted category, review queue, and dashboard of category errors; no automatic ticket closure.
3. Extract receipt fields with a review screen
Generate fictional receipts with known merchants, dates, totals, and items. Reserve layout families for testing to prevent template memorization.
Compare optical character recognition (OCR) plus fixed extraction rules with your proposed extraction method. Measure field precision and recall with a written matching rule for dates, amounts, and missing fields. Count a missing expected field as a missed extraction and a fabricated field as a false extraction. Report normalized-value correctness and correction time under the same review procedure for both methods. Keep manual confirmation before exporting results. Include blurred images and missing totals. Synthetic receipts establish controlled performance; real receipts introduce additional layouts, image defects, and privacy concerns.
MVP output: An uploaded receipt beside editable fields, validation warnings, and a confirmed CSV export.
4. Classify clothing images and explain the failures
Use the original Fashion-MNIST repository, with labeled grayscale clothing images and established training/test sets. Compare a linear classifier with a small convolutional neural network. Reserve validation data within training; preserve the final test set.
Report macro-F1, per-class recall, and a confusion matrix. Show mistaken examples in an explorer. Test your hardware before committing. Benchmark images do not establish performance on phone photographs or products photographed in real stores.
MVP output: A prediction screen and error explorer with class-level results and misclassified examples.
5. Simplify campus information without changing its meaning
Author passages about fictional campus services, then produce simpler versions using a language model. Compare them with the original text and a fixed editing checklist. Keep warnings, deadlines, and eligibility conditions intact.
Use blinded human review for meaning preservation, omitted facts, and readability. If permitted by your course, add comprehension questions with consenting participants and an approved study design. Readability scores alone cannot establish accessibility or learning benefit. Record evaluator disagreements and avoid presenting the output as officially approved campus guidance.
MVP output: Original and simplified passages side by side, with highlighted changes and a human approval control.
6. Generate schedules that satisfy explicit constraints
Create fictional course, room, and instructor records. Define hard constraints, such as no room overlap, and soft preferences, such as fewer gaps. Compare a constraint solver with greedy allocation on identical instances.
Count hard-constraint violations, report preference scores, and record runtime. Include deliberately impossible cases. Distinguish a valid solution, proven infeasibility, and an unresolved run that reaches its time limit. A greedy failure or solver timeout does not prove that no valid timetable exists. A feasible schedule is not necessarily optimal, and an invalid model is a modeling error rather than proof of infeasibility. The OR-Tools CP-SAT documentation distinguishes feasible, infeasible, and unknown statuses. Constraint programming connects AI planning with operations research; a language model is optional. Extend only after the basic solver and comparison work—for example, add a controlled study of how runtime changes with problem size.
MVP output: A timetable and constraint report, or an explicit status distinguishing proven infeasibility from a search that ended without a decision.
7. Explore unusual patterns in city-service requests
Use a bounded export from NYC's 311 service-request dataset. Select one request type, a fixed period, and daily aggregate counts. Exclude unnecessary location or identifying fields from the demo.
Compare an anomaly detector with a seasonal count rule, choosing thresholds on earlier development data. For a forward-looking evaluation, compute features using only information available at each alert time. Review flagged dates and a predefined sample of unflagged dates using the same rubric. Report reviewer agreement and alert volume. Reviewing alerts alone cannot establish missed-anomaly recall, and reviewer labels are not confirmed incidents. A small unflagged sample also does not establish population-wide recall without an appropriate sampling and estimation design. Keep later test periods unseen during tuning; request counts reflect reporting behavior as well as demand.
MVP output: A daily-count chart with flagged dates, detector settings, and reviewer notes; no claims of confirmed incidents.
8. Create a concept-practice tutor with checked hints
Choose one subject, such as introductory SQL joins. Author questions, worked solutions, and approved hints. Build a tutor that retrieves hints before generating explanations; compare it with fixed hints on identical questions.
Evaluate hint correctness, unsupported statements, and answer leakage using a written rubric. A permitted participant study can examine task completion, but satisfaction alone does not demonstrate learning. Keep assessment answers and private course material out of the corpus. The extension can test whether different hint levels preserve correctness.
MVP output: A practice question, staged hints, answer checking, and an error log tied to the reviewed solutions.
9. Build a read-only data analysis agent
Use a fictional SQLite retail database and questions with checked answers. Let an agent propose SELECT queries through a restricted tool; compare it with fixed query templates.
Enforce read-only database access, an allowlist of permitted tables and operations, row limits, and timeouts outside the model. A query beginning with SELECT is not a complete security policy. Keep database access inside a restricted tool rather than granting the agent a general shell. SQLite supports read-only connections through its URI options; use those alongside tool restrictions and resource limits. Measure answer correctness, query execution success, blocked write attempts, latency, and actual run cost. Include questions that require clarification. Python and SQLite support the core workflow; a language-model service or local model adds resource requirements that you must test and document.
MVP output: A question, executed query, bounded result table, and explanation; rejected actions remain visible in the log.
10. Test prompt-injection defenses in a sandbox
Build a local assistant with synthetic documents and dummy tools. Place instruction-like text inside retrieved documents and test whether the assistant follows it instead of the authorized task. Use no real credentials or external actions.
Compare the original assistant with one defense at a time on the same held-out tasks. Reserve unseen attack variants and benign tasks for testing. Define attack success before testing. Report successful attacks divided by attempted attacks, normal-task completion on benign cases, refusals, and test-set construction. Log errors and timeouts separately; do not silently remove them from the attempted-task counts. Record the model and configuration; if outputs vary between runs, repeat paired trials and report that variation. A defense that blocks every request is not useful. Passing your test suite supports a bounded robustness claim, not universal security.
MVP output: A comparison report showing attacks, normal tasks, outcomes, and the defense configuration for every run.
How to scope, evaluate, and present an AI capstone
- Prove input access. Load a small sample, check permissions, and document labels. Result: a usable data manifest. Follow the dataset selection guide if access remains uncertain.
- Write the evaluation contract. Define the user, input, expected output, baseline, split, and success criteria before tuning. Result: a proposal your advisor can review using this capstone proposal checklist.
- Build the baseline first. Run the simplest comparison end to end. Result: evidence that the task and scoring procedure work.
- Add one improvement. Keep final evaluation cases separate; use development data to choose settings. Result: a fair comparison and a failure log. Scikit-learn's data-leakage guidance explains why preprocessing must respect that separation.
- Package reproducible evidence. Save dependencies, corpus and question-set versions, prompts, model identifiers, retrieval settings, scoring rubrics, evaluation scripts, and limitations. Result: a repeatable demonstration. Reserve integration and report time in your capstone timeline.
Example proposal: a campus document assistant
This is an illustrative design, not a measured result or a validated benchmark. A student asks questions about an authored campus-services handbook. The assistant returns a supported answer and passage, or states that the handbook does not contain the answer.
| Proposal element | Bounded design |
|---|---|
| Research question | Does semantic retrieval find better supporting passages than keyword retrieval? |
| Fair comparison | Keep corpus, chunking, questions, generator, answer prompt, top-k, and context-token budget fixed; change retrieval method only |
| Development | Tune on separate questions; freeze settings before final testing |
| Final demonstration set | 40 unseen questions: 20 direct lookups, 10 requiring two passages, 10 unanswerable |
| References | Write expected passages and answer conditions before running either system |
| Measures | Retrieval success, supported answers, correct citations, and appropriate abstention; report counts with denominators |
| Resources | Record latency, model identifier, usage, and actual cost for both variants |
| Success decision | Set quality and resource targets with your advisor before final testing; report failure if unmet |
Use a written rubric and report the following measures separately:
| Measure | Scoring rule |
|---|---|
| Retrieval success | Questions with every required passage in the top-k results, divided by 30 answerable questions; choose k before testing |
| Answer success | Complete, factually supported answers divided by 30 answerable questions; refusals and incomplete answers do not pass |
| Citation correctness | Claim–citation pairs where the cited passage supports the claim, divided by all pairs inspected; report missing citations separately |
| Citation coverage | Factual claims with a valid supporting citation divided by factual claims requiring support; include responses with no citations and report claim-free responses separately |
| Correct abstention | Explicitly state that the handbook lacks the answer on the 10 unanswerable questions; count unsupported answers, errors, and timeouts separately |
| Resource use | Latency and actual usage/cost under the same recorded conditions for both retrieval variants |
For correct abstention, report successful cases out of all 10 unanswerable questions; a crash or timeout is not an appropriate unanswered response. When a citation denominator is zero, report N/A and the case count rather than assigning a perfect score.
Report the ten two-passage questions separately: retrieving one necessary passage is not complete retrieval success. Citation correctness alone can look good when a system cites only one easy claim, so inspect coverage too. If generation varies, score each paired repeated run on the same 40 questions and report per-run results and variation. Repeated runs do not create new independent questions. Do not tune prompts, retrieval settings, or the test questions after reviewing final results.
Forty cases provide a small demonstration, not strong evidence of general performance. Results from an authored handbook do not establish accuracy on changing university policies.
Keep a data and evaluation manifest
For each input collection, record its source or creation method, permissions, version, label definitions, review procedure, split assignment, and related-template group. If two labels seem plausible, clarify the label rule before adding more examples. Keep paraphrases and shared receipt templates together when separating development and final testing.
For human scoring, write a rubric with examples of supported, partly supported, and unsupported answers. Review disagreements explicitly; an unreviewed model-generated score is not a ground-truth label. For team projects, also record who built each component and who reviewed the labels and final scores. Where possible, hide the system identity from reviewers and resolve disagreements using the written rubric.
Common mistakes and useful refinements
Tuning on the final test set makes the reported score less independent. Keep validation and final testing separate.
Using an LLM to judge itself without checks can conceal errors. Audit a sample against references or a human rubric.
Calling a prototype production-ready overstates the evidence. Describe the tested inputs and known failures.
Advanced evaluation tips: Change one component at a time and report latency alongside quality. An ablation—removing one component—can show whether it contributes anything. Keep an offline demonstration path when your live presentation depends on a network service.
Frequently asked questions
Which AI capstone project is best for beginners?
Ticket triage is a practical starting point for students who know basic Python and classification. It supports a small dataset, a simple baseline, and clear error analysis. Confirm that its depth meets your course rubric.
Can I build an AI capstone without a GPU?
Yes. Text classification, constrained scheduling, and small retrieval systems can be scoped for CPU execution. A hosted model can move generation off your machine, but introduces service costs and availability dependencies. Benchmark a small example before choosing.
Can I use an API instead of training a model?
Yes, if your course permits it. Explain the model's role, your own engineering contribution, evaluation, costs, and limitations. A thin interface alone may not meet the required academic depth.
What makes an AI capstone original?
A specific question, a justified design change, or a careful reliability study can provide an original contribution. Reusing a model does not automatically remove originality, but you must identify borrowed components and demonstrate your own work.
How should I evaluate a generative AI capstone?
Use held-out tasks, checked references or a human rubric, a simple comparator, and documented failures. Evaluate factual support, task success, and resource use separately. Fluent wording is not evidence of correctness.
What do U.S. universities require for AI capstones?
Requirements vary by institution and course. Ask your advisor about research depth, teamwork, API use, data permissions, participant studies, and submission rules before finalizing the topic. No single project list establishes universal acceptance.
How can I control API spending during an AI capstone?
Set a project budget, cap request size and repeated calls, and measure a small pilot. Estimate evaluation spending from actual pilot usage and current provider pricing. Reuse cached examples where permitted, and record which results came from live runs.
Can I use synthetic data for an AI capstone?
Yes, if your course permits it and synthetic inputs fit the research question. Document creation and label review, then keep related templates or paraphrases within the same split. Report performance under those synthetic conditions; it does not establish real-world accuracy.
Choose the question you can defend
Choose AI capstone project ideas that leave time for a baseline, a fair comparison, and an explanation of failures. Run two small feasibility checks, then commit to accessible inputs and a contribution you can defend. For a narrower modeling focus, compare these options with FileMakr's machine learning capstone project ideas.
Need an implementation reference? Explore FileMakr's AI project source code, check the permitted use, and follow your course's disclosure rules. Use the reference to understand the system and develop your own contribution.
