Chapter 3 — Finding the Literature

“If I have seen further it is by standing on the shoulders of Giants.” — Isaac Newton, letter to Robert Hooke, 1675

“Remember the days of old; consider the years of many generations; ask your father, and he will show you, your elders, and they will tell you.” — Deuteronomy 32:7 (ESV)

Why This Matters

Last week you sharpened a vague interest into a research question and scored it on FINER. You walked out of Chapter 2 with a Research Opportunity Report and a domain you committed to for the semester. Good. Now comes the move that separates a graduate researcher from a smart undergraduate with a strong opinion: before you build anything, you find out who has already stood where you are standing.

There is a name for the researcher who skips this step. We call them the person who reinvented the wheel — badly — and got desk-rejected for it. A reviewer’s first job is to ask “what’s new here?” and they answer that question by checking your work against the literature you claim to advance. If you don’t know the literature, you cannot make a novelty claim, and a paper with no defensible novelty claim is not a paper. It’s a blog post.

This week you become fluent in the discovery toolkit of 2026. Not just Google Scholar — every working researcher already knows Scholar exists. You will learn the four-layer toolkit: tools to FIND, tools to UNDERSTAND, tools to SNOWBALL, and tools to MANAGE. You’ll learn Boolean search like a librarian, citation chasing like a detective, and source management like someone who intends to still find this paper in March. The deliverable is your Annotated Bibliography — 20+ credible, verified sources in Zotero — and it is worth 10% of your grade.

Here is the AI thread, and it has two edges. The first edge: AI discovery tools are genuinely good now. Semantic Scholar’s TLDR summaries, Elicit’s data extraction, Connected Papers’ similarity graphs — these accelerate a literature search that used to take weeks. You should use them. The second edge will cost you your degree if you ignore it: large language models fabricate citations. Walters and Wilder (2023) found that 55% of the citations GPT-3.5 produced were entirely invented — real-sounding authors, plausible titles, DOIs that resolve to nothing — and even GPT-4 fabricated 18%. A separate study (Bhattacharyya 2023) found that 87% of the citations that did point to real works had at least one metadata error. An AI that hands you a beautiful, confident, nonexistent reference is not a glitch. It is the default failure mode of the technology, and it is the single fastest way for a graduate student to commit research misconduct without meaning to.

So the spine rule of this course, stated for this week: AI accelerates the search; the human verifies every reference against a real index before it enters the bibliography. No exceptions. We will build the verification habit into the very structure of your annotated bibliography.

And that brings us to the question under this chapter. Deuteronomy tells Israel to remember the days of old, ask your father, ask your elders — to refuse the arrogance of the present moment that imagines it invented thinking. Why must we remember the generations before us? Not from mere politeness to the dead. The honest researcher remembers because truth is older than us, because we are finite and the work is long, and because the temptation to claim more novelty than we’ve earned is exactly the temptation that fabricates a citation to fill a gap. The literature review is an act of intellectual humility before it is anything else. We’ll develop that in §3.12.

Coach’s Note — A literature search is not a one-time event you “do” in Week 3 and finish. It is a muscle you keep warm all semester. You will come back to these tools when you write your related-work section (Chapter 4), when you pick a baseline (Chapter 7), and when you choose a venue (Chapter 16). This week you build the gym. You’ll be training in it until May.

3.1 — The Four-Layer Toolkit

Beginners treat “search the literature” as a single action: type words into Google Scholar, read the first page. That is how you find the famous papers and miss the relevant ones. A working researcher uses four distinct kinds of tool, in sequence, because each does a job the others can’t.

You move down the layers and back up. FIND a seed set, UNDERSTAND it enough to keep the right papers, SNOWBALL from the keepers to find their ancestors and descendants, and MANAGE everything as you go so that in Week 4 you can actually write. Skip the SNOWBALL layer and you will miss the paper that scoops you — the one a reviewer will find in thirty seconds and you somehow didn’t.

Coach’s Note — Every tool below has a free tier as of mid-2026, but pricing and corpus sizes drift fast. Verify limits on the vendor’s live pricing page before you build a workflow that depends on a quota. A workflow that breaks when a free tier shrinks is a workflow you’ll regret in April.

3.2 — FIND: The Databases (and Which One for Which Job)

Each FIND tool has a personality. Use the wrong one and you’ll either drown or come up empty.

