Literature Reviews for AI: Find, Compare, Summarize Sources

Section 1.1: Literature reviews as “maps” of what’s known

A literature review is best understood as a map. A map is not every street photographed; it is a selective representation designed to help someone navigate. Similarly, a literature review selects and organizes sources so the reader can understand the landscape of ideas and evidence around a research question. Your job is to make the terrain legible: major approaches, recurring assumptions, typical datasets, evaluation norms, and known trade-offs.

In plain language, the goal is: “Explain what the field currently believes, why it believes it, and what remains uncertain.” That goal is different from summarizing. A summary retells a single source. An annotated bibliography lists multiple sources with short notes. A literature review connects sources: it compares, groups, and evaluates them to support a storyline (for example, “accuracy improved as models scaled, but robustness and data contamination became central concerns”).

Common mistake: treating the review as neutral reporting. Reviews involve judgment—careful, transparent judgment. You decide which results matter, whether evidence is strong, and how methods relate. Another mistake is writing chronologically (“paper A, then paper B…”) with no synthesis. A map needs landmarks and routes, not just dates.

• Practical outcome: By the end of your review, a reader should be able to answer: What are the main options? What evidence supports each? Which option fits my constraints?
• Writer’s test: If you remove one paper summary and nothing changes, you were not synthesizing.

Section 1.2: Common review types (narrative vs structured) for beginners

Beginners usually start with either a narrative review or a structured review. A narrative review tells a guided story: you define a question, choose representative sources, and explain how ideas evolved and where debates sit now. Narrative reviews are flexible and readable, which makes them great for early-stage projects, class assignments, or when a field is moving fast (common in AI).

A structured review (sometimes “systematic-style,” though true systematic reviews have strict protocols) uses explicit rules: search strings, databases, inclusion/exclusion criteria, and a consistent extraction template. You may not need a full systematic protocol, but borrowing the discipline is useful: it reduces cherry-picking and makes your conclusions easier to trust.

How to choose: if your goal is orientation and framing, go narrative but keep your selection rationale. If your goal is to compare methods fairly (e.g., “Which retrieval-augmented generation setup improves factuality under the same evaluation?”), you need more structure.

A practical hybrid approach works well in AI: (1) use a structured search and a consistent note template, (2) write the final chapter as a narrative with clearly labeled comparison categories (datasets, metrics, compute, limitations). This avoids the common mistake of “pretty prose built on messy evidence.”

• Practical outcome: Pick a review type early, because it determines your search plan and note-taking format.
• Beginner rule: Even narrative reviews should state where you looked and why these sources were chosen.

Section 1.3: The minimum vocabulary: claim, evidence, method, results

To compare AI papers without getting overwhelmed, you need a small set of labels that apply to almost every study. Use four: claim, evidence, method, and results. This vocabulary is the foundation for trustworthy reading and for writing a review that does more than paraphrase.

Claim: What the authors assert (e.g., “Our model is more robust,” “This dataset measures reasoning,” “Scaling improves performance”). Claims can be broad; your job is to make them specific and checkable.

Method: What they did—model architecture or algorithm, training procedure, data sources, baselines, and evaluation setup. In AI, small method details often drive results (prompt format, filtering, compute budget, hyperparameters). Record the essential choices, not every line of implementation.

Results: The measured outcomes: metrics, benchmark scores, ablations, error analysis, cost/latency, and qualitative findings. Always note the metric and dataset; “better” without context is meaningless.

Evidence: Why the results should be believed: experimental design, comparisons, statistical tests, robustness checks, reproducibility artifacts, and whether alternative explanations were considered. This is where engineering judgment matters. For example, if a paper claims a new method generalizes, but evaluates on near-duplicate data or a single benchmark, the evidence is weaker than the claim.

Common mistake: copying results tables without recording the conditions. Another: accepting author conclusions without separating them into these four parts. When you keep the parts distinct, your later synthesis becomes straightforward: you can compare claims to evidence across papers and identify where disagreement comes from.

Section 1.4: How AI papers are organized (a gentle tour)

AI papers can look intimidating because they mix math, systems details, and empirical evaluation. You do not need to understand every equation to write a useful literature review. You need to understand the paper’s argumentative skeleton and where key information lives.

Most AI papers follow a predictable structure: Abstract (the sales pitch), Introduction (problem framing and contributions), Related Work (how they position themselves), Method (what they built or proposed), Experiments/Evaluation (how they tested it), Results (what happened), Discussion/Limitations, and Conclusion. Appendices often contain the details you need for trust: hyperparameters, additional baselines, dataset processing, prompts, and ablations.

A beginner-friendly reading workflow is “two passes plus extraction.” First pass: read abstract, intro, figures, and conclusion to capture claim and context. Second pass: skim method and evaluation to understand what was compared and under what conditions. Then extract notes using a consistent template (you’ll set that up in Section 1.6).

Engineering judgment shows up in the evaluation section. Ask: Are baselines strong and fairly tuned? Is the dataset appropriate and uncontaminated? Do metrics match the real objective (accuracy vs calibration, helpfulness vs factuality, latency vs cost)? Are there failure cases? These questions help you judge trustworthiness without requiring you to reproduce the work.

Common mistake: spending hours decoding derivations while missing that the evaluation is narrow or the baseline is weak. For a literature review, prioritize comparability and evidence quality over full technical mastery.

Section 1.5: Picking scope: time range, domain, and depth

A good literature review starts with a manageable topic and a clear scope. “Transformers” is not a topic; it is an entire ecosystem. Instead, turn vague interest into a question you can actually answer, then translate that into a search plan.

Scope has three dials: time range, domain, and depth. Time range might be “2019–2024” (recent methods) or “foundational to present” (if you need historical grounding). Domain might be “medical text summarization,” “code generation,” or “edge deployment.” Depth is how far you go into each paper: surface-level comparison of outcomes, or deeper analysis of design choices and limitations.

A practical way to shape a research question is to include: (1) the task, (2) the setting/constraints, and (3) what you’re comparing. Example pattern: “In task, under constraint, how do approach A and approach B compare on metric(s)?” This naturally leads to keywords and filters later.

Common scoping mistakes: choosing a topic so broad you can’t finish, or so narrow you can’t find enough credible sources. If you find hundreds of papers in a quick search, narrow by domain, evaluation type, or a specific family of methods. If you find fewer than ~8–10 relevant sources, widen the time range or include surveys and benchmark papers.

