It is 2 a.m., your M.Tech or MCA AI/ML thesis is due tomorrow, and your guide’s comment on the draft says “limitations section too thin — add substance.” You are not being asked to apologise for your model. You are being asked to name, specifically, the six or seven things any competent examiner already knows are true of your dataset, your model and your evaluation — and most students have never been shown what those actually are for an AI/ML project, as opposed to the generic “small sample size” line copied from a friend’s thesis in a different field.
The problem: generic limitations language does not survive an AI/ML viva
An examiner who works in machine learning reads “the model may not generalise to all cases” as filler, because it says nothing your evaluation chapter did not already imply. What they are looking for is specific: which dataset property limits generalisation, which design choice trades accuracy for something else, and whether you understood the trade-off when you made it — not whether you can write an apologetic paragraph. A thin limitations section costs marks directly and invites the exact follow-up questions at the viva that a well-written one heads off in advance.
Fix it now: the limitations an AI/ML thesis actually needs
Seven categories cover almost every Indian AI/ML M.Tech, MCA or B.Tech final-year project. Not every project needs all seven — write the ones that genuinely apply to your work, each with the specific number, dataset or design choice behind it, not the generic version:
- Dataset size and representativeness — state your actual training/test split size, and name what population or condition your data does not cover (a specific demographic, a specific time period, a specific class of the phenomenon you modelled)
- Class imbalance — if your target classes were unevenly distributed, say so with the actual ratio, and note how that affects the metric you reported (accuracy is misleading on imbalanced data in a way F1 or AUC is not — if you only reported accuracy, that itself is worth naming as a limitation)
- Overfitting risk and validation strategy — state whether you used a held-out test set, k-fold cross-validation, or only a single train/test split, since the last is the weakest evidence of generalisation and an honest limitations section says so
- Hyperparameter tuning scope — if you tuned only a subset of hyperparameters, or used default values for time reasons, say exactly which ones and why, rather than imply exhaustive tuning was performed
- Computational constraints — a smaller model architecture, a lower image resolution, or fewer training epochs than an ideal setup, chosen because of hardware or time limits, is a legitimate and specific limitation worth one sentence
- No real-world deployment testing — a model evaluated only on a static, offline dataset has not been tested against real-world distribution shift, latency constraints or adversarial inputs, and saying so is expected, not damaging
- Reproducibility gaps — if random seeds were not fixed, or if a third party could not exactly reproduce your reported numbers from your code and data alone, that is worth one honest sentence
A worked paragraph you can adapt tonight
This model was trained on a dataset of 4,200 labelled samples with a class ratio of approximately 3:1, and the minority class was not augmented or resampled, which may have contributed to the lower recall observed for that class relative to precision. Hyperparameters were tuned using a grid search over learning rate and batch size only; other parameters used framework defaults due to computational time constraints on the available hardware. Validation was performed using a single 80:20 train/test split rather than k-fold cross-validation, which limits confidence in the stability of the reported metrics across different data partitions. The model was not tested against real-world distribution shift or adversarial inputs, and its performance under deployment conditions therefore remains untested.
Notice the pattern: every sentence names a specific number, method or gap — nothing here is a vague apology, and every claim is checkable against your own methodology and results chapters.
A second worked example, for an NLP or text-classification project rather than an image-based one: The dataset used for training was scraped from a single source domain, which may limit the model’s applicability to text from different registers, dialects or writing styles not represented in that source. Pre-processing removed entries below a minimum token length, which excluded a subset of shorter real-world inputs the deployed model would need to handle. The model’s performance was evaluated only in English; no assessment was made of performance on code-mixed or regional-language inputs common in an Indian deployment context, which is a specific and named gap rather than a generic disclaimer. Adapt whichever example matches your project type — image, text, tabular or time-series — rather than force one template onto a different kind of model.
Where each limitation actually belongs in your report
A common mistake is dumping every limitation into one undifferentiated paragraph. Examiners find a limitations section easier to credit when it is grouped and each item is traceable to a specific earlier chapter:
- Data-related limitations (size, representativeness, class imbalance) trace back to your Chapter 3 data-collection description — reference the specific table or figure where the reader can verify the number you are citing
- Model and training limitations (hyperparameter scope, computational constraints, validation strategy) trace back to your methodology chapter’s model-configuration section
- Evaluation limitations (metric choice, no deployment testing, reproducibility gaps) trace back to your results chapter, and belong closest to the specific metric table they qualify
Grouping this way also makes the section easier to write under time pressure — work chapter by chapter through what you already wrote, rather than trying to brainstorm limitations from a blank page.
The cost of getting this wrong at 2 a.m.
A thin or generic limitations section rarely fails a thesis outright, but it is one of the most common reasons a panel sends a project back for “minor revisions” — which, three days before your final semester closes, is not minor. It costs you a resubmission cycle you do not have time for, and it signals to your examiner that you do not fully understand your own model’s boundaries, which invites harder follow-up questions on everything else in your report too.
How Tesify helps you write this section tonight
Tesify’s AI thesis assistant reads your existing methodology and results chapters and drafts a limitations section using the categories above, matched to what your project actually did — your dataset size, your validation method, your reported metrics — rather than a generic template pasted in from elsewhere. You review and adjust rather than write from a blank page at 2 a.m., and the free tier lets you try this on your own draft before you decide whether the paid plan is worth it for the rest of your thesis. Start with your own draft now — see what a specific, examiner-ready limitations section looks like for your project in minutes.
Once your limitations section is solid, the same specificity standard applies to the rest of your discussion chapter — how to turn results into argument covers the paragraph pattern for the chapter your limitations section usually closes, and how to write an M.Tech dissertation report covers where this section sits in the overall document structure if you are still assembling the rest of your report. If your thesis also needs a defensible dataset citation, M.Tech computer science thesis topics with a free dataset behind each one covers where Indian and international datasets for AI/ML projects actually come from and how to cite them. For the evaluation-metric choice your limitations section may need to reference directly, choosing the evaluation metric for an MCA machine learning project covers accuracy, F1 and AUC in the same worked-example depth as this guide. Ready to fix the section tonight? Try Tesify’s AI thesis assistant on your own draft — no card required for the free tier.
Frequently asked questions
Will admitting these limitations lower my grade?
Generally the opposite — examiners consistently rate an honest, specific limitations section as evidence of methodological maturity, while a thesis that claims no limitations or writes only generic ones reads as either naive or evasive, both of which draw harder follow-up questions at the viva.
How much does Tesify cost for a student?
Tesify offers a free tier so you can try drafting a section like this one on your own project before deciding whether a paid plan is worth it — check the current pricing on the Tesify pricing page for the exact rupee figures, since plans and student pricing can change.
Is using an AI tool to help draft my limitations section considered academic misconduct?
Using an AI assistant to help structure and phrase your own analysis of your own project’s genuine limitations is different from having it fabricate a project or a result — the underlying facts (your dataset size, your validation method, your actual metrics) come from your own work, and Tesify is built to help you write about that work clearly, not to generate results you did not produce. Check your own institution’s specific AI-use policy, since norms vary by department.
Is my data safe if I upload my thesis draft to an AI tool?
Check the specific data-handling and privacy terms of any tool before uploading unpublished research, including Tesify’s own current privacy policy, and prefer a tool that states clearly how your draft is stored and whether it is used to train other models.
What if my guide wants a longer limitations section than the seven categories here?
Use the seven categories as a floor, not a ceiling — add any project-specific limitation your guide or the literature in your sub-field commonly flags (a specific bias in a named dataset you used, a known weakness of the specific algorithm you chose) that is not already covered above.
Should limitations go in the discussion chapter or a separate section?
Convention varies by department — some Indian M.Tech and MCA programmes expect limitations inside the discussion chapter, others as a distinct section near the conclusion. Check your own department’s format guideline, and place it consistently with whichever convention your report otherwise follows.
How long should the limitations section actually be?
Long enough to cover every category genuinely relevant to your project with one specific sentence each — typically half a page to a full page for most Indian AI/ML final-year projects, rather than a single paragraph or several pages of padding. Depth per point matters more than total length.
Should I suggest how future work could address each limitation?
Yes, where you can — a limitations section that pairs each gap with a one-sentence direction for future work (a larger dataset, cross-validation, deployment testing on real traffic) reads as more forward-looking than a list of gaps with no proposed remedy, and many Indian departments explicitly expect a short future-work note alongside limitations.