Google Scholar — the broadest net. An external estimate puts it north of 400 million documents (Google does not publish an official count). Indexes everything: journals, conferences, preprints, theses, even some gray literature. Its superpower is the “Cited by” link under every result — that’s your forward-citation engine. Its weakness: no quality filter. A predatory-journal paper and a NeurIPS paper sit side by side. Use it for recall, never for authority.

ACM Digital Library — the system-of-record for computing. As of January 1, 2026, the ACM DL went fully open access: the entire corpus is free to read (the free “Basic” edition), with paid “Premium” adding analytics and discovery features. For SE, HCI, graphics, systems, and theory, this is your authoritative source.

IEEE Xplore — the engineering counterpart (signals, networks, hardware, robotics, communications). Note the contrast: Xplore did not go open access; it remains subscription/institutional as of 2026. Reach it through your university’s library proxy.

arXiv — free preprints in cs.* categories (cs.LG, cs.CL, cs.CR, cs.CV, and so on). This is where applied-AI work appears first, often months before peer review. The catch is right there in that sentence: arXiv is moderated, not peer-reviewed. A finding on arXiv is a claim, not a confirmed result. Cite it, but know what you’re citing. (Two 2025–26 policy notes if you ever plan to post to arXiv: as of Oct 31, 2025 a CS survey/review/position paper must already be peer-review-accepted with a DOI; and as of Jan 21, 2026 new submitters need an endorsement beyond an institutional email. Your student lit review is not arXiv-postable as a survey — see Chapter 4.)

dblp — the free, CC0 computer-science bibliography maintained by Schloss Dagstuhl (its homepage in mid-2026 reports on the order of 8.6 million publications). dblp doesn’t host papers; it hosts authoritative metadata. When you need to verify that a paper is real and get its citation exactly right — author order, venue, year — dblp is the ground truth. It even labels arXiv items as “informal publications” so you know what you’ve got.

OpenReview — the open peer-review platform that runs ICLR, NeurIPS, and ICML. Here’s the move most students miss: on OpenReview you can read the reviews and the author rebuttals for accepted and rejected papers. Want to know what reviewers think is wrong with a line of work? Read the threads. The “the authors did not address X” comments are a goldmine of research gaps (we did this in Chapter 2).

Coach’s Note — Match the tool to the field. If your domain is HCI or software engineering, ACM DL is home base. If it’s networking, architecture, or robotics, it’s IEEE Xplore. If it’s machine learning, you live on arXiv and OpenReview and verify in dblp. Knowing where your field publishes is itself a piece of domain literacy you’re building this semester.

3.3 — Search Strategy: Boolean, Keywords, and the Iceberg

Typing a sentence into a search box is how you find what you already know about. To find what you don’t, you search like a librarian.

Build a keyword grid. Take your research question, pull out the 2–4 core concepts, and for each one list its synonyms — including the ones other subfields use. An LLM-for-SQL-optimization project might build:

Combine with Boolean. OR within a column (synonyms), AND across columns (concepts must co-occur), quotes for exact phrases, and parentheses to group:

("large language model" OR LLM OR "language model")
AND ("query optimization" OR "query rewriting" OR "cardinality estimation")
AND (database OR DBMS OR SQL)

Most databases also give you field operators. On many systems you can scope to title or author, e.g. intitle: on Google Scholar, or the structured advanced-search forms on ACM DL and IEEE Xplore. A starter grid template lives in code/search-strategy.txt — fill it in for your question this week.

Watch the iceberg. Your first query returns the famous tip. The relevant body of work is underwater, indexed under vocabulary you haven’t guessed yet. Two tells that you’re still at the tip: (1) every result is from the same three labs, or (2) you recognize every paper already. When that happens, mine the keywords sections and abstracts of your best hits for the terms they use, and re-run. Two or three iterations of this is normal and correct.

Coach’s Note — Keep a search log from day one: which database, which exact query string, the date, and how many of the hits you kept. This is not busywork. A systematic review requires this log, your reviewers may ask for it, and Future You will thank Present You when a reviewer says “did you consider work on X?” and you can answer “yes — here’s the query, here’s why it didn’t make the cut.” A template is in code/search-strategy.txt.

3.4 — SNOWBALL: Citation Chasing in Both Directions

Keyword search has a ceiling. The single most powerful technique for completeness is snowballing — following the citation graph. It comes in two directions, and you need both.

