MSBTE Project Submission: Documents You Need

MSBTE project submission typically requires five items: your project logbook, the written project report, bound certificate pages, a soft copy of the report and code, and the micro-project proposal. Exact formats vary by institute and scheme year, so confirm the list with your guide early rather than the week before submission. Keep the report's page order standard — certificate, acknowledgement, abstract, contents, then chapters — maintain the logbook weekly as evidence of your process, and plan for 2–3 hardbound copies plus the soft copy.

Published by Projectech4 min readPublished
A neat stack of MSBTE project submission documents with an open logbook, a hardbound project report with seal, and a USB drive on a desk.
Illustration generated for this guide.
In this guide

Submission day has a quiet way of exposing everything you postponed. Students who built excellent projects have lost marks over a missing logbook entry or a report bound in the wrong order. The documents are part of the deliverable — treat them with the same seriousness as the hardware.

The five documents you need

MSBTE project submission typically requires these five items. Confirm the exact list with your guide early, because formats and requirements vary by institute and scheme year — the MSBTE official website publishes scheme documents, but your institute's project coordinator has the final word on what your batch must submit.

# Document What it is Why it matters
1 Project logbook A dated, handwritten record of weekly work: what you did, problems faced, decisions taken Evidence of your process — examiners check that the project grew over the semester, not the last fortnight
2 Project report The bound written document describing the full project The permanent record of your work; the external examiner reads this before your viva
3 Bound certificate pages Signed certificate, declaration, and approval pages bound into the report Formal proof the work is yours and was supervised and approved
4 Soft copy Report PDF, source code, and supporting files on pen drive or as specified Lets examiners verify code and keeps an archivable copy with the department
5 Micro-project proposal The approved proposal document from your earlier micro-project work Shows continuity and that earlier approvals were obtained properly

Warning: Do not assume last year's format still applies. Scheme revisions change report formats, certificate wordings, and page requirements. One confirmation meeting with your guide in the first month saves a rebinding scramble in the last week.

The logbook: evidence of your process

The logbook is the document students neglect most and examiners value most. It should be handwritten, dated, and maintained weekly — not reconstructed the night before submission. Each entry needs only a few lines: what was attempted that week, what worked, what failed, and what was decided. Failed attempts belong in the logbook; they prove you tested and iterated rather than copying a finished design. A logbook with honest failure entries and course corrections reads as genuine. A pristine logbook with no problems reads as fiction.

Report page order

Examiners expect a standard sequence. Keep this order unless your institute specifies otherwise:

  1. Title page
  2. Certificate (signed by guide, HOD, and principal as required)
  3. Declaration by the students
  4. Acknowledgement
  5. Abstract
  6. Table of contents, list of figures, list of tables
  7. Chapters: introduction, literature review, system design, implementation, testing and results, conclusion and future scope
  8. References
  9. Appendices (datasheets, lengthy code listings)

Get the certificate and declaration pages signed early — chasing signatures in submission week is a classic, avoidable crisis. Print one draft copy for your guide's review before you send anything for binding.

Hardbound copies and the soft copy

Plan for 2–3 hardbound copies plus the soft copy: typically one for the department library, one for your guide, and one for yourselves. Binding takes a few working days at a print shop, longer in submission season when every batch in the city is queueing — book your slot at least a week ahead. For the soft copy, include the final report PDF, all source code with a short readme explaining how to build and run it, and key datasheets. Label the drive clearly with your project title, names, and year.

A submission timeline that works

  • 8 weeks out: Confirm the exact document list and formats with your guide.
  • 6 weeks out: Start the logbook properly if you haven't — and begin the report draft alongside the build, not after it.
  • 3 weeks out: Full report draft to your guide for review.
  • 2 weeks out: Corrections done; certificate pages signed.
  • 1 week out: Binding booked and submitted; soft copy assembled and checked on a different computer.

Documentation takes the back third of any project — if you haven't started writing by the halfway mark of your build window, your project timeline needs adjusting now, not later.

More project guides

All guides

Random Forests Explained: Why Decision Trees Vote Better Together

Decision trees are readable but overfit; random forests fix this by training hundreds of varied trees on bootstrapped data with random feature subsets, then letting them vote. This guide explains Gini impurity, bagging, out-of-bag validation and the four hyperparameters that matter, with a complete scikit-learn workflow, honest feature-importance practices, and the mistakes students keep making.

Read guide

Rectifiers, Clippers and Clampers: The Diode Circuits Behind Every Power Supply

Every power supply hides the same trick: diodes forcing AC to flow one way, and a capacitor smoothing the pulses into DC. This guide explains half-wave and bridge rectifiers with real numbers, shows how to size the filter capacitor with one formula, and covers clipper and clamper circuits — the diode techniques behind input protection, DC restoration and voltage multipliers — plus a bench build you can measure yourself.

Read guide

AI Agents on ESP32: Agentic IoT Final-Year Projects

An agentic IoT system observes, reasons, acts, remembers and explains. On ESP32 that means a split architecture: the chip senses and acts while a small local model (Ollama on your laptop) reasons over MQTT — a full LLM needs gigabytes of RAM the chip doesn't have. This guide covers three working patterns (host-reasoned agent, on-device tinyML on ESP32-S3, and a hybrid of both), plus Wi-Fi CSI presence sensing, parts and budget for India, code shapes, and honest limits to state in your report.

Read guide