• Practical outcome: End this step with a one-sentence research question and 3–5 inclusion rules (e.g., “must evaluate on dataset X,” “must report metric Y,” “peer-reviewed or widely used preprint with released code”).

Section 1.6: Your starter toolkit: tracker, notes, and versioning

Literature reviews fail more from poor organization than from poor reading. Set up a simple workspace before you collect many papers. You need three things: a folder structure, a source tracker, and a note template that makes comparison easy. Add lightweight versioning so your work doesn’t become a fragile pile of edits.

Folders: Create one top-level folder for the project, with subfolders such as /papers_pdf, /notes, /figures, and /exports. Rename PDFs consistently: “Year_FirstAuthor_Venue_ShortTitle.pdf” so you can find them without opening them.

Tracker (spreadsheet or table): Make columns for citation, link, venue, year, task, dataset(s), metric(s), method family, key claim, strength of evidence, limitations, and relevance score. Include a status field (to read / skimmed / extracted / cited). This tracker becomes your “single source of truth” when you start writing.

Note template: For each paper, capture: (1) Claim (one sentence), (2) Method (bullet points), (3) Evidence and evaluation setup (datasets, baselines, metrics), (4) Results (numbers with conditions), (5) Limitations/failure modes, (6) How it relates to other papers (agreement, contradiction, dependency). This last field is what turns notes into synthesis.

Versioning: Use dated filenames for drafts (e.g., “litreview_draft_2026-03-27.docx”) or a git repository if you are comfortable. Keep a short changelog in your main doc (“What changed and why”) so you can recover decisions and avoid rewriting history.

Common mistake: taking notes in inconsistent formats across papers. If your template is stable, comparison becomes mechanical: you can line up claims, methods, and results and write a coherent storyline instead of re-reading everything.

Section 2.1: Research questions that guide the search

A good search starts with a research question, not a topic. “AI in healthcare” is a topic; it is too broad to guide keyword choices, filters, or inclusion decisions. A research question creates a target and prevents you from collecting papers that are merely adjacent. For early-stage literature reviews, your question can be exploratory, but it still needs boundaries: who/what system, what task, what context, and what outcome.

Use a simple template that works well for AI: Task + Method/Model + Domain + Evaluation/Constraint. Example: “How do retrieval-augmented generation (RAG) methods affect factual accuracy in clinical question answering compared with fine-tuned LLMs from 2020–2024?” That one sentence gives you obvious search hooks (RAG, factual accuracy, clinical QA) and obvious exclusions (general chatbots, non-clinical domains, pre-2020 unless foundational).

From the question, write a one-paragraph search plan: what types of papers you need (surveys, benchmark papers, method papers, clinical validation studies), what date range matters, and what counts as “in scope.” This is engineering judgment: if you are studying fast-moving LLM methods, your plan might prioritize the last 3–5 years plus a few classic precursors. If you are studying a mature area like SVMs for text classification, older work may be required.

Common mistake: changing the question every time you see a new keyword. Instead, treat the question as stable for the first pass, build an initial reading list of 8–12 sources, then refine the question once you’ve learned the field’s vocabulary and typical baselines.

Section 2.2: Keyword building: synonyms, acronyms, and related terms

AI papers are discoverable only if you speak the language used by authors. Your job is to translate your research question into a keyword set that includes synonyms, acronyms, and closely related terms. Start by splitting the question into 3–5 concept buckets. For the RAG clinical QA example, buckets might be: (1) retrieval-augmented generation, (2) factuality/hallucination, (3) clinical/biomedical QA, (4) LLMs/fine-tuning.

For each bucket, list: (a) primary terms, (b) synonyms, (c) acronyms/variants, and (d) exclusions. This matters because authors may say “grounded generation” instead of RAG, or “faithfulness” instead of factuality. Acronyms are especially risky: “QA” might mean “question answering” or “quality assurance,” depending on domain. Capture both long-form and acronym forms so you can search safely.

• Primary: “retrieval augmented generation”, RAG
• Related: “grounded generation”, “open-book QA”, “knowledge-grounded”, “tool use” (sometimes)
• Outcome terms: hallucination, factuality, faithfulness, attribution, citation accuracy
• Domain terms: clinical, medical, biomedical, PubMed, EHR, radiology (optional)
• Exclusions: “image generation”, “reinforcement learning” (if irrelevant), “quality assurance” (to avoid QA ambiguity)

Then turn the list into search strings. A practical pattern is: (Bucket A terms) AND (Bucket B terms) AND (Bucket C terms), keeping each bucket as an OR-list. You can also add exclusions with a minus sign in many tools (e.g., -“quality assurance”). Expect to iterate: the first search teaches you new vocabulary; add it to your list instead of starting from scratch.

Section 2.3: Where to search: Scholar, arXiv, libraries, and publisher sites

Run your first search in Google Scholar because it is fast, broad, and good at citation tracing. Use it to map the terrain: identify recurring venues (NeurIPS, ICML, ACL, EMNLP, AAAI, Nature/Science family, JAMIA for clinical informatics), recurring authors/labs, and canonical terms. Scholar is also practical for finding PDFs, but it is not curated; you must apply judgment later.

Next, run one search in a library database (through your university or public library). Options include Scopus, Web of Science, IEEE Xplore, ACM Digital Library, PubMed, or ProQuest. The value of a database is better metadata, consistent filters, and reliable access to publisher versions. If your topic touches medicine or biology, PubMed is often non-negotiable. If your topic is core CS/AI, IEEE and ACM are common starting points alongside indexing databases like Scopus.

Add arXiv as a targeted source for cutting-edge AI. It is excellent for early results, but preprints may not be peer reviewed and can change between versions. Use arXiv to avoid being late to a rapidly moving area, then check whether the work later appears in a peer-reviewed venue (often noted on the paper or on the author’s page).

Finally, use publisher sites (Springer, Elsevier, Nature, PLOS) when you already know the venue or need the “version of record.” A practical workflow is: Scholar for discovery, database for verification and filtering, arXiv for recency, publisher sites for authoritative copies. Don’t rely on only one platform; each has blind spots.

Section 2.4: Smart filtering: date ranges, citations, and relevance checks

Filtering is where you stop guessing and start controlling the result set. Begin with a date range aligned to your question. For many LLM-era topics, a “last 5 years” filter is sensible, but don’t let the filter hide foundational papers. A good compromise is: recent range for the main search, plus one separate search for “survey” or “tutorial” without strict year limits to find older anchors.