• Backward snowballing — read a paper’s reference list. These are the ancestors: the foundations the authors built on. Backward chasing finds the seminal work and the methods you’ll need to understand.
• Forward snowballing — find everything that cites this paper. These are the descendants: who extended it, who criticized it, who superseded it. Forward chasing is how you discover that your “novel” idea was published eighteen months ago. Google Scholar’s “Cited by” is the manual tool; Semantic Scholar and the graph tools automate it.

Connected Papers builds a similarity graph (not strictly a citation graph — it uses co-citation and bibliographic coupling) around a seed paper, so you find conceptually related work even when there’s no direct citation link. As of 2026 the free tier allows roughly 5 graphs per month.

Research Rabbit (acquired by Litmaps, announced May 2025; it moved to a freemium model in late 2025, with the free tier capping each search at around 50 seed papers) lets you build a collection of seeds and continuously discover similar and citing work, with alerts as new papers appear. Litmaps is its parent and adds monitoring/alerting on a saved map. Inciteful and scite round out the graph tools; scite additionally classifies citations as supporting, contrasting, or mentioning — which tells you not just that a paper was cited but how.

A practical exercise you’ll do this week: take one seed paper, snowball it in Connected Papers, then snowball the same seed in Research Rabbit, and compare the neighborhoods. They will not be identical. The disagreement is information — the union is your candidate set.

Coach’s Note — Snowballing is also your defense against the filter bubble. Keyword search returns what’s worded like your query; the citation graph returns what’s conceptually adjacent regardless of vocabulary. The paper that scoops you often uses words you’d never search for. The graph still connects you to it.

3.5 — UNDERSTAND: Reading-Triage Tools (Used Honestly)

You cannot read 200 abstracts at full attention. Triage tools help you decide what deserves a real read. Two cautions up front: these tools summarize and extract, and every summary can be wrong. They are a first-pass filter, never a substitute for reading the paper you decide to cite.

Semantic Scholar (Allen Institute for AI) — free; on the order of 200M+ papers and billions of citation edges (point-in-time, growing). Its TLDR one-line summaries and the Semantic Reader help you triage at speed. The S2AG API is free if you want to script your search.

Elicit (~138M papers; the free tier is generous as of 2026 after a pricing overhaul) — built for systematic review. It will extract structured fields from a set of papers into a table: method, sample size, outcome, and custom columns you define. This is a preview of your Chapter 4 comparison matrix. The discipline: let Elicit populate the cell, then hand-verify every cell against the PDF before you trust it.

Consensus (~200M+ papers; free tier capped around 20 searches/month) — answers a yes/no research question across papers and shows a “Consensus Meter,” with Study Snapshots that auto-extract methods and outcomes.

Here is the line you do not cross. These tools are grounded — they answer over a real index, so they hallucinate less than a bare chatbot. But “less” is not “never,” and an extracted number can be misattributed or an open-domain chatbot can invent the paper entirely. A grounded summary is a lead, not a citation. You verify the lead. Always.

3.6 — Verify Every Reference (The Non-Negotiable)

This is the most important paragraph in the chapter, so read it twice.

When any AI tool — chatbot, grounded summarizer, “deep research” agent — hands you a reference, you verify it exists and is described correctly before it enters your bibliography. The verification protocol is mechanical:

1. Does it exist? Search the exact title in dblp or Semantic Scholar or the publisher’s DL. If it doesn’t resolve, it’s fabricated. Delete it.
2. Is the metadata right? Confirm author list, year, and venue against dblp. LLMs routinely shuffle authors and invent venues.
3. Does it say what the AI claimed? Open the paper. Read enough to confirm the finding you’re about to cite. The AI’s summary is not evidence.

The numbers that justify this protocol: 55% of GPT-3.5 citations and 18% of GPT-4 citations were entirely fabricated (Walters & Wilder 2023); among the real ones, 43% (GPT-3.5) and 24% (GPT-4) had substantive errors. A 2023 study (Bhattacharyya) found 87% of citations to real works had at least one metadata error. Newer retrieval-grounded agents move these numbers down — but you cannot know by how much for the specific tool on the specific day, so you verify regardless.

