The AI Capstone Project: Planning, Log Book, Documentation and Video

Hello students, welcome to Kwickprep. Many teams build a good AI model and still lose marks in the Capstone Project. Why? Because they skip the planning, the log book or the documentation. Today we learn what the project needs and how to define the problem. Then we learn to keep the log book and make the three minute video.

First, what does capstone mean? A capstone is the top stone that completes a building, so a Capstone Project is the final project that uses everything you learned. It solves a real problem by following the AI project cycle. It is usually done in a small team. And it is assessed on the whole process, not only on whether the final model works.

A typical Capstone Project asks for five things. A working solution, which may be a model, a program or a prototype app. A project log book that records your work week by week. Documentation, which is the written report of the whole project. A project video of about three minutes. And a viva, where the examiner asks questions to check your understanding. Always confirm the exact list and marks with your school, because they can change each year.

Your project should move through the AI project cycle. Problem scoping defines what you will solve and for whom. Data acquisition collects the data you need. Data exploration studies that data with charts and summaries. Modelling builds and trains the model. Evaluation tests how well it works on new data. Deployment, or a demo, shows it working for real users.

Problem definition is the most important step, so use the four Ws problem canvas. Who are the users, the people who actually face the problem? What exactly is the problem, written in one clear sentence? Where and when does it happen? And why does it matter, meaning what improves if you solve it?

Put the four answers into one problem statement using this template. For example, our small farmers in Nashik have a problem that grape leaf disease is spotted too late, during the monsoon. An ideal solution would warn them early from a phone photo. This one statement will guide every later decision.

A strong project talks to real users, not imaginary ones. Interview at least a few people who face the problem. Summarise what you learn in an empathy map of what they say, think, do and feel. Note what they already use today, because your solution must be better. And check that they can actually use it, for example on a basic phone or in their own language.

Brainstorming means the team produces many ideas quickly. First aim for quantity, and judge the ideas later. Everyone gets a turn, and no idea is laughed at. Then group similar ideas together on sticky notes or a board. Finally, vote for the best idea by checking its impact, the effort needed, and whether data is available.

Next, the project log book. A log book is a dated diary of your team's project work. It must be written regularly, ideally every week, never all at once at the end. It proves to the examiner that the work is truly your own. Your teacher usually checks or signs it at regular points.

Here is what one good log book entry looks like. The date is fourteen July. Work done says the team took three hundred leaf photos. Who did it names Riya and Aman, so every member's role is clear. Problem faced records that some photos were blurry. Next step says they will retake fifty photos, so the plan keeps moving.

Examiners spot three common mistakes quickly. The first is filling the whole log book the night before submission, with the same pen and handwriting. The second is writing only successes, while real projects always have failures worth recording. The third is leaving out names, so nobody can tell who did what.

Documentation is the full written report of the project, and it usually has these sections. The introduction explains the problem, the users and any linked SDG. The data section explains where the data came from and how it was cleaned. The model section explains the method you chose and why. The evaluation section gives accuracy and test results honestly. The conclusion lists the limits of your work and future improvements.

Now the project video, which should be about three minutes long. Spend the first thirty seconds on the problem and who faces it. Spend the next forty five seconds on your data and your model. Give the biggest part, over a minute, to a live demo of the solution working. Use the last thirty seconds for results, limits and each member's role.

A few tips make the video strong. Write a short script and time it before you record. Clear audio in a quiet room matters more than fancy effects. Show the real solution working, not only slides. And stay within the time limit. Pause and think. If your video runs for five minutes, what should you cut first?

Let us revise, and first the answer: cut long slides and introductions, never the demo. The Capstone Project solves a real problem through the AI project cycle. Define who, what, where and why, and meet real users. Brainstorm many ideas, then vote for the best. Keep a dated log book every week. Finish with clear documentation and a three minute video with a live demo.