Use type and venue filters when available: journal articles and top conference proceedings often carry more weight than unreviewed material, but high-quality workshops can be valuable for emerging ideas. Be explicit about what you are collecting. If you need an initial reading list of 8–12 sources, aim for a mix: 2–3 surveys or systematic reviews, 4–6 key method papers, 1–2 benchmark/dataset papers, and 1–2 domain-specific evaluation papers.

Citation counts are a useful but imperfect signal. High citations can indicate influence, but they favor older papers and popular topics. Apply a simple relevance check on every candidate source before saving it: read the title, skim the abstract, and scan figures/tables for the task definition and evaluation metrics. Ask: Does it actually answer part of my question, or is it using my keywords in a different meaning?

Common mistake: filtering only by “most cited” and ending up with a historical tour that misses current methods. Another mistake: filtering only by “since 2024” and collecting noisy preprints with unclear baselines. Your job is balance—enough recency to be current, enough stability to be credible.

Section 2.5: Snowballing: using references and “cited by” safely

Once you find one strong paper, you can expand your set efficiently through snowballing. There are two directions: backward snowballing (checking the references) and forward snowballing (using “cited by” to find newer work that builds on it). This is often the fastest way to move from “some papers” to “the important papers” without random searching.

Use snowballing with guardrails. Not every referenced paper is relevant; authors cite for many reasons (background, criticism, tangential framing). When scanning references, look for repeated appearances: the same dataset paper, the same metric definition, the same baseline model. These repeated citations often reveal the field’s shared foundations.

For “cited by,” prioritize citations that match your buckets (task, domain, outcome). A practical trick: open a citing paper and search within it (Ctrl/Cmd+F) for your core terms (e.g., “hallucination,” “attribution,” “clinical”). If the term appears only in the introduction, it might be superficial. If it appears in methods and experiments, it is more likely relevant.

Safety checks matter because snowballing can lead you into citation bubbles. Balance it with a fresh keyword search to ensure you’re not only seeing one research community’s perspective. Also note that preprints may cite aggressively; verify whether the citing work has a final published version and whether the results hold up in later papers.

Section 2.6: Source capture: links, PDFs, and a clean naming system

Finding papers is wasted effort if you lose them or can’t reconstruct why you saved them. Build a capture system on day one. At minimum, store: (1) the canonical citation (authors, year, title, venue), (2) a stable link (DOI or publisher page when possible), (3) the PDF (when legally available), and (4) your quick notes (why it’s relevant, what it contributes).

Use a reference manager (Zotero, Mendeley, EndNote) or a lightweight spreadsheet if you must, but be consistent. Create folders/collections by chapter theme or by concept bucket (e.g., “RAG methods,” “Factuality metrics,” “Clinical QA evaluations”). Your practical target here is an initial reading list of 8–12 sources: enough to see patterns without becoming unmanageable.

Adopt a clean file naming convention so PDFs remain usable outside the reference manager. One robust pattern is: Year_FirstAuthor_Venue_ShortTitle.pdf (e.g., 2023_Lewis_arXiv_RAGSurvey.pdf). Avoid spaces and keep it readable. If you download multiple versions, add a suffix like v2 or cameraReady. Put all PDFs in one “papers” folder with subfolders by theme, and never rely on your browser downloads folder.

Common mistake: saving only a PDF and forgetting the source page; later you cannot retrieve the DOI, correct citation, or updated version. Another mistake: capturing too many sources without triage. Your capture system should enforce discipline: if a paper fails your relevance check, don’t save it “just in case.” You can always re-find it, but your future self can’t easily un-clutter your library.

In an AI literature review, “quality” is less about fame and more about whether you can understand the claim, verify the support, and trace how the result was produced. A simple credibility checklist can be built from three pillars: clarity, evidence, and transparency.

Clarity means the paper answers: What is the problem? What is new? What is being compared? If you can’t restate the main claim in one sentence (“This model improves X on dataset Y measured by metric Z”), that’s a warning sign. Many weak sources hide behind vague improvements like “more robust” or “significantly better” without specifying where, compared to what, and by how much.

Evidence means results are measurable and connected to the claim. Look for tables/figures with numbers, not just illustrative examples. Strong sources show comparisons to baselines, report variability (error bars, multiple seeds, confidence intervals), and avoid cherry-picked demos. Weak evidence often shows one dramatic example, a single dataset, or a single metric that flatters the method.

Transparency means you can see enough detail to evaluate the work: data description, model configuration, training setup, and limitations. Missing methods is a top red flag in AI writing—if you can’t tell how the results were obtained, the results are not actionable for your review.

• Hype language red flags: “breakthrough,” “human-level,” “game-changing,” “solves,” without scoped definitions.
• Missing-method red flags: no dataset details, no baseline list, no metric definition, no experimental setup.
• Weak-evidence red flags: only qualitative results, no comparisons, or comparisons to outdated/irrelevant baselines.

Practical outcome: for each candidate source, write a 2–3 bullet “credibility snapshot” before you decide to keep reading. This prevents you from spending hours on attractive-but-empty sources.

AI has a dual publishing culture: peer-reviewed venues (journals, conferences) and preprints (often arXiv). Both matter, and neither is a guarantee of truth. Peer review is a filter, not a certification; preprints are early access, not automatic junk.

Peer-reviewed sources are typically more stable: they have passed at least one round of reviewer scrutiny, and they are usually easier to cite in academic contexts. However, peer review varies in quality, reviewers can miss issues, and flashy results can slip through. Treat peer review as a positive signal that the authors have met minimum community expectations, then still verify methods and evidence yourself.

Preprints are essential when your topic is fast-moving (e.g., new model architectures, safety techniques, benchmarks). Preprints often contain the first public description of a method, and sometimes they are the only available source. The trade-off is uncertainty: the work may change, errors may be corrected later, or claims may not survive replication.

Practical rule: include preprints when they are central to your question, but label them clearly and apply a stricter checklist. Look for signs of maturity: an updated version history, released code, released model weights, additional experiments, or follow-up papers that cite and critique the preprint.

• How to cite responsibly: note “preprint” in your notes, and avoid presenting tentative claims as settled facts.
• How to compare fairly: don’t treat “preprint vs peer-reviewed” as the main argument; compare methods and evidence directly.
• How to reduce risk: prefer preprints that have independent discussion (blog replications, issues filed on GitHub, later peer-reviewed versions).

Practical outcome: your core set can mix both types, but you should be able to explain why each preprint is included and what uncertainty remains.

When you’re new to AI research, venue and author signals help you prioritize reading. They are heuristics, not proofs. Use them to decide where to spend time, then let methods and evidence make the final call.