The consequence is not abstract. ICCV has rejected papers containing nonexistent citations without review. arXiv announced (May 2026) a one-year submission ban for incontrovertible evidence of unchecked LLM content — hallucinated references among the named offenses. “The model gave it to me” is never a defense. You are accountable for every reference with your name on it. We’ll go deeper on disclosure policy in Appendix C; the integrity machinery is in Appendix B.

Coach’s Note — Build the verification into your tooling, not your willpower. In Zotero, I keep a tag #unverified that I slap on anything an AI suggested, and a rule for myself: nothing with #unverified is allowed in a draft. The tag is the gym buddy who won’t let you cheat the last rep.

3.7 — MANAGE: Zotero, and Why You Start Now

A reference you found but didn’t capture is a reference you’ll re-find at 1 a.m. before a deadline. From this week, every paper you keep goes into a reference manager.

Zotero — free, open-source, with a browser connector that captures a paper’s metadata and PDF in one click. It generates BibTeX for your acmart/IEEEtran paper, syncs across machines (300 MB free storage), and never locks your data behind a vendor. Note for 2026: Zotero has no native AI — AI features come only via third-party plugins (PapersGPT, Aria, Beaver). That’s arguably a feature: your library stays a clean, verifiable record.

Mendeley — Elsevier-owned, 2 GB free storage, with built-in AI tools (Reading Assistant, Ask My Library, Compare Experiments). The tradeoff is vendor lock-in and the politics of who owns your reading habits.

Our recommendation for this course: Zotero. It’s free, open, exports clean BibTeX for the LaTeX templates you started in Week 1, and keeps your data yours. The full setup is in Appendix B.

A Zotero workflow that scales for the semester:

