In this guide
Reproduce Your IEEE Base Paper First: A Baseline-Before-Features Guide
Quick answer
Baseline reproduction means rebuilding your base paper's method from the paper itself, running it unchanged, and proving it behaves as described before you extend it.
Reproducing a base paper means rebuilding its method from the paper, running it on comparable data, and checking your results against the published ones before changing anything. Freeze that working version as your baseline, log every setting, and only then add your own feature, so later changes can be judged fairly.
| Approach | What you build first | When results differ, you learn | Review evidence |
|---|---|---|---|
| Reproduce first | The paper's method, unchanged | Your implementation or your data differs from the paper | A frozen baseline plus a comparison against the paper |
| Features first | Your own idea on top of an untested method | Nothing — the fault could be in either layer | A demo with no reference point |
| Paper summary only | No running code | Nothing about whether the method works | Slides, not a system |
Reproduce first is slower in week one and faster for the rest of the project, because every later decision has something to compare against.
Why reproduction comes before your own features
Most base-paper projects fail in the same quiet way: the team builds its own feature on top of a method they never got working, and when the demo misbehaves nobody can say which layer is at fault. The guide cannot help either, because there is no clean version to test against. A frozen baseline fixes this. It turns arguments about the project into a checkable comparison: baseline versus new version, on the same data, with the same metric.
Reproduction also proves understanding. A team that can rebuild a method, explain each step, and show where its results match or differ from the paper has done the core intellectual work of the project. Your own feature then becomes a genuine extension with a measurable effect, instead of a second untested idea stacked on the first.
This guide assumes your base paper is already approved. If it is not, sort that out first — the approval guide in the related guides covers the meeting, and the reading guide covers the three-pass method for understanding a paper before you write any code.
The reproduction protocol in seven steps
Step 1: Extract a claim table from the paper
Before coding, write down exactly what the paper claims, in your own words, one row per claim: the input, the method step, the output, and the result the authors report. Note which claims are central (the method's core idea) and which are secondary (ablations, extra datasets, minor variants). Your reproduction target is the central claims only. Trying to reproduce every ablation in week one is how teams run out of semester.
Also record what the paper does not specify: hyperparameters it omits, preprocessing details it glosses over, and any step described only as "standard practice". Those gaps are your risk list, and Step 6 exists for them.
Step 2: Pin down the data and the split
Find the dataset the paper used, its licence and access route, and the exact train, validation and test split. If the dataset is gated, paywalled, or too large for your machine, decide on a substitute now, not mid-build — the substitution rules below apply. Never tune on the test split, and never report test numbers from a run that was selected using the test set. That is the single most common way student results look better than they are, and reviewers who know the field check for it.
Log the dataset version, the number of samples in each split, and any filtering you applied. If a future run disagrees with an earlier one, the split is the first thing to check.
Step 3: Rebuild the smallest runnable version
Implement the method's core first and ignore extensions, ensembles, and optimisation tricks until the core runs end to end. A small version that trains, predicts, and can be measured beats a faithful-looking large version that never finishes a run. Keep the code structured so each paper section maps to one identifiable part of your code — when a result is wrong, you want to suspect one section, not the whole program.
Use the authors' released code only if it exists, is legally available, and your guide agrees. Even then, read it rather than running it blind: code you cannot explain is not evidence you understood the paper, and it hides exactly the details your review will ask about.
Step 4: Match preprocessing exactly
Preprocessing mismatches cause more reproduction failures than model errors. Image size, normalisation values, text tokenisation, missing-value handling, feature scaling — each one changes results, and papers sometimes state them in a single sentence or a footnote. Copy them literally before inventing your own. Where the paper is silent, pick the most standard choice, write it down, and treat it as a variable to test in Step 6 if results diverge.
Step 5: Run, measure with the paper's metric, and log everything
Measure with the same metric the paper used, on the same split, and log the run so it can be repeated: the seed, the data version, the preprocessing choices, the hyperparameters, the hardware class (your own laptop, a lab machine, or a free cloud notebook), and the result. A minimal run log in code looks like this:
import random
random.seed(42)
run = {
"seed": 42,
"split": "train, validation, test as described in the paper",
"metric": "the same metric the paper reports",
"preprocessing": "copied from the paper, gaps noted in the log",
}
print(run)
One run proves very little. Repeat the key run with a second seed and confirm the result is stable before calling it your baseline. If two seeds give wildly different outcomes, that instability is itself a finding to report, not something to hide by picking the better seed.
Step 6: Compare honestly, then diagnose gaps
Lay your results next to the paper's, claim by claim. Three outcomes are possible, and all three are usable:
- Matches. Your implementation behaves as described. Freeze it as the baseline and move on.
- Close, with a plausible explanation. A different dataset version, a smaller compute budget, or a documented preprocessing gap can explain a modest difference. Write the explanation down with evidence, and confirm it with your guide.
- Far off, or a claim that does not behave at all. Work the diagnostic ladder in order: wrong split or data leak, preprocessing mismatch, a misread equation or algorithm step, a missing hyperparameter, a different metric definition, and only then a possible error or unstated assumption in the paper. Change one thing at a time and re-run; changing five things at once teaches you nothing.
Never adjust your method until it matches the paper and then present the adjusted number as a reproduction. That is fitting to the answer, and a reviewer who asks how you got there will expose it in one question.
Step 7: Freeze the baseline before touching it
Copy the working version aside — a separate folder or a tagged commit — with its run log and its comparison table. From this point on, your own feature is developed on a branch or copy, and the baseline stays runnable. Every claim about your feature is then a comparison against this frozen version on the same split with the same metric. That comparison is the strongest evidence your review can ask for, and it is impossible to produce after the fact if the baseline was overwritten.
Worked example: what reproduction looks like for a real paper
Take Marino and colleagues' 2025 paper in IEEE Transactions on Industrial Informatics (DOI 10.1109/TII.2025.3534443), on self-supervised vision-transformer methods for industrial defect detection with few labels. A reproduction here does not mean claiming any particular accuracy figure — this guide deliberately reports none, because a number without the paper's exact data and setup behind it would be misleading. It means rebuilding the pipeline's stages: splitting product images into patches, training the self-supervised stage on unlabelled or lightly labelled images, and scoring new images for defects against what the model learned as normal.
The claim table for such a paper would list each stage separately, so a mismatch can be traced to patch handling, to the self-supervised training, or to the scoring rule. The dataset question is decided early: an industrial defect dataset with the same character — product images, rare defects, few labels — matters more than a large generic dataset that makes the problem look easy. If the original dataset is unavailable, the substitution is documented as a limitation, and the baseline is judged on behaviour (defects scored differently from normal products) rather than on matching a number from different data.
A second example shows the same protocol in a different domain. ECLoRA, published in IEEE Transactions on Neural Networks and Learning Systems in 2025 (DOI 10.1109/TNNLS.2025.3586545), concerns federated fine-tuning of large language models with low-rank adaptation. Reproducing it means implementing the federated loop — clients training locally, updates combined centrally — and checking that the loop trains and communicates as described, on a small model and a small dataset first. No speed or efficiency claim is repeated here, because such claims depend on scale and setup that a student reproduction will not match; the baseline is the working loop, and any efficiency claim of your own must be measured against it.
When the paper's dataset is unavailable
Substitution is normal and acceptable, provided it is honest. A good substitute matches the paper on task type (detection, classification, forecasting), on label scarcity (few labels if the paper is about few labels), and on input character (industrial images, not holiday photos, for a defect-detection paper). A substitute that is larger, cleaner, or easier than the original makes your results look better than the paper's without proving anything, so say so in your report and in your review.
Document four things about any substitute: why the original was unavailable, how the substitute differs, what that difference could change, and what you did to keep the comparison fair (same split discipline, same metric, baseline and feature versions on identical data). A guide would far rather approve a documented substitution than discover an undisclosed one at review time.
From baseline to your own feature
Once the baseline is frozen, the own-feature phase has a discipline of its own:
- Write the feature as one change, not five. If you change the model, the data, and the metric together, no comparison is meaningful.
- Run baseline and feature versions on identical splits with identical metrics and seeds.
- Report both numbers side by side, including cases where the feature does not help. A feature that helps on one split and hurts on another is a real result; hiding the second split is not.
- Keep the baseline runnable until submission. Reviews sometimes ask to see it, and rebuilding it under pressure is where errors creep in.
Your own feature is where the project becomes yours, but its value is measured entirely by the baseline you built first. Teams that skip reproduction often discover at review time that they cannot show what their feature actually changed.
Where reproduction sits in Phase-1 and Phase-2
A frozen baseline with its claim table and comparison is Phase-1 evidence: it shows the paper is understood, implementable, and already running. The own-feature build, its comparison against the baseline, and the full evaluation belong to Phase-2. If your Phase-1 review is approaching and the baseline is not yet running, say so plainly and show the claim table, the data decision, and the smallest runnable version — reviewers respect an honest partial state far more than a polished claim with nothing behind it. Department templates and your guide's instructions override anything in this guide.
Mistakes that cost the most time
- Starting with your own feature and never building the paper's method cleanly.
- Tuning on the test set, then reporting the tuned number as a result.
- Copying code you cannot explain, then failing the first review question about it.
- Changing the dataset, the metric, and the model at once and losing the thread.
- Overwriting the only working version in the rush before a review.
- Reporting a paper's number as your own result without running anything.
- Treating a mismatch as failure instead of diagnosing it — a diagnosed mismatch is review material; an unexplained one is a weakness.
Frequently asked questions
How close do my results need to be to the paper's?
Close enough that the behaviour matches: the same stages work, the same kinds of inputs succeed and fail, and any gap has a documented explanation. Agree the bar with your guide before you start, because it depends on the paper, the data, and your compute. Do not invent a tolerance after seeing your numbers.
What if the paper omits a hyperparameter or a preprocessing step?
Note it as a gap, choose the most standard option, log the choice, and test alternatives only if results diverge. A short sensitivity note — "changing this setting moved the result in this direction" — is stronger review evidence than silently picking the value that looks best.
Can I use the authors' code?
If it is legally available and your guide agrees, yes, but read it first and be able to explain it. Code you run without understanding fails at review and teaches you nothing about the method. If no code exists, that is normal for many papers, and a clean re-implementation is the expected work.
What if I cannot reproduce the paper at all?
That is a legitimate outcome if you can show your working: the claim table, the diagnostic ladder, and what you ruled out. Take it to your guide early, not at review time. The options are usually a narrower reproduction target (core claims only), a documented dataset substitution, or — with your guide's agreement — a different paper. What you must not do is fabricate matching numbers.
Does reproduction count as my own work?
Yes. A clean re-implementation with a comparison, a run log, and an analysis of gaps is substantial work, and it is the foundation your own feature stands on. What does not count is copying results or code without understanding or attribution. Cite the paper properly in every document, and keep base-paper work and your own contribution clearly separated.
Who gives the final approval for my approach?
Your guide and your department. No outside service, listing, or guide article can guarantee approval or a particular result. This guide gives you a defensible method; the decision stays with them.
Limitations
Papers vary enormously in how completely they specify their method, and some methods genuinely need compute or data that a student team does not have — that is a reason to narrow the reproduction target with your guide, not to fake it. Free cloud notebooks, lab machines, and smaller models change what is feasible, and this guide cannot know your setup. Department templates, review formats, and your guide's instructions override anything written here. Where a paper is paywalled, use your library access or the authors' legally available preprint where one exists, and never circulate pirated copies.
Get a quotation for your base-paper build
If your base paper is approved and you want help implementing it, message Projectech on WhatsApp with your paper's DOI, the dataset you can access, and the compute you have available, and ask for a quotation covering the scope (baseline reproduction, then your own-feature build), the price, and the delivery timeline across Phase-1 and Phase-2. The price is set only after the topic, base paper, and compute scope are locked, and final approval of the project always rests with your guide and college.