Venue signals: top conferences and journals in machine learning (and relevant subfields) tend to enforce stronger norms: clear baselines, standard benchmarks, and detailed experiment sections. Workshop papers can be high-quality but more exploratory. Company blog posts and marketing pages can be informative but are often optimized for persuasion, not transparency.

Author signals: an author with a track record in the area is a positive indicator that they know the literature and common evaluation traps. But reputations can bias you: famous groups can still publish weak comparisons, and newcomers can publish excellent work. Also note whether authors are affiliated with organizations that might benefit directly from a particular conclusion (e.g., a vendor evaluating their own product).

Practical checks you can do quickly:

• Find the paper trail: does the work cite the key baselines you already saw in earlier reading?
• Check the version: is this an “extended version,” a “technical report,” or a later revision that fixed errors?
• Look for community uptake: are other credible papers building on it, reproducing it, or criticizing it?

Common mistake: over-weighting citations. High citation counts often reflect topic popularity or being “first,” not correctness. For a literature review, your goal is to understand which sources provide the most reliable evidence for your specific question, not which sources are most famous.

Practical outcome: create a short “source identity” line in your notes (venue/type, year, author affiliation) to contextualize credibility without letting it dominate your judgment.

Many credibility decisions become easy once you can read an AI methods section at a basic level. You do not need to understand every equation; you need to verify that the experiment is interpretable and comparable. A good mental model is: dataset (what you tested on) + metric (how you measured) + baseline (what you compared to).

Datasets: Strong papers describe where data comes from, how it’s split (train/validation/test), and what preprocessing was done. Watch for leakage: anything that allows information from test data to influence training. Also watch for overly narrow datasets that don’t match the claim scope. If a paper claims “real-world robustness” but evaluates on a tiny curated benchmark, the evidence is thin.

Metrics: A metric must match the task. Accuracy might be fine for balanced classification, but misleading for rare events; BLEU may not reflect factuality in text generation; average performance can hide failures on subgroups. Credible sources define the metric and justify it, especially if they introduce a custom metric.

Baselines: The baseline set should be relevant and reasonably strong. Red flags include comparing only to old methods, tuning the new method heavily but not the baselines, or changing evaluation settings in ways that disadvantage competitors. A good sign is an “apples-to-apples” comparison: same data, same compute budget (or clearly reported compute), same evaluation protocol.

• Minimum methods checklist: dataset described, metric defined, baselines listed, experimental setup stated.
• Extra credibility boosters: ablation studies (what matters), error analysis (where it fails), multiple seeds/variance.

Practical outcome: when you write your one-paragraph quality note later, you’ll be able to say precisely what was tested and why you believe (or doubt) the result.

Credibility is not only technical; it’s also about incentives. AI papers and reports exist in an ecosystem of grants, product launches, hiring, and media attention. Bias doesn’t automatically invalidate a source, but it changes how carefully you should read it and how cautiously you should generalize its claims.

Funding and conflicts: Check acknowledgments and disclosures. Industry-funded work can be excellent and well-run, but it may prioritize benchmarks aligned with product goals or omit uncomfortable comparisons. Academic work can be biased too (toward novelty, publishability, or a preferred theory). Your job is to notice where incentives might shape choices.

Selection bias and reporting bias: Many results look strong because only “successful” experiments are reported. Watch for language like “we tried many settings” without specifying how many or how chosen. If negative results or failure cases are absent, that’s a transparency gap.

Limitations sections: A credible paper often states limitations clearly: data constraints, compute assumptions, generalization risks, ethical concerns, and known failure modes. A missing limitations discussion is not fatal, but it increases uncertainty—especially for high-stakes topics like healthcare, education, hiring, and safety.

• Practical bias check: Who benefits if this conclusion is believed?
• Scope check: Do the claims go beyond the tested setting (dataset, language, demographic, environment)?
• Reproducibility check: Is code/data available, or at least enough detail to replicate?

Practical outcome: you’ll be able to write balanced synthesis later (“strong results on benchmark X, but limited evidence for Y due to Z”), which is a hallmark of a credible literature review.

To finalize your core set of 6–10 sources, you need explicit inclusion/exclusion rules. This is what separates a disciplined literature review from “papers I happened to read.” Rules also prevent you from unconsciously selecting only sources that agree with your initial belief.

Start with your research question and define inclusion criteria that guarantee relevance and evaluability. Then define exclusion criteria that remove sources you can’t trust or can’t compare. Keep the rules simple enough to apply consistently.

• Inclusion examples: published 2019–2026; evaluates on at least one benchmark relevant to the task; reports quantitative metrics; compares to at least two strong baselines; describes dataset and evaluation protocol.
• Exclusion examples: purely marketing content; no methods section; no measurable results; only qualitative anecdotes; unclear data provenance; claims far beyond evidence scope.

Next, write a one-paragraph quality note for each remaining source. Use a consistent template so you can compare papers later. A practical paragraph structure is: (1) claim + context, (2) evidence summary (dataset/metric/baselines), (3) credibility notes (peer-reviewed vs preprint, transparency, red flags), (4) your verdict for review use (keep/core vs background vs drop).

Common mistake: keeping too many “maybe” sources. Your core set should be the papers you can actively compare and synthesize. You can keep extra items in a “parking lot,” but the 6–10 you choose now will drive the storyline and structure of your review in the next chapters.

Practical outcome: you end this chapter with a short list you trust, a written justification for each item, and clear rules you can explain in one sentence when someone asks, “Why these sources?”

Section 4.1: The extraction template: problem, approach, data, results

To compare papers, you must extract the same kinds of facts from each one. A good beginner-friendly template is: Problem → Approach → Data → Results. This prevents “over-reading” (getting lost in math or implementation details) and keeps you focused on what makes papers comparable.

Problem: Write a 1–2 sentence statement of the task and setting. Include assumptions and scope. Example: “Improve long-context retrieval for question answering with limited labeled data.” Avoid copying the paper’s hype; restate the problem in plain language.

Approach: Capture the core idea, not every component. Use one sentence for the main mechanism (“contrastive objective with hard negatives,” “mixture-of-experts routing,” “self-training with pseudo-labels”), then a short bullet list for key design choices (loss, architecture, training scheme). If the method depends on a critical trick (e.g., temperature scaling, data filtering), record it here.

Data: Record dataset names, sizes (rough order of magnitude is fine), and whether they are public, proprietary, or synthetic. Include splits, domain, and labeling source if relevant. Data differences often explain performance differences more than model differences—so treat this field as first-class.

