Week 1 — Get the data before anything else
Download the dataset in the first week. Not identify it, not bookmark it — download it, open it, and count the rows. Many promising ideas die here, and finding out immediately is the cheapest possible outcome.
- Record the source, licence and download date; these go straight into your report.
- Count rows per class. A class with forty examples will not train reliably.
- Check for duplicates — they leak between train and test sets and inflate your results.
- Open twenty rows manually and confirm the labels look correct.
- Checkpoint: you can state the dataset size, class balance and source from memory.
Week 2 — Establish a baseline
Before any modelling, compute what a trivial approach scores. For classification that is predicting the majority class; for forecasting it is predicting yesterday's value. This number is the most important one in your report, because without it nobody can tell whether your model learned anything.
Teams routinely present 82% accuracy proudly, until an examiner points out that 80% of the dataset belongs to one class. Knowing your baseline prevents that moment.
- Split the data properly, stratified for classification, chronologically for time series.
- Lock the test set away and do not look at it again until the end.
- Record the baseline score in your notebook with the date.
- Checkpoint: you know the number your model must beat to be worth anything.
Weeks 3 to 5 — Build the simple model first
Start with logistic regression or a decision tree. It trains in seconds, is easy to explain in a viva, and often lands within a few points of a much heavier model. Only move to something complex when the simple model has been fully tuned and you can articulate why it is insufficient.
- Build a preprocessing pipeline so training and inference transform data identically.
- Try three or four algorithms and record every result in one table.
- Tune the best two with cross-validation on the training set only.
- Keep the results table as you go — it becomes a report section with no extra work.
- Checkpoint: a model that beats the baseline, with a saved results table.
Week 6 — Evaluate honestly
Now open the test set, once. Report accuracy, precision, recall and F1, plus the confusion matrix. If one class performs badly, say so and explain why — panels reward that far more than a suspiciously uniform result.
- Confusion matrix with a written interpretation of the errors
- Per-class metrics, not only the overall average
- Feature importance so the model is explainable
- Two or three specific examples the model gets wrong, with your analysis of why
- Checkpoint: you can explain what your model is bad at, and why.
Weeks 7 to 8 — Wrap it in something usable
A notebook is not a deliverable. Serialise the trained pipeline, load it in a small Flask or FastAPI service, and put a simple interface in front of it. This is what the panel will actually see, and it takes far less time than teams fear.
- Save the entire pipeline, not just the model, so preprocessing travels with it.
- One prediction endpoint that accepts raw input and applies the same transformations.
- A minimal interface: an input form, a result, and an explanation panel.
- Handle bad input gracefully — an empty field must not return a stack trace.
- Checkpoint: someone outside the team can use it without instructions.
Weeks 9 to 10 — Document and rehearse
- Dataset chapter: source, size, class distribution, cleaning steps, and what you discarded.
- Methodology chapter: preprocessing, algorithms tried, tuning approach.
- Results chapter: the comparison table, confusion matrix, baseline and error analysis.
- Limitations: where the model fails and what data would fix it.
- Rehearse the demo cold, and prepare answers to the standard AI viva questions.
Mistakes that invalidate an AI project
| Mistake | Why it invalidates the result | Fix |
|---|---|---|
| Augmenting before splitting | Near-duplicates appear in both train and test | Split first, augment only the training set |
| Scaling on the full dataset | Test statistics leak into training | Fit the scaler on training data only |
| Tuning against the test set | The test score stops being an estimate of the unseen | Use a validation split for tuning |
| No baseline | Nobody can tell if the model learned anything | Compute the trivial score first |
| Random split for time series | The model sees the future during training | Split chronologically |
What good looks like at submission
A dataset you can describe from memory, a results table with a baseline, a confusion matrix you can interpret aloud, a working interface anyone can use, and an honest limitations section.
That combination is unusual enough to stand out, and every part of it is achievable in ten weeks by a team that starts with the data instead of the model.
Related projects
Student Performance Predictor
A machine learning system that flags students at academic risk early, using attendance, internal marks and engagement data.
AI Resume Analyzer
An NLP system that scores a resume against a job description, extracts skills and returns specific, actionable improvements.
Crop Disease Detection System
An image classification system that identifies plant leaf diseases from a photograph and suggests documented treatment steps.