1. Install Zotero + the browser Connector.
2. Create a collection per project (yours: your domain's lit review).
3. On any paper page (ACM DL, IEEE Xplore, arXiv, Scholar), click the
   Connector — it grabs metadata + PDF.
4. Add tags: your sub-topic, plus #unverified for anything AI-suggested.
5. Write the annotation in the item's Notes field (see §3.11).
6. Right-click the collection → Export → BibTeX  →  references.bib

A reference references.bib excerpt and an annotation template ship in code/references.bib and code/annotation-template.txt. Wire your Zotero export into the \bibliography{references} line of the paper skeleton you set up in Week 1.

3.8 — Deduping and Tracking Coverage

Two papers that are “the same” will haunt you: the arXiv preprint and its later published version. They have different identifiers, different page numbers, sometimes different titles, and a citation manager will happily store both. When you cite both as if they were two pieces of evidence, you’ve quietly double-counted a single result — a small but real distortion of the record. The rule: keep the most authoritative version (the published, peer-reviewed one), record the arXiv id in its note, and delete the duplicate. dblp helps here, because it explicitly links preprint and published entries and labels the arXiv item an “informal publication.”

Coverage is the other half of the discipline. A bibliography can be large and still have a hole the size of a reviewer’s objection. Before you call the search done, check three buckets:

If a bucket is thin, that thinness is your next query. Tools like Litmaps let you save a map and set an alert, so new work in the gap finds you instead of surprising you in a review. The empty bucket today is the “the authors failed to cite…” comment tomorrow — find it first.

Coach’s Note — Watch your own confirmation bias in the critical bucket especially. It is psychologically easy to collect twenty papers that agree with you and zero that don’t, and to mistake that for a thorough search. A literature review with no contrasting voice isn’t a review; it’s a brief for the defense. Go find the paper that argues you’re wrong. If you can’t find one, you haven’t looked hard enough — or you’ve found a genuinely uncontested gap, which is rarer than students think.

3.9 — A Discovery-Tool Cheat Sheet

You will not memorize fifteen tools this week, and you shouldn’t try. Memorize the four jobs and one default tool for each; reach for the specialists when the job demands it. Here’s the whole toolkit on one page, as of mid-2026 — verify free-tier limits live before you depend on them.

Coach’s Note — A footnote on a tool that isn’t here: Papers with Code was sunset by Meta on July 24, 2025. Its leaderboards and dataset links were a fixture of ML literature work for years, so older guides still point you there. The announced successor is “Trending Papers” on Hugging Face — but treat it as a different tool, not a drop-in replacement; the leaderboard/dataset coverage is not guaranteed to be the same. This is a small lesson in a big habit: the toolkit drifts, defunct tools linger in old advice, and part of staying a researcher is keeping your map current.

3.10 — Interactive Lab: Literature Search Builder

Open the Literature Search Builder embedded directly below this chapter on the site, and use it before you start Rep 1.

The widget walks you through the exact loop this chapter teaches. You’ll pick a goal (broad recall? authoritative metadata? citation snowball? grounded summary?) and the widget recommends which layer and which tool fits — so you stop reflexively reaching for Google Scholar for every job. Then you compose a Boolean query from a keyword grid: add synonyms within a concept (joined by OR), add concepts across columns (joined by AND), and watch the assembled query string update live. Finally you simulate a snowball from a seed paper — stepping backward to its references and forward to its citers — and the panel tracks your coverage: which tools you’ve used, how many seeds you’ve expanded, and where duplicates appear so you learn to dedupe.

What it teaches, in one sentence: the right tool for the goal, a query precise enough to find the iceberg, and a snowball disciplined enough to be complete. Run your real question through it. The query string it builds is the one you’ll paste into the databases for Rep 2.

3.11 — What an Annotation Actually Contains

An annotated bibliography is not a list of citations with a sentence of summary stapled on. A real annotation is a working note to your future self and your reviewers. For each source, write 100–200 words covering:

1. Citation — full, correct, verified (per §3.6).
2. Summary — the problem, the method, and the key result, in your own words. One or two sentences. If you can’t summarize it, you haven’t read it.
3. Method & evidence — what did they actually do? Dataset/benchmark, baseline, metric. (These become columns in your Chapter 4 comparison matrix.)
4. Relevance to your project — why is this in your bibliography? This is the sentence beginners skip and reviewers live for. Is it your baseline? A method you’ll adapt? The gap you’re filling?
5. Limitations / your critique — what didn’t they address? This is often your opening.

A filled template is in code/annotation-template.txt. Write annotations as you read, in the Zotero Notes field, not in a panic the night before the deadline. An annotation written from memory a week later is an annotation that quietly drifts away from what the paper actually says — which is its own small act of fabrication.

Coach’s Note — The “relevance to my project” line is the single highest-value sentence in the annotation, because it turns a reading list into an argument. Twenty summaries are a chore. Twenty arguments for why each paper matters to your gap — that’s the skeleton of your Chapter 4 literature review. You’re not just collecting. You’re building the case.

3.12 — Remembering the Generations: Why the Literature Review Is an Act of Humility

The blueprint puts a hard question under this week: why must we remember the generations before us? Deuteronomy 32:7 commands it directly — “Remember the days of old; consider the years of many generations; ask your father, and he will show you, your elders, and they will tell you” (ESV). Israel is told that the memory of what came before is not optional nostalgia; it is the condition for knowing the truth about where you stand.

Strip the theology for a moment and the research methodology is identical. The reproducibility crisis — Baker’s 2016 Nature survey found more than 70% of researchers had failed to reproduce someone else’s results, and over half had failed to reproduce their own — is in large part a crisis of not remembering carefully enough: not reading the prior work closely, not recording what was actually done, claiming more novelty than the record supports. The literature review is the discipline of remembering the generations before us accurately. It is how the long, slow, communal search for truth refuses to restart from zero with every arrogant newcomer.

Now put the theology back, because it does real work here. The Christian researcher remembers for a deeper reason than efficiency: truth is older than we are, and we did not invent it. Newton’s line about standing on the shoulders of giants — even sharpened as it was into a barb at Hooke — concedes the point. We see further because others stood first. To skip the literature is to pretend we are the first to think, which is precisely the pride that fabricates a citation to fill a gap rather than confessing “I don’t know — someone before me might.” A correct “this is already known, and here is who knew it” is worth more than a confident, lonely, wrong claim of novelty.

This is why the verification protocol of §3.6 is not bureaucratic box-checking but an ethical practice. To honor the generations before us, we have to cite them as they actually are — real authors, real findings, real limitations — not as a convenient hallucination dressed in their names. A fabricated citation does not merely break a rule. It bears false witness about what someone before you said. Deuteronomy says ask your elders, and they will tell you. The least we can do is report honestly what they told us.

3.13 — Common Pitfalls

Pitfall: Google-Scholar-only syndrome. Example: A student runs one Scholar search, reads page one, and declares the literature “covered” — missing the ACM DL papers, the OpenReview rebuttals, and everything the citation graph would have surfaced. Fix: Use all four layers. FIND in at least two databases, then SNOWBALL from your best hits. One tool is never coverage.

Pitfall: Trusting an AI-generated citation without verifying it. Example: A chatbot returns “Zhang et al., 2022, Neural Query Optimization, VLDB” — a real-sounding paper that does not exist. It lands in the bibliography and a reviewer catches it in thirty seconds. Fix: Run the §3.6 protocol on every reference: exists in dblp/Semantic Scholar? metadata correct? says what was claimed? Tag AI suggestions #unverified until you’ve checked all three.

Pitfall: Summarizing instead of annotating. Example: Twenty entries each say “This paper is about X and proposes Y.” None says why it’s in your bibliography. Fix: Every annotation ends with relevance-to-your-project and a limitation. Those two lines are what turn a reading list into a literature review.

Pitfall: No search log. Example: A reviewer asks “did you consider work on cardinality estimation?” and the student has no record of which queries they ran, so they can’t tell whether they missed it or screened it out. Fix: Log database, exact query string, date, and hits-kept from the first search. Template in code/search-strategy.txt.

Pitfall: Keyword tunnel vision. Example: Every result comes from the same three labs using the same vocabulary, and the student concludes the field is small — when in fact an adjacent subfield solved a related problem under different words. Fix: Mine your best hits for their keywords and re-run; snowball through the citation graph, which ignores vocabulary. Expect 2–3 query iterations.

Pitfall: Citing the preprint as a settled result. Example: A student writes “It has been shown that…” and cites an arXiv preprint that has not been peer-reviewed and whose central claim was later disputed. Fix: Know what you’re citing. arXiv is moderated, not peer-reviewed — phrase it as a claim (“X et al. report…”), verify the venue status in dblp, and check OpenReview if it was submitted to ICLR/NeurIPS/ICML.

Pitfall: Collecting forever, never reading. Example: 80 PDFs in Zotero, zero annotations, two days before the deadline. Fix: Annotate as you read, in the Notes field. A capped, well-read, well-annotated set of 20–25 beats an unread pile of 80.

3.14 — Reps

The reps for this week live in the exercises, and they move your project forward — by Friday you’ll have a real search log, a Zotero library, and 20+ verified, annotated sources. A preview:

• Rep 1 — build your keyword grid and Boolean query (use the widget).
• Rep 2 — run the search across at least three databases and log every query.
• Rep 4 — snowball one seed in Connected Papers and Research Rabbit and compare the neighborhoods.
• Rep 6 — the fabrication drill: ask a chatbot for five references, verify each in dblp, and record how many were real.
• Done? One Last Thing — assemble the full annotated bibliography that is this week’s deliverable.

Then take the “Check Your Reps” quiz embedded on this page. Five questions, grounded in this chapter. If you miss one, the explanation tells you which section to re-read.

3.15 — This Week’s Deliverable

Your deliverable is the Annotated Bibliography (20+ sources), specified in Project 3, and it is worth 10% of your course grade. You will assemble at least 20 credible, verified sources for your chosen-domain applied-AI project into a Zotero collection, write a structured annotation for each, and export both a BibTeX file and a formatted bibliography. The project file lays out the Normal / Medium / Hard tiers and the rubric. Start it the day you finish reading this chapter — a bibliography is built one verified source at a time, and it does not assemble itself the night before.

3.16 — Coach’s Final Word

Here’s the thing nobody tells you about the literature search: it’s the week you find out whether your idea from Chapter 2 is actually any good. Sometimes you’ll discover your “novel” idea was published last year — and that’s a gift, because you found out now, in Week 3, instead of in a reviewer’s rejection in Week 16. Other times you’ll find a small, real gap in a corner everyone else walked past, and you’ll feel the specific thrill of standing at the edge of what’s known. Either way, you can’t get there without doing the reading.

So do the reading. Use the AI to go faster — and verify every single reference like your degree depends on it, because it does. Remember the generations before you, and report honestly what they told you. That’s not a constraint on the work. That is the work.

See you on Monday.

Up next: the exercises for this week’s reps · Project 3 for the Annotated Bibliography deliverable · then Chapter 4, where these sources become a comparison matrix and a synthesized review. Reference shelf: Appendix A (research environment), Appendix B (researcher’s toolkit), Appendix C (using AI responsibly), Appendix D (glossary).