Results: Record the main metrics and the comparison baseline(s). Always write “better than what?” Include a note on evaluation setup: in-domain vs out-of-domain, zero-shot vs fine-tuned, single model vs ensemble. If the paper reports many tables, pick the one that best matches the paper’s claim and record just enough to compare across papers.

• Template tip: Add two extra lines: “Claim in one sentence” and “Key limitation stated by authors.” These are high-signal and quick to extract.
• Traceability rule: For every non-obvious number or claim, store a page/figure/table reference (e.g., “Table 2,” “Fig. 3,” “p. 5”). This makes later summaries accurate.

By forcing identical fields, you create notes that are easy to merge into a comparison table. You also reduce the temptation to keep reading until you “feel” you understand—because the template tells you what “done” looks like.

Section 4.2: Reading strategy: abstract-first, then selective deepening

A repeatable comparison workflow needs a repeatable reading workflow. Use abstract-first, then selective deepening. The aim is to get accurate extraction without spending an hour in the weeds for every paper.

Pass 1 (5–8 minutes): Read title, abstract, and the contributions list (often in the introduction). Skim figures and the main results table. Then fill in your template with placeholders and question marks. At this stage you are not proving the method to yourself; you are identifying what the paper claims and where the evidence likely lives.

Pass 2 (10–20 minutes): Deepen only where it affects comparison. Typical “must-read” zones are: (1) the dataset/evaluation section, (2) the baseline description, and (3) ablations that justify the main claim. If the paper’s novelty is a new training objective, read that part carefully enough to state the objective in words and note what differs from prior work.

Stop conditions: Stop reading when your template fields are complete and you can answer: “What did they do differently?” and “On what evidence do they claim it works?” If you cannot answer, deepening is justified; if you can, extra reading often produces diminishing returns.

• Common mistake: reading methods sections line-by-line before you know whether the evaluation is even comparable to other papers in your set.
• Engineering judgment: allocate time based on role. Anchor papers (highly cited, standard baselines) may deserve deeper reading; fringe or redundant papers may only need Pass 1 + a quick check of evaluation.

This strategy keeps your attention on comparable facts. It also makes it easier to write short summaries later, because you have already separated “core claim + evidence” from “implementation details.”

Section 4.3: Comparison tables: features, strengths, weaknesses, tradeoffs

Once you have 5–15 extracted templates, convert them into a comparison table. A table is not just a storage format; it is a thinking tool. It makes patterns visible that are hard to notice when notes are trapped in separate documents.

Start with columns that directly support your research question. For AI papers, a strong default set is:

• Task / problem setting (one phrase)
• Approach type (e.g., retrieval, finetuning, distillation, prompting, architecture change)
• Data (public/private, size, domain)
• Evaluation (datasets + metric + setup)
• Main result (number + baseline)
• Strengths (2–3 bullets)
• Weaknesses / limitations (2–3 bullets)
• Tradeoffs (what you gain vs what you pay: compute, latency, labeling, complexity, interpretability)

How to write strengths/weaknesses without opinion: tie each to evidence. “Strength: strong out-of-domain accuracy (Table 3).” “Weakness: requires proprietary data; unclear reproducibility (Data section).” Avoid vague labels like “robust” unless the paper actually evaluates robustness.

Tradeoffs are where synthesis begins: two papers can both improve accuracy, but one does it with 10× compute or narrow evaluation. Capturing tradeoffs prevents your review from becoming a scoreboard.

Practical outcome: after filling the table, sort rows by approach type or evaluation setting. You will often discover that papers aren’t directly comparable because they use different datasets or report different metrics. That discovery is valuable: it tells you what the field measures—and what it avoids measuring.

Section 4.4: Theming: clustering sources into categories that make sense

After tabulating, you need a way to explain the literature to a beginner. That usually means grouping sources into themes—clusters that answer “What kinds of solutions exist?” rather than “What happened in Paper A?”

Build themes from your table, not from memory. Look for columns where values repeat: similar approach types, similar data regimes, similar evaluation setups, or similar failure modes. Common AI review themes include:

• Method families: e.g., retrieval-augmented, instruction-tuned, distillation-based, architecture-based.
• Data regimes: low-label, synthetic-data heavy, proprietary-data dependent.
• Deployment constraints: edge/latency-limited vs offline/batch; privacy constraints; interpretability requirements.
• Evaluation philosophies: leaderboard metrics vs human evaluation vs stress tests.

Rules for good themes: (1) Themes should be mutually distinguishable by a reader in one sentence. (2) Each theme should have at least two papers, otherwise it’s a “special case,” not a theme. (3) Themes should map to a meaningful decision: “If you care about X, you’ll likely use approaches in Theme Y.”

Common mistake: making themes that are just paper titles (“Approach A,” “Approach B”) instead of categories. Another mistake is theming by publication venue or year only; those can be useful secondary groupings but rarely explain technical differences.

When theming is done well, your literature review stops being a list and becomes a guided tour: you can say what the main solution paths are, why they exist, and what tradeoffs they represent.

Section 4.5: Synthesis vs summary: turning “paper notes” into insights

A summary describes papers one by one. A synthesis explains what the set of papers collectively implies. Your comparison table and themes are the bridge from notes to insight.

To synthesize, write statements that require multiple sources to be true. Examples of synthesis moves:

• Consensus: “Across Theme A and Theme B, performance gains mostly come from better data curation rather than architectural changes.”
• Conditional insight: “Methods in Theme A win on in-domain benchmarks, but Theme B generalizes better under distribution shift.”
• Gap: “Most papers report accuracy but few report latency/cost, making deployment tradeoffs hard to assess.”
• Reconciliation: “Conflicting results appear when evaluation differs (zero-shot vs fine-tuned), not necessarily because methods disagree.”

Draft a one-page synthesis outline: Use your themes as section headers. Under each theme, add (1) what the theme is, (2) 2–4 representative papers with one-line contributions, and (3) the tradeoff story. End with a “What remains uncertain” paragraph that points to missing evaluations or disputed claims.

Traceable short summaries: Even in synthesis, you still need accurate mini-summaries. Keep them short (2–3 sentences) and grounded in your notes with references like “Table 2” or “Sec. 4.1.” This is how you avoid accidental exaggeration when you later write the full literature review.

The practical outcome is a review that reads like analysis rather than a reading diary: the reader learns how the field is structured and how to choose between approaches.

Section 4.6: Tracking uncertainty: what’s unclear, missing, or disputed

