In this guide
How to Write the Abstract for Your IEEE Base-Paper Project
Quick answer
The abstract is the one-paragraph summary at the front of your project report. It states the problem, the base paper's method, your own feature, and what the build will show or showed — in 150 to 250 words, with no citations, no figures, and no claims the report cannot support.
Write it last, after the methodology and results chapters are fixed, as five sentences — one per job — past tense for finished work, future tense for planned Phase-1 work. A reader who reads the abstract should be able to say what problem you solved, whose method you built on, what you added, and how you will prove it works.
| Document | What it does | Length |
|---|---|---|
| Abstract | Summarises the whole project in one paragraph | 150–250 words |
| Synopsis | Proposes the project before it is built, for approval | 1–2 pages |
| Introduction | Opens the report and sets up the problem in full | A full chapter section |
| Summary | Repeats the abstract in more detail at the end of a submission | Up to 2 pages |
The problem: three ways abstracts fail
Most abstracts that come back from a guide fail in one of three ways, and all three are easy to recognise once you know what to look for.
The first is the abstract written first. A student writes it before the build exists, so it promises results nobody has measured and describes a method nobody has finished choosing. When the build changes — and it always changes — the abstract is wrong in every sentence, and the guide notices in the first meeting. The abstract is a summary of the report, so it is written after the methodology chapter is fixed — not before it.
The second is the copy of the base paper's abstract. The student lifts the wording of the paper they are building on, swaps in their own title, and submits it. A guide who has read the paper recognises it immediately, and the abstract now describes the paper's contribution instead of the student's. Your abstract must describe your project: the base method as you reproduced it, plus the feature you added, plus your evaluation.
The third is the vague abstract. It says the project is "an efficient and novel system using advanced technology" without naming the problem, the method, the dataset, or the result. Every sentence is true of a hundred other projects, which means it says nothing about yours. If you can swap your project title for another team's title and the abstract still reads correctly, it is vague.
What the abstract must do: five jobs
A good abstract does five jobs, and each one maps to one sentence. That is the whole structure of this guide: five sentences, five jobs, in this order.
- Name the problem. One sentence on what is broken or missing in the real setting, in plain words. Not the history of the field — the specific gap your project addresses.
- Name the base paper and its method. One sentence that cites the paper you built on — authors, journal, year — and states its method in one clause. This is the sentence that proves you are building on a real, verifiable paper rather than a vague idea. The paper you name here is the same one your literature survey is anchored on, so the two documents agree.
- Name your own feature. One sentence on what you added or changed, and why. This is the sentence your guide reads most carefully, because it is the difference between reproducing a paper and doing a project.
- Say how you prove it works. One sentence on the evaluation: the dataset or test setup, the baselines you compare against, and the measures you report. In a Phase-1 abstract this is written as a plan; in a Phase-2 abstract it reports what you measured. Pick the dataset before you write this sentence — choosing the dataset is a decision in its own right, not a detail to fill in later.
- State the scope and the verdict. One sentence on what the build covers, what it does not cover, and — for a finished project — what the results mean. This is where honest limits belong, not in a footnote nobody reads.
The five-sentence structure
| Sentence | Job | What goes in | What stays out |
|---|---|---|---|
| 1 | Problem | The specific gap, in the real setting | Field history, motivation essays |
| 2 | Base method | Authors, journal, year, method in one clause | The paper's results as your own |
| 3 | Own feature | What you added, and why it matters | Implementation detail, tool names |
| 4 | Evaluation | Dataset or setup, baselines, measures | Numbers you have not measured yet |
| 5 | Scope and verdict | What is covered, what is not, what it means | New claims, future-work promises |
Write the five sentences in order and do not merge two jobs into one sentence. Merged sentences are how abstracts become vague: the problem and the method collapse into one clause, the own feature disappears, and the evaluation never appears at all. If a sentence is doing two jobs, split it and cut something else to stay inside the word budget.
Use the past tense for work that is finished and the future tense for work that is planned. A Phase-1 abstract says "the system will be evaluated on" — a Phase-2 abstract says "the system was evaluated on". Mixing the two tenses in one abstract is the most common tell that the abstract was written before the work was done.
The word budget: 150 to 250 words
IEEE's own guidance for abstracts is 150 to 250 words, written as a single paragraph, self-contained, with no abbreviations left undefined, no footnotes, no references, and no displayed equations or tables. Your college template may set a different limit — some departments ask for 200 to 300 words, some ask for a fixed 150. The college template wins: if it says 200 words, write 200 words, not 250.
Spend the budget roughly like this:
| Sentence | Share of the budget | Rough words |
|---|---|---|
| 1 — Problem | About 15% | 25–35 |
| 2 — Base method | About 20% | 30–45 |
| 3 — Own feature | About 25% | 35–55 |
| 4 — Evaluation | About 25% | 35–55 |
| 5 — Scope and verdict | About 15% | 25–35 |
The own feature and the evaluation get the most words because they are the two sentences that distinguish your project from the base paper. If your problem sentence is running to 60 words, you are writing an introduction, not an abstract — cut the background and keep the gap.
Count the words before you submit. Word-count tools are built into every editor, and a guide who asked for 200 words will count. An abstract that is 320 words long signals that the student did not read the template; an abstract that is 90 words long signals that the project has nothing to say.
Phase-1 abstract vs Phase-2 abstract
You will write the abstract twice: once for Phase-1, when the build is planned, and once for Phase-2, when the build is done. They are not the same document, and submitting the Phase-1 version with the final report is a common mistake. The two phases and what each one expects are laid out in the Phase-1 vs Phase-2 guide.
| Phase-1 abstract | Phase-2 abstract | |
|---|---|---|
| Tense | Future: what will be built and measured | Past: what was built and measured |
| Sentence 4 | Planned evaluation: dataset, baselines, measures | Measured evaluation: the same, plus the outcome |
| Sentence 5 | Scope of the planned build | Scope of the finished build, plus what the results mean |
| Numbers | None — no result exists yet | The headline outcome, if the methodology chapter supports it |
| Purpose | Shows the guide the plan is concrete and checkable | Shows the examiner the work is finished and honest |
When you update the abstract for Phase-2, change sentences 4 and 5 and leave sentences 1 to 3 mostly alone — unless the build itself changed, in which case sentence 3 must change too. Never carry a Phase-1 promise into the final report: if the abstract says the system "will be evaluated on" a dataset and the final report never evaluates it, the abstract is making a false claim.
Keep both versions. When your guide asks what changed between the phases, the two abstracts side by side are the fastest honest answer you can give.
Worked example: a Phase-1 abstract
This is a Phase-1 abstract for a real project — self-supervised defect detection built on a tracker-verified base paper — written to the five-sentence structure. It states a plan, not results: no accuracy figure appears anywhere, because no experiment has run yet.
Industrial visual inspection still depends on human operators checking parts on a production line, a slow and inconsistent process that misses small surface defects. This project builds on Marino et al. (IEEE Transactions on Industrial Informatics, 2025), who proposed a self-supervised vision transformer that learns defect patterns from a small number of labelled examples. The base method is reproduced first, then extended with an uncertainty-aware triage stage that routes low-confidence parts to a human inspector instead of forcing a decision. The system will be evaluated on the public MVTec AD and VisA defect-detection datasets, measuring detection quality and the share of parts the triage stage holds back, against the reproduced baseline and the PatchCore and PaDiM baselines. The build is scoped to a working laboratory prototype with a documented experiment protocol, and its results will be reported separately for the reproduced baseline and the added triage stage so a reader can see exactly what the own feature contributes.
Word count: 158 words. Sentence by sentence:
- Sentence 1 names the problem in the real setting — human inspection, slow, inconsistent, misses small defects. No field history.
- Sentence 2 names the base paper — Marino et al., IEEE Transactions on Industrial Informatics, 2025 — and its method in one clause. The DOI for this paper is 10.1109/TII.2025.3534443; the abstract itself carries no DOI, because abstracts carry no references — the DOI belongs in the report's reference list. Before writing this sentence, the base method must actually be understood well enough to reproduce its results; an abstract cannot summarise a method the student has not yet run.
- Sentence 3 names the own feature — the uncertainty-aware triage stage — and why it exists: to avoid forcing a decision on low-confidence parts.
- Sentence 4 names the evaluation as a plan — MVTec AD and VisA datasets, detection quality and triage share, against the reproduced baseline and two standard baselines — with no numbers claimed.
- Sentence 5 states the scope — a laboratory prototype with a documented protocol — and the reporting rule that keeps the base-versus-own split visible.
The same five-sentence shape works for any domain. A federated learning project names its base paper the same way — for example, the federated LoRA fine-tuning listing built on the ECLoRA paper (IEEE Transactions on Neural Networks and Learning Systems, 2025, DOI 10.1109/TNNLS.2025.3586545) — and then spends sentence 3 on its own extension and sentence 4 on its own evaluation. The structure does not change; only the content does.
The keywords line
Most templates ask for 3 to 5 keywords under the abstract. Choose them from the words a reader would actually search for: the method family, the application, and the dataset or setting. For the worked example above, sensible keywords are self-supervised learning, vision transformer, industrial defect detection, and uncertainty-aware triage. Do not repeat the title word for word, and do not list generic words like "machine learning" alone — they describe a thousand projects. Check the keywords against the abstract itself: every keyword should appear in the abstract or be an obvious synonym of a phrase in it. If a keyword appears nowhere in the abstract, either the keyword is wrong or the abstract is missing something.
Seven mistakes that send the abstract back
| Mistake | What the guide sees | Fix |
|---|---|---|
| Written before the build | Promises results nobody measured | Write it last; rewrite it when the build changes |
| Copied from the base paper | The paper's contribution, not yours | Sentences 3 and 4 must be about your project |
| Vague adjectives, no nouns | "Efficient, novel, advanced system" | Name the problem, method, dataset, and measures |
| Results invented for Phase-1 | Numbers with no experiment behind them | Phase-1 sentence 4 is a plan, never a result |
| Acronyms never defined | A reader outside your team cannot follow it | Define each acronym on first use, or drop it |
| Citations or references | Reference numbers in a paragraph that allows none | Move every citation to the reference list |
| Over the word limit | A template the student did not read | Cut background first, then adjectives, then the problem sentence |
Two more habits worth breaking. First, do not open with "In this modern era of rapid technological advancement" — it spends 10 words saying nothing, and every guide has read it a hundred times. Second, do not close with "the project will be useful for society" — usefulness is shown by the evaluation, not claimed in the last line.
What your guide checks first
When you send the abstract to your guide, this is the order in which it is usually read — and the point at which it is usually sent back.
| Check | What the guide asks | Send-back if |
|---|---|---|
| Is the base paper real? | Can I find this paper by its authors, journal, and year? | The citation is vague, or the paper cannot be found |
| Is the own feature visible? | Can I point to the sentence that says what the student added? | Sentence 3 is missing or describes the base method again |
| Is the evaluation checkable? | Dataset, baselines, and measures — are they named? | Sentence 4 says "will be tested" with no dataset or baseline |
| Does the tense match the phase? | Phase-1 future, Phase-2 past | A Phase-1 abstract claims results, or a final abstract promises work |
| Is it inside the word limit? | Counted, not estimated | Over the template limit, or under 100 words |
If your abstract passes these five checks, the remaining feedback is usually wording, not structure. If it fails any of them, fix the structure before polishing the wording — a polished vague abstract is still vague.
Pre-submission checklist
- Five sentences, in order: problem, base method, own feature, evaluation, scope and verdict.
- Base paper named with authors, journal, and year; verifiable on IEEE Xplore.
- Own feature in its own sentence, not merged with the base method.
- Evaluation names the dataset or setup, the baselines, and the measures.
- No number appears that no experiment has produced.
- Tense matches the phase: future for Phase-1, past for Phase-2.
- Word count inside the template limit; counted, not guessed.
- Every acronym defined on first use; no citations, figures, or references inside the paragraph.
- Keywords chosen: 3 to 5, each appearing in the abstract or an obvious synonym of a phrase in it.
- Read aloud once: if a sentence cannot be read in one breath, split it.
Frequently asked questions
Should I write the abstract before or after the rest of the report?
After. Write the methodology chapter first, then the results chapter, then the abstract. The abstract summarises the report, so it cannot be finished before the report exists. A draft abstract written early is fine as a planning note, but treat it as a draft and rewrite it at the end.
Can I copy the base paper's abstract and change a few words?
No. The base paper's abstract describes the paper's contribution; your abstract must describe your project. Copying it is also the fastest way to lose your guide's trust, because the guide has read the paper. Use the paper's abstract as a model for structure, never as text to reuse.
What if my college template asks for a different word limit?
Follow the template. The 150-to-250-word range in this guide comes from IEEE's own author guidance; your department's format is the one your report is marked against. If the template says 200 words and this guide says up to 250, write 200.
My project has no results yet — what do I put in sentence 4?
Write the evaluation as a plan: the dataset, the baselines, and the measures you will report. That is exactly what a Phase-1 abstract is for. Never invent a number to fill the gap — a planned evaluation is honest, an invented result is not, and your guide can tell the difference when the results chapter arrives.
How do I mention the base paper without citing it in the abstract?
Name it in the sentence: authors, journal, and year, as in the worked example. The full citation with the DOI belongs in the report's reference list, not in the abstract. Abstracts carry no references — that is part of the IEEE format, not a shortcut.
What if my own feature changed during the build?
Rewrite sentence 3 and sentence 5 to match the build you actually finished, and check sentence 4 still describes the evaluation you actually ran. An abstract that describes an earlier version of the project is wrong in the same way as an abstract written before the build. Expect to defend the change in viva — the viva-defense guide covers how to present a base-versus-own map when the build moved on from the plan.
Limitations
This guide covers the abstract for an IEEE base-paper project report: one paragraph, five sentences, 150 to 250 words. It does not cover conference-paper abstracts, journal submissions, or thesis abstracts, which follow their own formats and reviewer expectations. Word limits, keyword counts, and paragraph rules vary by college — your department template and your guide's instructions override anything in this guide. The worked example is a Phase-1 planning abstract for one specific project; your abstract must be written from your own base paper, your own feature, and your own evaluation, not adapted from the example's sentences.
Get help with the full build
If you want the whole project delivered — base-paper reproduction, your own feature, the experiment protocol, the results tables, and the full report including the abstract, methodology, and results chapters — message Projectech on WhatsApp with your base paper title and DOI, your branch, and your Phase-1 or Phase-2 deadline. You will get a quotation that states the scope (paper implementation, own-feature build, documentation), the price, and the delivery timeline before any work starts. Final approval of the topic and the report always rests with your own guide and college.