In this guide
How to Get Your Base Paper Approved in One Meeting
Guides usually decide on a base paper within minutes. They are not being careless; they have seen hundreds of proposals and they know the four questions that predict trouble: is it recent, is it from a credible venue, can it actually be implemented, and is there room for your own work. If you walk in ready to answer those four questions for one paper, and with two backups ready, you can leave with a decision instead of a second meeting. This guide shows you how to prepare for that.
Why guides decide fast
A guide's time is the bottleneck in every major-project batch. When a team arrives with a vague idea and no paper details, the guide cannot evaluate it without doing the reading themselves, so the meeting ends with homework instead of a decision. When a team arrives with a verified paper, a one-page brief, and a clear own-contribution slot, the guide can check the four questions on the spot. Your preparation is what converts a discussion into a decision.
Before the meeting: the ranked shortlist of three
Never bring one paper. Bring three, ranked, with a recommendation. The ranking itself tells your guide you did the work of comparing, and it gives the meeting somewhere to go if the first choice fails.
| Slot | What it should be |
|---|---|
| First choice | The paper you actually want: recent, credible venue, implementable, clear own-contribution slot |
| Second choice | A solid alternative in the same area, slightly easier to implement |
| Third choice | A safer paper: simpler method, public dataset, well-documented baselines |
For each paper, verify the same facts before the meeting: full title, authors, journal or conference, year, and a DOI that resolves to the publisher page. A shortlist with an unverified DOI is worse than no shortlist, because it signals that the team did not check its own sources.
The one-page brief
Carry one page per paper. Not a printout of the paper, not a slide deck, one page. It should contain exactly these fields:
- Paper: full title, authors, venue, year, DOI link
- Problem in one line: what the paper solves, in plain words
- Method in three lines: the core idea, the model or algorithm, the training or evaluation setup
- Dataset: the public dataset used, and whether you can access it
- What you will implement: the part of the method you will actually build
- Your own contribution: the feature, transfer, or evaluation you add beyond the paper
- Risks: the two things most likely to go wrong, and your fallback for each
The risks section is the part most students skip and guides notice most. A team that names its risks looks prepared; a team that claims there are none looks unaware. Two honest risks with fallbacks beat a page of enthusiasm.
The 15-minute meeting plan
| Minutes | What happens |
|---|---|
| 0-2 | State your recommendation and the problem in one sentence each |
| 2-6 | Walk through the one-page brief: method, dataset, own contribution |
| 6-10 | Guide asks questions; answer from the brief, not from memory |
| 10-13 | Discuss the risks and fallbacks honestly |
| 13-15 | Ask for the decision, and confirm what happens next in writing |
The last two minutes matter most. Do not leave with a vague maybe. Ask directly: is this paper approved, approved with changes, or rejected? If it is approved with changes, write the changes down in the meeting and read them back. If it is rejected, ask which of the three backups the guide prefers, or what kind of paper they want instead. A decision you can act on is worth more than a polite conversation.
The five objections and your answers
It is too old
Answer with the newest paper that builds on it, or explain why the older paper is foundational and how your own contribution is correspondingly larger. If you cannot make either case, switch to a newer paper from your shortlist.
It is too hard to implement
Answer with the smaller variant you will actually build: a distilled model, a subset of the method, or the paper's own ablation that shows the core idea works at student scale. If the paper only works at a scale you cannot reach, it is the wrong paper.
There is no dataset
Answer with the public benchmark you will use instead, or a realistic data-collection plan with sizes, labelling method, and validation. A plan that says the dataset will be arranged later is not an answer.
It is too close to the paper
Answer with your own-contribution slot, stated in one sentence. A transfer to a new domain, a low-data protocol, an uncertainty or interpretability addition, or a deployment constraint all count, as long as they are genuinely yours and testable.
Someone already did this
Answer by showing what differs: a different dataset, a different setting, a different evaluation, or a different own feature. Prior work is normal in research; identical work is the problem. Name the difference precisely.
If the answer is no
A rejection is information, not failure. Ask two questions before you leave: what specifically was wrong with this paper, and what kind of paper would you prefer? Then go back to your shortlist the same day. Guides check papers quickly, and teams that return the same day with a corrected shortlist get approved faster than teams that disappear for two weeks. Keep the rejected paper in your notes with the reason; it stops you from proposing it again to another guide or in another semester.
After approval: lock it in writing
Approval given verbally in a corridor has a habit of being forgotten. Before you leave, confirm the approved paper, the own-contribution slot, and the next deliverable in a short message or email to your guide. This protects both sides: you have a record of what was agreed, and your guide has a record of what they approved. It also becomes the first line of your abstract.
A worked example of a brief
Paper: Self-Supervised and Interpretable Anomaly Detection Using Network Transformers, by D. L. Marino, C. S. Wickramasinghe, C. Rieger, and M. Manic, IEEE Transactions on Industrial Informatics, 2025, DOI 10.1109/TII.2025.3534443. Problem: detecting anomalies without labelled examples. Method: self-supervised pretraining of a transformer, plus an interpretable scoring step. Dataset: the paper uses network traffic data; a student transfer would use a public image defect dataset instead. Own contribution: the transfer itself, a low-label evaluation protocol, uncertainty triage, and localisation maps. Risks: the transfer may underperform the paper's setting, in which case the fallback is a narrower defect set and a simpler baseline comparison; and labelling even a small evaluation set takes time, in which case the fallback is a smaller, carefully labelled test set with the protocol unchanged. That brief fits on one page, and a guide can decide on it in minutes.
If you want a base-paper project built
Projectech publishes IEEE-anchored major-project listings. Each listing names its verified base paper with journal, year, and DOI, states what gets implemented from the paper, and separates the own-features split from the paper's work. Enquiries go through the WhatsApp enquiry flow, starting with your college, branch, semester, and whether your guide has approved a paper yet. Internal links to those listings will be added to this guide once the listings are live.
FAQ
Should I email the paper before the meeting?
Yes, if your guide accepts email. Send the one-page brief and the DOI link, not the full PDF, the day before. A guide who has skimmed the brief before you arrive decides faster than one seeing it cold.
What if my guide has never heard of the paper?
That is normal and fine. Your brief exists precisely so the guide does not need prior knowledge. What matters is that the paper is verifiable, recent, and implementable, not that it is famous.
Can I change the paper after approval?
Only with your guide's agreement, and it costs time. Treat approval as a commitment: the paper you get approved is the paper you build on, unless the guide agrees to a change.
Does one meeting really work for a whole team?
Yes, when the team arrives aligned. Decide your recommendation together before the meeting. A team that argues about its own shortlist in front of the guide does not get a decision that day.
Who gives the final approval?
Your guide and your department. No outside service, listing, or guide article can guarantee approval. Preparation raises your chances; the decision stays with them.
Limitations
Guide meetings vary by department: some guides want a full proposal document first, some decide from a brief, some ask the team to present to the whole class. Adapt this plan to your department's actual process rather than following it literally. For paywalled papers, use your library access or the authors' legally available preprint where one exists; never circulate pirated copies. If your guide asks for a different format, that format wins over anything written here.