Real literature is messy: results conflict, methods are underspecified, and evaluations are not apples-to-apples. Good reviewers don’t hide this—they track it. Add an Uncertainty field to your template and table, and treat it as seriously as “Results.”

Use three practical categories:

• Unclear: you couldn’t determine something from the paper (e.g., training compute, filtering rules, exact baseline setup). Record what you tried to locate (“not specified beyond ‘large-scale data’”).
• Missing: the paper did not evaluate something important for your question (e.g., no out-of-domain test, no ablations, no cost/latency, no statistical significance).
• Disputed: other papers report conflicting outcomes, or a replication suggests different results. Note the conflict precisely and point to the differing conditions (data, metric, model size, prompt format).

Engineering judgment: not all uncertainty is fatal. If your goal is to understand method families, missing hyperparameters may be tolerable. If your goal is to recommend an approach for deployment, missing latency or compute costs is a major blocker.

Common mistake: turning uncertainty into vague skepticism (“seems questionable”). Instead, write falsifiable notes: “No details on negative sampling; hard to replicate,” or “Baseline uses different tokenizer; may inflate gains.” These notes become powerful sentences in your literature review’s limitations section.

Tracking uncertainty also protects you from overconfident synthesis. When you later write your storyline, you’ll know which claims are solid, which are tentative, and which are genuinely open research questions—exactly the distinction a strong literature review should communicate.

Section 5.1: Review outlines that work: 4 common patterns

Start by choosing a structure that fits your research question and the shape of the evidence. Most literature reviews in AI can be organized using one of four patterns. Picking one early prevents a common failure mode: collecting sources forever because you never decided what “coverage” means.

1) Timeline (chronological): Use when the field clearly evolves through phases (e.g., “rule-based → statistical → deep learning → foundation models”). Your paragraphs emphasize what changed and why: new compute, new datasets, new objectives, or new evaluation norms. Risk: it can become a history lesson with weak synthesis if you don’t connect each phase to the same core problem.

2) Theme (conceptual buckets): Use when multiple approaches coexist and the key is comparing ideas (e.g., retrieval-augmented generation, fine-tuning, prompting; or privacy techniques like DP-SGD, federated learning, synthetic data). This is often the best default for student reviews because it keeps comparisons tight. Risk: themes can overlap; fix this by defining each bucket with one sentence and a boundary.

3) Method (pipeline or technical choices): Use when the research question is about how something is built or measured (data collection, representation learning, training objective, inference-time strategy, evaluation). This is strong for AI because many “results” are really “pipeline decisions.” Risk: it can read like a tutorial unless you keep returning to your research question and criteria.

4) Problem-based (use-case constraints): Use when requirements drive design (latency, safety, interpretability, domain shift, multilinguality). This structure helps you discuss tradeoffs honestly because each subsection is framed by constraints. Risk: you might repeat the same papers in multiple constraint sections; handle this by deciding where each paper is “mainly” discussed and cross-referencing briefly elsewhere.

Practical workflow: write your outline as 6–10 headings, and under each heading list (a) the 3–6 most central sources, (b) one sentence on the claim you want that heading to make, and (c) the evaluation lens (dataset, metric, setting) you will use to compare. That outline becomes the backbone of your introduction and conclusion later.

Section 5.2: Building your “storyline”: what the field agrees on vs debates

A literature review needs a storyline: a logical sequence that explains what is settled, what is uncertain, and what motivates your work. A simple way to build this is to separate consensus claims from debate claims. Consensus claims are stable patterns across multiple sources (e.g., “larger models often improve performance but increase cost and sometimes worsen calibration”). Debate claims are contested or conditional (e.g., “RLHF improves helpfulness without harming truthfulness” depends heavily on evaluation design).

To draft your storyline, create two lists from your notes:

• Agreement list: 3–5 statements that at least three credible sources support, even if they phrase it differently.
• Debate list: 3–5 tensions where sources diverge (different conclusions, different metrics, different assumptions, or different data).

Then order the review so the reader earns the debates. Typically: define the task and evaluation norms → summarize the strongest shared findings → introduce the debates as “remaining questions.” This prevents the review from sounding chaotic or opinionated.

Engineering judgment matters here: not all disagreements are equally meaningful. Many are artifacts of setup. When you see conflict, diagnose the cause: (1) different datasets/domains, (2) different evaluation metrics, (3) different baselines, (4) different compute budgets, or (5) different definitions of the problem. Naming the cause is synthesis; merely stating “Paper A says X, Paper B says Y” is not.

Common mistake: making your project the hero too early (“Existing work fails because…”). Instead, earn your gap by showing the field’s progress and then identifying a specific boundary condition: “Most studies evaluate on English benchmarks; fewer examine domain-specific jargon, where retrieval quality and citation accuracy become limiting factors.” That kind of gap is scoped, testable, and respectful to prior work.

Section 5.3: Paragraph recipe: claim → evidence → comparison → takeaway

Paragraphs are where structure becomes readable. A strong literature review paragraph does more than report; it makes a small argument and ties sources together. Use this repeatable recipe: claim → evidence → comparison → takeaway. It keeps your voice in control while still grounding every statement in citations.

1) Claim (topic sentence): State the point of the paragraph in your own words, and make it connect to the previous paragraph. Example pattern: “A second line of work improves reliability by adding external evidence at inference time.” This immediately tells the reader what bucket they are in and why it follows.

2) Evidence (what sources show): Add 2–4 sentences summarizing the relevant findings. Use precise nouns: dataset name, metric, setting. Avoid vague verbs like “proves” or “demonstrates” unless the methodology truly supports it. This is also where you integrate citations smoothly: place them at the end of the sentence that contains the supported claim.

3) Comparison (connect sources): Explain how the sources relate: do they use different retrieval strategies, different evaluation protocols, or different baselines? This is where synthesis happens. If you have a consistent note template, you can compare along the same axis each time (data, method, evaluation, limitations).

4) Takeaway (why it matters): End with a “so what” sentence that sets up the next paragraph or section. Example: “These results suggest retrieval helps factuality most when the evidence source is high-quality, which motivates later work on citation filtering and confidence estimation.”

Practical outcome: after drafting, highlight only the first sentence of each paragraph. If those topic sentences read like a coherent outline, your review has flow. If they read like paper titles, you are still summarizing.

Section 5.4: Fair comparison language: avoiding overclaims and hype

AI literature is full of persuasive framing: “state-of-the-art,” “breakthrough,” “solves,” “human-level.” Your literature review should be the opposite: careful, conditional, and transparent about evidence. Fair language is not timid; it is accurate. It also protects you from accidentally misrepresenting a paper’s scope.

