In this guide
How to Defend an IEEE Base-Paper Project in Your Viva
Quick answer
A base-paper viva is an oral defence of two things at once: the published paper you built on, and the change you made to it. Examiners check whether you understand the paper, what your own feature adds, and whether your results support your claims.
An IEEE base-paper viva tests whether you understand the paper you built on, what you changed, and whether your results support your claims. Answer in three parts: what the paper did, what your feature adds, and what evidence supports it. Examiners forgive an honest limitation; they do not forgive a claim you cannot explain.
| What examiners test | What students usually prepare | What actually holds up |
|---|---|---|
| Understanding of the base paper | A summary of the abstract | The problem, method, and limits in your own words |
| Your own contribution | A feature list | One clear change, and why it matters |
| Results | A single best number | The metric, the split, and what the number does not prove |
| Ownership | Slides read aloud | Code, data, and decisions you can walk through live |
Why a base-paper viva is different
In a regular project viva, most questions are about what you built. In a base-paper viva, every answer gets compared against the paper. If you describe the paper's method as your own idea, examiners notice. If you cannot say where the paper ends and your work begins, they will keep asking until the boundary appears.
That boundary is the whole defence. Get it sharp before you walk in, and most hard questions become easy: they are either about the paper, about your change, or about the evidence connecting the two.
If you are still choosing a paper, read How to Get Your Base Paper Approved in One Meeting and How to Read an IEEE Paper in a Weekend first. If your build is still in progress, Reproduce Your IEEE Base Paper First explains why the baseline must be frozen before your own features go in.
Step 1: Draw your base-versus-own map
Write one table and keep it in front of you during preparation. Every row is one part of the project, and every row must have all three columns filled. Any row with an empty evidence column is a question waiting to happen.
| Part of the project | From the base paper | Your own feature | Evidence you can show |
|---|---|---|---|
| Problem and data | The paper's task and dataset | Your adapted task or added data | Dataset note with source and licence |
| Method | The paper's architecture or pipeline | The block you changed or added | Code with the changed block marked |
| Training or setup | The paper's training setup | Your changed settings and why | Training log and configuration file |
| Evaluation | The paper's metric and split | Your comparison on the same split | Results table with the split stated |
| Limits | Limits the paper states | Limits your change introduces | A written limitations slide |
Work through the table out loud, one row at a time, until you can explain each row without looking at your slides. That rehearsal is the viva. Slides are only the visual aid.
Worked example: defect detection
Take the tracker-verified paper by Marino and colleagues, Self-Supervised and Interpretable Anomaly Detection Using Network Transformers, IEEE Transactions on Industrial Informatics, 2025, DOI 10.1109/TII.2025.3534443. The paper's framework is self-supervised and interpretable anomaly detection, originally for network traffic and industrial control data. A student project transfers that framework to images, using a vision transformer with masked autoencoding for low-label industrial defect detection.
The base-versus-own map for that transfer is honest only if it says so plainly: the self-supervised framework and the interpretability idea come from the paper; the image transfer, the defect dataset, and the low-label training setup are the student's own work. Claiming the transfer as the paper's contribution, or the framework as your own invention, both fail the same check.
Worked example: federated fine-tuning
A second tracker-verified example is ECLoRA, published in IEEE Transactions on Neural Networks and Learning Systems, 2025, DOI 10.1109/TNNLS.2025.3586545. A student building on it must be able to say what federated low-rank adaptation means in plain language, which part of the setup they reproduced, and which part they changed, such as the client setup, the data split, or the evaluation task. The examiners do not need a recital of the paper. They need proof you know which decisions were yours.
Step 2: Learn the 30 questions examiners ask most
Viva questions sound unpredictable, but they cluster into six groups. Prepare two or three answers per group, and you have covered nearly every viva. For each question below, write your answer in the three-sentence shape from Step 3 before you rehearse it.
About the base paper
- Why did you choose this paper over others in the same area?
- What problem does the paper solve, and who has that problem?
- Explain the paper's method in your own words, without reading the slides.
- What are the paper's limitations, as stated by its authors?
- What would break if you removed one key part of the paper's method?
About your own contribution
- What exactly is your own feature, in one sentence?
- Why is your feature needed, and what fails without it?
- What did you try that did not work, and what did you learn from it?
- How is your work different from simply running the paper's code?
- If you had four more weeks, what would you change first?
About method and data
- Why this dataset, and what are its licence and access conditions?
- How did you split the data, and could any test sample leak into training?
- Why this architecture or model, and what alternative did you reject?
- What preprocessing did you apply, and does it match the paper's?
- How did you handle class imbalance, missing data, or noisy labels?
For dataset questions, the companion guide How to Choose a Dataset for Your IEEE Base Paper Project covers licences, splits, and substitution when the paper's data is gated.
About results
- What metric did you use, and why is it the right one for this task?
- What is your baseline, and did you beat it on the same split?
- Show me a case where your model fails, and explain why.
- Would your result hold on a different dataset? Why or why not?
- What does your result not prove, even though it looks good?
About the demo and implementation
- Walk me through the code path from input to output.
- What happens if the input is missing, corrupt, or out of range?
- How long does one run take, and on what hardware?
- What did you build yourself, and what came from a library or tutorial?
- If the demo fails right now, what is your backup?
About scope, team, and future work
- Who did what in the team, and what did you personally build?
- What part of the project is design-stage, and what is actually running?
- Where would this be used in practice, and what would stop it working there?
- What is the biggest risk in your project, and how did you reduce it?
- What would you do differently if you started again tomorrow?
Question 27 matters more than students expect. Calling design-stage work implemented is the fastest way to lose trust in a viva, because the next question is always a demo request. Label design as design, and running code as running code, and examiners can calibrate every later answer.
Step 3: Answer in three sentences
Long answers are where vivas go wrong. A five-minute ramble gives examiners five new things to question, and usually includes one claim you cannot defend. Use this shape for every technical answer:
- The claim: one sentence stating the point.
- The reason: one sentence saying why it is true or why you chose it.
- The evidence: one sentence pointing at something checkable, such as a table, a log, a code file, or a failure case.
Then stop. If the examiner wants more, they will ask a follow-up, and that follow-up tells you exactly what they care about. Silence after a complete answer is not failure; filling it with guesses is.
Example answer to question 9, for the defect-detection transfer: The paper contributes the self-supervised and interpretable framework, and the image transfer with the low-label defect setup is our own work. We transferred it because factory defect images are scarce and labelling them is expensive, which matches the paper's low-label motivation. Our evidence is the frozen baseline reproduction plus the comparison on the same split, with the changed blocks marked in code.
Step 4: Prepare your demo like it will fail
Live demos fail in vivas more often than in rehearsals, because the room, the network, and the hardware are all different. Examiners judge the failure handling as much as the demo itself, so prepare three layers:
- Live run: the real system, with inputs you have tested in advance.
- Recorded fallback: a short screen recording of the same run, on the same laptop, playable offline.
- Static fallback: screenshots of the key outputs, plus the results table, so you can keep answering even with no running code.
Rehearse the failure sentence out loud: what broke, what you already know about it, and what the fallback shows. A calm sentence such as the network call failed, so here is the recorded run on the same input, keeps the viva moving. Pretending a broken demo is working, or blaming the equipment, stops it.
Test the demo on the actual presentation laptop the day before, with the exact inputs you will use. If the demo needs the internet, have an offline input ready. If it needs a camera or sensor, have a recorded input file that exercises the same code path.
Step 5: Team viva rules
Examiners ask individuals, not teams. Agree these rules before the viva, and stick to them under pressure:
- Each member owns named parts of the project and answers first on those parts.
- Nobody answers a question about someone else's part by guessing; hand it over by name.
- Nobody contradicts a teammate in the room. If an answer was wrong, correct it calmly with evidence, not with an argument.
- If two members disagree about a design choice, say so honestly and explain the trade-off that settled it.
A team that hands questions to the right person looks more competent than a team where one person answers everything. Examiners read the second pattern as one person doing the project.
Step 6: The honest answers
Three sentences save more vivas than any technical preparation. Learn them word for word, and use them instead of guessing.
- I don't know: I don't know that yet. The closest evidence I have is this, and I would check it by doing that.
- A limitation: That is a real limitation. It matters when this condition holds, and it does not change our claim because we tested only this scope.
- Out of scope: That is outside our scope, and we excluded it because of this reason. It would be the first extension if we continued.
Never invent a number, a paper, or a result under pressure. Examiners can check a cited paper in seconds, and a fabricated detail poisons every honest answer that follows it. An honest gap is a normal part of a student project. A defended invention is not.
Two-week viva preparation plan
| When | What to do | Done when |
|---|---|---|
| Day 1 to 2 | Finish the base-versus-own map and the limitations slide | Every row has evidence, and limits are written down |
| Day 3 to 5 | Write answers to all 30 questions in the three-sentence shape | Each answer fits in three sentences with checkable evidence |
| Day 6 to 8 | Rehearse out loud, with teammates asking follow-ups | You can answer without reading slides |
| Day 9 to 11 | Test the demo on the presentation laptop, build all three fallback layers | Demo runs, recording plays offline, screenshots ready |
| Day 12 to 13 | Full mock viva, timed, with hostile follow-ups | You used the honest answers at least once without panic |
| Day 14 | Light review only: map, limits, demo inputs, documents | You stop rehearsing and rest before the viva |
Do not rewrite slides in the final two days. New slides introduce new claims you have not rehearsed, and unrehearsed claims are where vivas unravel.
Frequently asked questions
Do examiners expect us to beat the base paper's results?
No, not as a rule. They expect a fair comparison: your reproduction of the paper's setup, your change, and results measured on the same split with the metric stated. A modest, honestly measured result with a clear baseline is stronger than a large number with no baseline, no split, and no failure case.
What if the examiner has not read our base paper?
Explain it from scratch in plain language: the problem, the method in three steps, and the limits. Do not assume familiarity, and do not hide behind jargon. If the examiner knows the paper well, the same explanation still works, because it proves understanding rather than recall.
What if our results are worse than the paper's?
Say so, and explain why. Common honest reasons include a smaller dataset, different hardware, a changed task, or a substitution for gated data. Show the baseline, the changed setup, and what the gap tells you. Hiding a worse result always fails, because the comparison table is the first thing examiners check.
How much code should we be ready to explain?
Every file you claim as your own work, and every changed block in reproduced code. You do not need to recite library internals, but you must be able to walk from input to output through your own code and say what each stage does and why it is there.
What if two teammates give different answers?
The second speaker corrects the record calmly, with evidence, and without arguing. Say what the correct position is, point at the table or code that shows it, and move on. Examiners notice the correction; they also notice how the team handles it.
Should we mention that a guide or service helped with the build?
Be honest about what help you received and what you did yourself, following your college's rules on authorship and acknowledgement. What examiners test is your understanding and your own contribution, so the honest split between help received and work done is part of the defence, not a separate problem.
Limitations
This guide describes how base-paper vivas usually run in Indian BTech major projects, but every department sets its own format, marking scheme, and document rules. Your department's template and your guide's instructions override anything here. Nothing in this guide guarantees approval, marks, or any particular outcome; final assessment always rests with your guide and your college.
The worked examples use only tracker-verified papers, and they describe those papers qualitatively. No accuracy, efficiency, or performance figure is claimed for any student build in this guide, because a student result depends on its own data, split, and setup.
Get help preparing your base-paper project
If you want help with the build behind the viva, message Projectech on WhatsApp for a quotation covering the full scope: base-paper selection and approval support, baseline reproduction, your own-feature build, and Phase-1 to Phase-2 documentation. The price is set after your topic, base paper, and compute scope are locked, and delivery is planned across Phase-1 to Phase-2 so your review documents and your demo are ready together. Final approval always rests with your own guide and college.
Related reading: IEEE Base Paper vs Regular Project: What Guides Actually Check, Phase-1 vs Phase-2: What to Submit Each Semester, and the live IEEE-based listings for self-supervised ViT defect detection and federated LoRA fine-tuning.