Use calibrated verbs. Prefer “reports,” “finds,” “observes,” “achieves,” “suggests,” or “is consistent with.” Reserve “outperforms” for cases where the evaluation is comparable and statistically or practically meaningful. When results depend on conditions, name them: “On summarization benchmarks with reference-based metrics…” or “In low-resource settings…”

When comparing methods, keep the playing field explicit. A fair comparison often requires one sentence of setup: “Because Paper A uses a larger model and more compute than Paper B, their scores are not directly attributable to the algorithmic change alone.” That sentence is valuable synthesis and signals integrity.

Replace hype with tradeoff language. Examples of balanced phrasing:

• “Improves X at the cost of Y” (accuracy vs latency, helpfulness vs faithfulness, privacy vs utility).
• “Works well when…” / “degrades when…” (domain shift, long context, noisy retrieval).
• “Compared with…” (define baselines and metrics explicitly).

Common mistakes: (1) attributing causality without evidence (“because the model understands better…”), (2) treating benchmark gains as general progress, and (3) ignoring negative results or limitations sections. A practical rule: for each subsection, include at least one limitation that multiple sources acknowledge (or that you infer from their evaluation choices). This improves balance and strengthens your conclusion.

Section 5.5: Connecting sections with transitions and signposts

Readers do not experience your outline; they experience the path between ideas. Transitions and signposts are how you control that path. Without them, even correct content feels like a pile of summaries. With them, your review reads like a guided tour of a research landscape.

Section openers: begin each section with 2–3 sentences that (a) remind the reader where they are in the overall structure, (b) state what this section will argue, and (c) define how you will compare sources. Example: “Having established common evaluation settings, this section compares three strategies for improving robustness under distribution shift, focusing on data augmentation, invariant representations, and test-time adaptation.”

Micro-transitions between paragraphs: use short bridge phrases that express logic, not chronology: “In contrast,” “A complementary approach,” “However, this setting assumes…,” “This raises a practical constraint…,” “To address this limitation…” These phrases should be earned by the content; don’t add them as decoration.

Forward references and backward reminders: occasional signposts prevent confusion when ideas recur. Example: “As discussed in Section 5.2, disagreement often stems from evaluation choices; we see this again in safety benchmarks.” Keep these brief so they don’t interrupt the reading.

Introduction and conclusion matched to scope: your introduction should state the scope boundaries (time range, tasks, types of sources) and the organizing structure you chose. Your conclusion should not introduce new papers; it should (1) summarize consensus, (2) summarize debates/tradeoffs, and (3) point to a specific gap or next step aligned with your research question. A mismatch—broad intro, narrow body, or vice versa—is a common issue that revisions should catch.

Section 5.6: Editing checklist: clarity, balance, and traceability

Revising a literature review is less about polishing sentences and more about tightening logic. Treat editing as a series of targeted checks. You are aiming for clarity (readability), balance (fair representation), and traceability (claims map to citations).

• Clarity: Delete throat-clearing and filler (“it is important to note,” “in today’s world”). Replace vague nouns (“this,” “things,” “issues”) with specific referents (task, metric, dataset, constraint). Keep paragraphs focused: one main claim each.
• Signposting: Ensure every section starts with a purpose statement and ends with a takeaway that sets up what comes next. If you can reorder two paragraphs without changing meaning, your transitions are likely weak.
• Balance: For each major approach, include both strengths and limitations. Avoid stacking only positive results for the approach you like. If a famous paper is central, still mention at least one credible critique, limitation, or replication concern.
• Traceability: Audit every non-obvious factual claim: can you point to a citation? Conversely, avoid “citation dumping” (a long list of references after a generic statement). Citations should support specific claims, not replace them.
• Comparability: Check that comparisons use consistent criteria. If you compare accuracy in one paragraph and cost in another, label the shift explicitly so the reader understands the lens changed.

A practical final pass: create a two-column table for yourself (not necessarily in the paper). Column A lists your main claims in order (from topic sentences). Column B lists the supporting sources and the key evidence (metric, dataset, setting). If any claim lacks evidence, either add support, weaken the language, or remove the claim. This “claim-to-citation” audit is one of the fastest ways to turn a draft into a review that feels rigorous and trustworthy.

Section 6.1: Citation basics: in-text vs reference list

Citations do two jobs at once: they give credit and they let others verify. In a literature review, almost every factual claim, numeric result, dataset description, or quoted definition should be traceable to a source. A common beginner mistake is to place one citation at the end of a long paragraph even though that paragraph contains multiple distinct claims from different papers. A safer habit is “cite as you go”: attach citations to the specific sentences they support.

In-text citations are the pointers inside your writing. The reference list (APA: “References”; IEEE: “References”) is the detailed retrieval information. If a reader cannot locate the source from your reference entry, the citation has failed—even if your in-text citation looks correct.

• APA (author–date): In-text: (Lee & Kumar, 2023) or Lee and Kumar (2023). Reference includes authors, year, title, venue, volume/issue/pages, DOI/URL when available.
• IEEE (numbered): In-text: [7]. Reference list is ordered by appearance and includes authors’ initials, title in quotes, venue in italics, year, pages, DOI.

Engineering judgment: choose a style early and stick to it. Switching styles mid-draft creates mismatched in-text markers and duplicate entries. Also, be precise about what you are citing. If you cite a survey paper for a claim that actually came from a primary experiment, your review looks shallow and your evidence is weaker. When possible, cite the original study for core results and use surveys for framing and coverage.

Practical outcome: after drafting, do a “citation sweep.” For each paragraph, ask: Which sentences are factual claims? Which paper supports each one? Add or split citations accordingly, and remove citations from purely your own interpretation or transitions.

Section 6.2: Reference managers and quick-start workflows

Reference managers (Zotero, Mendeley, EndNote, Paperpile) prevent the two biggest time sinks in beginner literature reviews: retyping bibliographic details and fixing formatting at the last minute. The workflow is simple: capture sources as you read, store PDFs and metadata together, and insert citations while drafting.

A quick-start workflow that works for most AI literature reviews:

• Step 1: Set up one library. Create a folder/collection for your topic (e.g., “LLM hallucination evaluation”).
• Step 2: Import from reliable identifiers. Prefer DOI, arXiv ID, or publisher pages. Browser connectors often pull complete metadata; PDF-only imports can be messy.
• Step 3: Attach the PDF and check fields. Verify author list, year, title capitalization, venue, and DOI. Fix errors immediately; they compound later.
• Step 4: Tag and take notes. Use tags like “survey,” “benchmark,” “theory,” “baseline,” “replication,” and add 2–3 bullet notes per paper.
• Step 5: Draft with citation insertion. Use the manager’s Word/Google Docs plugin, or export a BibTeX file if you write in LaTeX.

Common mistakes: duplicates (same paper imported twice from different sites), missing DOIs, and inconsistent author names (e.g., “J. Smith” vs “John Smith”). Deduplicate weekly. When a source is a web page or a model card, capture an access date (APA often requires retrieval date for changing content) and archive the link if possible.

Practical outcome: by the time you reach the final mini literature review, the reference list should be generated—not hand-built. Your job becomes spot-checking and polishing, not reconstructing citations from memory.

Section 6.3: Paraphrasing safely: keep meaning, change structure, cite

Plagiarism in literature reviews is often accidental: a student reads a paper, takes “notes” that are nearly copied sentences, and later forgets what was copied versus what was original writing. The fix is a disciplined note rule: every note must be labeled as quote, paraphrase, or your idea. If you cannot label it, you cannot safely draft from it.

Quoting is appropriate when exact wording matters: definitions, formal statements, or a sentence you plan to analyze. Use quotation marks (or block quotes for longer excerpts) and include a citation with page/section if available. Do not overquote; literature reviews should synthesize, not paste.

Paraphrasing means: keep meaning, change structure, and cite. Beginners often only swap a few words (“thesaurus paraphrase”), which is still too close to the source. A safer method is the “close–read–write” loop:

• Close: Read the passage and identify the single claim you need (e.g., what metric was used, what result changed, what limitation was reported).
• Read: Re-check the claim in the paper (numbers, conditions, dataset name). Capture exact details you must not change.
• Write: Look away from the paper and write the claim in your own sentence structure. Then add the citation.

Engineering judgment: preserve uncertainty and scope. If a paper says “in our setting” or “on dataset X,” your paraphrase must keep that boundary. Do not inflate a narrow result into a general conclusion. Also, keep numerical results exact; changing “~2%” to “significant improvement” is misleading unless the authors framed it that way.

Practical outcome: your notes become draft-ready building blocks. When you assemble the review, you can trust that each claim has a source and that your language is independently written.

Section 6.4: Responsible AI assistance: prompts, verification, and limits

AI tools can accelerate reading and drafting, but they can also introduce fabricated citations, distorted claims, and false confidence. The rule for responsible assistance is simple: AI can help you process sources, but it cannot replace verification. Treat the model as a helpful intern—fast, but not authoritative.

Use AI tools most safely in these tasks:

• Structure help: propose an outline for your literature review sections (background → themes → comparison → gaps).
• Extraction support: given a pasted excerpt, list variables, datasets, evaluation metrics, and stated limitations.
• Rewrite your own text: improve clarity of paragraphs you already drafted from verified notes.

Prompts that reduce risk specify inputs and constraints. Example pattern: “Using only the text in the excerpt below, list the evaluation metrics and the dataset names. If not stated, output ‘not stated.’” Another good pattern: “Generate a two-sentence paraphrase, but keep all numbers and dataset names unchanged.”

Verification checklist (do this even when the output looks plausible): (1) confirm every number against the PDF, (2) confirm that datasets and metrics match the paper’s method section, (3) confirm that limitations and conclusions are not exaggerated, (4) never accept a citation the AI invented—only cite sources you actually imported into your manager.

Limits and ethics: do not upload restricted PDFs or sensitive data to tools you are not allowed to use; follow your institution’s policies. If you used AI for substantial rewriting or summarization, disclose it according to your course or lab guidelines. Practical outcome: you gain speed without sacrificing accuracy or academic integrity.

Section 6.5: Reproducibility for beginners: search log and source tracker

Transparency is not only for advanced researchers. Even in a 2–4 page mini literature review, a simple record of how you searched and why you included sources protects you from “cherry-picking” and helps others replicate your path. This is especially important in AI topics where preprints, blog posts, and fast-moving benchmarks can shift quickly.

Create two lightweight documents alongside your draft:

• Search log (chronological): date, database (Google Scholar, ACM DL, IEEE Xplore, arXiv), exact query string, filters (year range, “review” keyword), and notes on what you changed next.
• Source tracker (table): citation key, type (survey/experiment/position), trust signals (peer-reviewed? reputable venue? citations?), decision (include/exclude), and reason (e.g., “out of scope,” “no evaluation,” “superseded by 2024 benchmark”).

Engineering judgment: define inclusion criteria early and keep them stable. For example: “English, 2019–2026, contains evaluation on public datasets, focuses on factuality in LLM outputs.” If you later relax a criterion (e.g., include a 2018 seminal paper), write that decision down. Readers do not require perfection; they require honesty.

Common mistakes: only saving final PDFs (not the search process), losing track of why a paper was rejected, and relying on citation counts alone as a quality signal. Practical outcome: your review becomes defensible—someone can see your method, not just your conclusions.

Section 6.6: Final packaging: formatting, final checks, and next steps

Your final mini literature review should read like a coherent argument, not a stack of paper summaries. Packaging is where academic skill becomes visible: consistent formatting, accurate citations, and clear synthesis. Aim for 2–4 pages with (1) a short introduction that states the research question and scope, (2) 2–4 thematic sections comparing papers using the same criteria, (3) a brief gap/limitations section, and (4) a conclusion pointing to next research steps.

Final formatting checklist:

• Consistency: one citation style (APA or IEEE), consistent tense (often present for general facts, past for specific studies), consistent terminology (don’t alternate “hallucination” and “fabrication” without defining).
• Reference integrity: every in-text citation appears in the reference list; every reference is cited at least once; titles and years are correct; DOIs included when available.
• Evidence alignment: every key claim is supported by an appropriate source (primary study when possible); no “floating” facts without citations.
• Ethics: quotes are marked; paraphrases are genuinely rewritten; AI-assisted outputs are verified against sources; AI usage is disclosed if required.

Common last-minute errors include broken numbered citations after rearranging paragraphs (IEEE), missing page numbers for direct quotes (APA/IEEE depending on context), and references generated from incorrect metadata. Do a final “source-to-sentence audit”: pick 5–10 sentences that carry your main storyline and open the cited PDFs to confirm each one.

Next steps: keep your search log and tracker; they become the foundation for expanding from a mini review into a full literature review chapter or related-work section for a paper. Your future self will thank you for treating citations and transparency as part of the research, not just formatting.