A student who meets an unfamiliar topic can now ask a tool to explain it, list the main studies, summarize what they found and draft a short report with references, all within a few minutes. Used well, these tools shorten the slowest parts of evidence work: getting oriented, assembling a first set of sources and reading many papers in limited time. Used carelessly, they produce confident summaries of papers the user has never opened and reference lists with errors the user cannot see.

This lesson teaches four tasks: using AI to scope a topic, finding a starting set of sources, reading and extracting from papers, and verifying citations. Its examples come from coursework, evidence briefs and the early stages of research. Systematic and scoping reviews have stricter requirements, and the series already teaches them in HSCI 241, where Lessons 3 and 4 cover database searching and Lesson 6 covers the use of AI in evidence retrieval and synthesis. This lesson points to those lessons wherever review methods come up.

One fictional case runs through the whole lesson. Box 5.1 introduces Jordan, a Health Sciences co-op student who is asked to prepare an evidence scan for the population health team of the Cedar Valley Health Authority.

An evidence scan is a time-limited summary of the best available evidence on a question, prepared to inform a decision. It states its methods and limits and accepts that it may miss some relevant studies, which is why AI research tools suit it well and why its methods differ from those of a systematic review.

Four Kinds of AI Research Tool

Almost every AI research tool in use in 2026 relies on the retrieval-augmented generation described in Lesson 2: it searches a collection of documents and asks a language model to write from the passages it retrieved. The tools differ in what they search (the open web, an index of scholarly records, or the sentences in which papers cite one another) and in what they produce (a short answer, a ranked list, a table of extracted details or a long report). Those two questions sort them into four categories. The products named are examples available in 2026, and the categories will outlast them.

The tabs that follow take each category in turn and describe how its tools work, their good first uses and what to watch for.

Table 5.1. The four categories of AI research tool compared.

Table 5.1 compares the four categories on what each searches, what each produces and its main watch-point.

The same tools appear in HSCI 241, where they are grouped differently, and Box 5.2 explains how the two lessons' groupings relate.

Because almost every one of these tools searches a collection of documents and writes from what it retrieves, the next part compares that approach with the search of a bibliographic database.

How AI Search Differs from a Bibliographic Database

A bibliographic database such as MEDLINE (searched through PubMed), CINAHL or PsycInfo holds a structured record for each article, with fields for the title, abstract, authors, journal and subject headings assigned by trained indexers. A search written in Boolean logic returns every record that matches it. Two people who run the same search in the same database on the same day obtain the same set of records, and the full search can be published so that a reader can see exactly what was done. HSCI 241 Lesson 3 explains how these databases work and how Boolean retrieval differs from relevance ranking.

An AI search tool works differently. It converts the query and each document into embeddings, the lists of numbers introduced in Lesson 2 that place texts with similar meanings close together, and ranks documents by how closely they match the query. This semantic search finds papers that express an idea in different words: a query about "community connectors" can return a paper about "link workers" without the user knowing that term. The tool shows the top-ranked documents, and a language model writes a summary from those documents alone. Figure 5.1 compares the two approaches, and three consequences follow.

A ranked top set has low and unknown recall

Recall is the proportion of all the relevant studies in existence that a search finds. A database search written for a systematic review aims for high recall, and HSCI 241 Lesson 3 shows how reviewers estimate it. An AI search tool shows the papers it ranks highest, so its recall is limited by design, and the user has no way to know how many relevant papers sit below the cut-off. Twelve excellent papers at the top of a list say nothing about the fifty relevant papers the tool did not show.

The weakest configuration is an assistant that answers from training without searching. Chelli and colleagues (2024) gave GPT-3.5, GPT-4 and Bard (later renamed Gemini) the inclusion criteria of eleven published systematic reviews on shoulder rotator cuff conditions. The two GPT models found 11.9 and 13.7 percent of the studies the reviews had included, Bard found none, and between 28.6 and 91.4 percent of the references the models produced were classed as hallucinated. Tools that search a scholarly index return real papers far more often, and none of them promises a complete set.

The same query can return different results

Reproducibility means that another person can repeat a search and obtain the same results. AI search tools are hard to reproduce for three reasons. The language model samples its words, so the same prompt can produce different text and different selections, as Lesson 2 explained. The index grows as new papers are added. The model and the ranking method are updated, often without notice. A user who runs the same question in March and again in June may receive a different set of papers and a different summary, and cannot reconstruct why. HSCI 241 Lesson 3, Section 4 discusses the same problem for web search engines.

The method is mostly hidden

A database documents its fields, subject headings and syntax. Most AI search tools disclose little about how they rank papers, which parts of each paper they read or which journals their index covers, and a summary written from the top-ranked documents can only be as complete as that set.

These three properties limit what an AI search can support. Box 5.3 describes the case in which a search must be complete and the place that AI tools have in it.

Because the two kinds of search differ in recall, reproducibility and transparency, the right choice depends on the task, and the next part matches common literature tasks to a kind of tool.

Matching the Tool to the Task

The most useful habit with these tools is to decide what the task needs before choosing one. Some tasks need orientation, and a fast, fluent overview with a few good sources serves them well. Some need a citable source for a specific claim, and the tool's answer is only a pointer to a paper that the user must open and read. Some need completeness or exact repetition, and those belong to a database. Table 5.2 matches common tasks to a category and to the check that applies.

Table 5.2. Common literature tasks, a suitable kind of tool and the check that applies.

Box 5.4 follows Jordan through a first morning with three kinds of tool, and Box 5.5 sets four tasks for which the reader names a starting tool and the check that applies.

On Jordan's first morning, a scholarly search summary reported the studies accurately and left out how weak the evidence was. The next part sets out in general terms what AI research tools do well and where they fall short.

What AI Research Tools Do Well and Poorly

AI research tools are excellent at orientation: within an hour, a student can know the vocabulary of a field, its main debates and its most cited reviews. They are weak wherever completeness, exact repetition or faithful representation of a source is required. The cards below summarize the four points that the rest of the lesson builds on.

The four points summarized in the cards carry into the rest of the lesson. Box 5.6 records where Jordan's evidence scan stands at the end of this section and what Section 2 does with it, and the reflection and knowledge check that follow close the section.

Scoping is the work a researcher does before searching: learning what a topic contains, what its parts are called, what its main debates are and which reviews already exist. It used to take days of reading. Language models are strong at exactly this kind of work, because it is mostly work with words: explaining terms, listing synonyms, grouping ideas and describing how a field is organized. This section shows how to use that strength to map a topic and draft a search, and how to test the draft in a database, where the model's weaknesses show up.

Mapping an Unfamiliar Topic

A useful topic map has six parts. It defines the core concepts in plain language. It lists the terms that different countries and disciplines use for the same idea. It names the main debates and open questions. It identifies the usual study designs and outcome measures. It points to the major reviews and reports, and it notes the organizations that fund, run or study the work. An assistant can produce a first version of all six parts in a minute, and the student's task is to confirm the parts that matter against sources.

Box 5.7 shows Jordan's prompt for a six-part map of social prescribing, an abridged output and a commentary on which parts held up when they were checked.

The pattern in Box 5.7 is typical. Explanations, vocabularies and lists of debates draw on the general knowledge that a language model learned from a very large body of text, and they are usually reliable for established topics. Precise facts about a specific system, such as which headings a thesaurus contains this year, are the kind of detail that models get wrong, either because the fact changed after training or because the model generates a name that fits the pattern. A topic map is therefore a set of leads to confirm, with the definitions checked against a recent review and every database-specific detail checked in the database itself.

The five cards that follow set out the steps of mapping a topic with an assistant, from mapping the concepts to asking what the map has left out.

A confirmed topic map supplies the concepts and vocabulary for a database search, and the next part turns them into a first search string.

From Concepts to a First Search String

A database search begins with a concept table: a grid that breaks the question into its main concepts (for Jordan, social prescribing, loneliness and older adults) and lists, for each concept, the database's subject headings and the free-text words that authors use. A subject heading is a term from a controlled vocabulary that indexers assign to each record, such as MeSH (Medical Subject Headings) in MEDLINE. Free-text terms catch records that were never indexed or were indexed under another heading. Terms for the same concept are joined with OR, and the concept blocks are joined with AND. HSCI 241 Lesson 4 teaches the concept table, Boolean operators, truncation and field tags in full; this section concentrates on what AI adds and what it gets wrong.

An assistant can turn a topic map into a draft concept table and a search string in seconds, and the draft is often a good start. Wang and colleagues (2023) tested ChatGPT on the task of writing Boolean queries for systematic review topics. Its queries often achieved high precision, meaning that a large share of the records they returned were relevant, at the cost of lower recall, which led the authors to suggest that the approach may suit rapid reviews, where time is short and some loss of recall is acceptable. The same prompt produced different queries on different occasions, and 55 percent or more of the MeSH terms that ChatGPT generated in one of their experiments were not in the MeSH vocabulary at all. Both problems appear in Jordan's draft.

Box 5.8 gives the PubMed search that the assistant drafted from Jordan's topic map and the result of running it, and Box 5.9 asks the reader to list its problems before showing the four that Jordan found.

#1 "social prescri*"[tiab] OR "link worker*"[tiab] OR "community connector*"[tiab] OR "Link Workers"[Mesh]
#2 "Loneliness"[Mesh] OR lonel*[tiab] OR "Social Isolation"[Mesh] OR "social isolation"[tiab]
#3 "Aged"[Mesh] OR "older adult*"[tiab] OR elderly[tiab] OR senior*[tiab]
#4 #1 AND #2 AND #3 AND "Randomized Controlled Trial"[pt]

Jordan corrected the four problems and ran the search again. The corrected three-concept search returned 104 records, and it still found none of the three known reviews. The reason is instructive. The three reviews study social prescribing in general. Two of their records do not mention loneliness at all, and the third, which does, was excluded by the age concept because its record neither uses the older-adult terms nor carries the heading "Aged". Requiring all three concepts excluded the most important papers in the field. This is the purpose of a known-item test: checking whether a search retrieves a small set of relevant papers that the searcher already knows about. A search that misses known items is missing other papers like them.

Jordan revised the strategy for the purpose of the scan, which is to find reviews first. The social prescribing concept on its own, combined with PubMed's filter for systematic reviews, returned 73 records and included all three known reviews. A second search, combining the social prescribing and loneliness concepts without the age concept, returned 229 records for primary studies, and Jordan screened both sets for studies of older adults by reading titles and abstracts.

The revised strategy, with the record counts obtained on the test date, reads as follows.

#1 "Social Prescribing"[Mesh] OR "social prescri*"[tiab] OR "link worker*"[tiab] OR "community connector*"[tiab] OR "community navigator*"[tiab]
#2 "Loneliness"[Mesh] OR lonel*[tiab] OR "Social Isolation"[Mesh] OR "social isolation"[tiab] OR "socially isolated"[tiab]
#3 #1 AND systematic[sb]          (reviews: 73 records, all three known reviews found)
#4 #1 AND #2                      (primary studies: 229 records)

None of these corrections required deep expertise; each required running the draft and looking at what it did. An assistant can help with that step as well. Pasting the record counts and the known-item results back into the conversation and asking "Why might this search miss these three papers, and what would you change?" usually produces sensible suggestions, which the student then tests in turn.

Figure 5.2 summarizes the workflow that this case follows, from the AI-drafted search through testing and revision to the librarian's review.

The four items that follow describe the checks that apply to any AI-drafted search: checking every heading in the thesaurus, running a known-item test, reading the first fifty results and testing the assistant's explanations.

A tested keyword search can still miss studies that describe the topic in other terms, and the next part turns to citation chasing, which follows the links between papers.

Citation Chasing with AI Help

Citation chasing follows the links between papers: backward through the reference list of a relevant paper, and forward to the later papers that cite it. It finds studies that a keyword search misses, especially in fields such as social prescribing where terms vary. AI tools make several parts of it faster. Semantic Scholar and scite list the papers that cite a given paper and show the sentences in which they cite it, so a student can see quickly which later papers built on a review and which disputed it. Scholarly AI search engines can return papers similar to a seed paper, and an assistant can summarize the citing sentences and sort them by theme. Jordan used the three known reviews as seed papers and found two later evaluations that neither database search had returned.

These tools have limits that matter for completeness. Their citation data cover only the papers in their index, and tools that recommend "similar" papers choose them by algorithm, so they suit exploration more than exhaustive searching. HSCI 241 Lesson 5 teaches complete forward and backward citation chasing for reviews, with tools that export full lists of cited and citing records for screening.

With the database search tested and supplemented by citation chasing, the remaining step before reading is a librarian's review of the search, the subject of the next part.

Asking a Librarian to Review the Search

Errors in a search strategy rarely show in its results: a missing synonym or a wrong heading simply produces a list that looks plausible. For this reason, systematic reviews have their searches peer reviewed by a second librarian or information specialist, using the PRESS guideline that HSCI 241 Lesson 4 teaches. An evidence scan or the search behind a short literature review rarely needs a formal peer review, and it still benefits from a short consultation with a health sciences librarian at a university or health authority library.

An AI-drafted search makes that consultation more productive when the student brings the right material. That material includes the question and the purpose of the search, the concept table, the full search with a note of which lines the AI drafted and what the student changed, the record counts, the known items and whether each was found, and the databases the student plans to search. A librarian can then spend the time on judgement, for example on whether a filter is appropriate or whether a second database such as CINAHL or PsycInfo is needed, instead of on reconstructing what was done. Jordan's consultation with the health authority's librarian added CINAHL, which indexes many nursing and allied health evaluations, and replaced two free-text terms with better ones.

Box 5.10 describes how the search for an evidence scan is recorded and how that record works together with the AI use log.

The next part draws together what this section has shown about where AI helps and where it fails in scoping and searching.

What AI Does Well and Poorly in Scoping and Searching

For scoping, AI tools are among the most useful aids a student has. They explain a field's concepts clearly, supply vocabulary that a newcomer would not know, summarize its debates and point to its major reviews, and they do so in minutes. For building a search, they produce a reasonable first draft with good free-text synonyms. They are unreliable on the details of a particular database: they invent subject headings, miss recent ones, apply limits that defeat the purpose of the search and cannot run the search to see what it returns. The draft is a starting point, and the database tests, the known-item check and the librarian's review make it a search.

Box 5.11 records where Jordan's evidence scan stands at the end of this section and what Section 3 does with the reviews and studies found, and the reflection and knowledge check that follow close the section.

Once a starting set of sources exists, most of the time in evidence work goes into reading. Lesson 4, Section 3 showed how AI can help a student understand a difficult paper: generating a reading guide, defining terms, explaining a table and answering questions from documents the student uploads. This section turns to reading for evidence work, in which the reader records the same details from every paper so that the papers can be compared, and writes summaries that other people will rely on. AI saves a great deal of time on both tasks, and both have characteristic errors that a careful reader learns to catch.

Structured Extraction

Data extraction is the recording of the same set of details from each study in the same form. The result is an extraction table, sometimes called a comparison table, with one row per study and one column per detail. Reading across a row tells you what one study did and found; reading down a column shows how the studies differ in design, population or result. A table of this kind is the backbone of an evidence scan, a literature review section or a briefing note, because it makes the strength and consistency of the evidence visible at a glance.

Table 5.3 lists the fields that most extraction tables contain, together with the errors that AI tools most often make in each field. The errors follow a pattern: they tend to make a study look stronger, more relevant to the user's question or more certain than it is, because a model writing fluent text drifts toward the most typical phrasing, and the most typical phrasing in research abstracts is confident.

Table 5.3. Fields in an extraction table and the AI errors to watch for in each.

A good extraction prompt guards against these errors directly. It gives the tool the text of the paper, so that the model works from the source and has no need to recall it. It asks for one paper at a time, which makes each output short enough to check. It asks for a supporting quotation for every value, with the section or page where it appears. It tells the model to write "Not reported" when the paper does not state a value, so that a gap is not filled with a plausible guess.

Box 5.12 gives an extraction request that builds these safeguards into a single prompt.

Two practical rules apply before anything is uploaded. The first concerns licences: open-access articles may be uploaded freely, while library licences for subscription journals can restrict uploading full texts to AI tools, so the student checks with the library first (HSCI 241 Lesson 6, Section 3 discusses this). The second concerns the tool's data rules: in the Cedar Valley pilot, published articles are public documents and may be used with the enterprise assistant, while unpublished manuscripts sent to the team for comment are confidential and may not.

With a prompt of this kind in place, the remaining question is how accurate the extracted values are, which the next part examines.

How Accurate Is AI Extraction?

Gartlehner and colleagues (2024) tested a large language model, Claude 2, on data extraction for evidence synthesis. They took a convenience sample of ten open-access reports of randomized controlled trials included in one systematic review, chose sixteen types of data of varying difficulty, and uploaded each article to the browser version of the model with a prompt for each data element. Across the 160 data elements, the model's overall accuracy was 96.3 percent, and two repeat runs gave 96.9 and 95.0 percent. It made six errors, and four of the six were data items it missed. The model needed no technical expertise or training data, and the authors judged the approach promising.

Worked Example 5.1 works through what an accuracy of 96.3 percent implies for a comparison table of ten studies and ten fields.

The study is a proof of concept, and its conditions were favourable: clearly reported randomized trials, open-access full texts and a fixed set of well-defined data elements. Program evaluations, grey literature reports and studies that report results in several places are harder to extract from, and the study cannot show how a model performs on them. Systematic reviews deal with this risk by having two people extract data independently and resolving disagreements, and any use of AI in that process is checked by a human (HSCI 241 Lesson 6). For an evidence scan or a literature review, the practical conclusion is that AI extraction is a fast and usually accurate first pass that has to be checked value by value against the paper.

Box 5.13 follows Jordan through that check. Table 5.4 shows the assistant's extraction of the three reviews as produced, and Table 5.5 gives the values Jordan corrected after checking them against the articles.

Three things stand out in the case. The assistant saved Jordan most of the reading time, and eight of the twelve extracted cells were correct, with the four wrong cells containing three distinct errors. The errors were of the kinds listed in Table 5.3, upgraded designs and generalized findings, and each made the evidence look stronger than the reviews report. The quotations made the check fast, because each value could be traced to a passage in a few seconds.

Accurate extraction is one product of AI-assisted reading, and the next part turns to the other, the summaries that an evidence scan contains.

Summaries for Different Purposes

An evidence scan contains summaries of several kinds, and each needs a different instruction. A one-sentence summary for a comparison table must name the design, the population, the main finding and its certainty. A paragraph for a briefing note must say what the evidence means for a decision while keeping the authors' qualifications. A plain-language summary for the public must be accurate and readable, and Lesson 6 develops that task. A critical summary for a reviewer must set out strengths and limitations. Table 5.6 pairs each purpose with an instruction to include in the prompt and the check that applies.

Table 5.6. Summaries for different purposes.

The commonest error in AI summaries is overgeneralization: stating a finding as if it applied more broadly than the study supports. A summary overgeneralizes when it turns a past-tense result about particular participants ("loneliness scores fell among participants in one United Kingdom program") into a general present-tense claim ("social prescribing reduces loneliness"), when it drops the population or setting, or when it removes the authors' hedges. Peters and Chin-Yee (2025) compared 4,900 summaries of scientific texts written by ten large language models with the original texts. Most models produced broader generalizations than the originals, with several of them overgeneralizing in 26 to 73 percent of cases. Summaries written by the models were nearly five times as likely to contain broad generalizations as summaries of the same articles written by experts for NEJM Journal Watch, prompts asking for accuracy made the problem worse, and newer models tended to perform worse than older ones. Tang and colleagues (2023) found that two earlier models could produce summaries of medical evidence that were factually inconsistent with the source or overly convincing, that they struggled to identify the most important information, and that they made more errors with longer texts.

These findings suggest practical countermeasures. None of them guarantees a faithful summary, and together they make errors much easier to find. Ask every summary to name the population, setting and design. Ask for results in the past tense and for the authors' certainty in their own words. Compare each summary with the abstract's conclusion and the discussion of limitations, and look specifically for words that broaden the claim, such as "reduces", "improves", "effective" and "people" where the study said "was associated with", "participants" or "in this sample".

Box 5.14 applies these countermeasures to two short summaries of the review by Kiely and colleagues (2022).

These countermeasures make errors easier to find, and finding them still depends on checking each value and summary against the paper, which the next part sets out as a routine.

Checking Against the Full Text

Checking an extraction table follows a fixed routine, and with supporting quotations it takes a few minutes per paper. For each value, find the quoted passage in the paper and confirm that it says what the value says. Check every number against the paper's tables, including the denominator, since a review's total sample and the number analyzed for one outcome are often different. Check the design label against the methods section and the population against the eligibility criteria. Read the authors' conclusion and limitations and compare them with the finding and certainty cells, which is where overgeneralization shows. Search the paper for any value marked "Not reported" before accepting the gap. Finally, mark each cell as verified or corrected, and keep the checked table with the entry in the AI use log. Figure 5.3 shows the routine.

Tools that answer only from documents the user supplies reduce the risk of invented content, and Box 5.15 explains why the same checks still apply to them.

Extraction and summaries are a first pass. For the two or three papers that carry most of the weight in a brief or a review section, the student still reads the full text, because the details that change an interpretation, such as how participants were recruited or how many were lost to follow-up, often sit in methods sections and tables that a summary leaves out.

The next part draws together what AI does well and poorly in reading and extraction.

What AI Does Well and Poorly in Reading and Extraction

AI tools extract clearly reported details accurately and quickly, produce summaries at any length, restructure findings into tables and adapt a summary to its audience. In the best available test, a model extracted data from trial reports with about 96 percent accuracy. Their errors cluster in predictable places: upgraded designs, wrong denominators, missed items and summaries that state findings more broadly and more confidently than the authors did. Supporting quotations, a fixed checking routine and a habit of comparing every summary with the authors' own conclusion catch most of them.

Box 5.16 records where Jordan's evidence scan stands at the end of this section and what Section 4 does before the scan goes to the team, and the reflection and knowledge check that follow close the section.

Every claim a student cites carries the student's name, and in professional settings a wrong citation can misinform a decision. Lesson 3 introduced the errors that AI tools make, including the case in which lawyers were sanctioned for citing court decisions invented by a chatbot. This section applies those lessons to references, where AI errors are most common in academic work.

Why AI Tools Produce Fabricated and Misattributed References

Lesson 2 explained that a language model writes by predicting the next token. A reference is an unusually predictable piece of text: author surnames, a year, a title in a familiar style, a journal name, volume, pages and a DOI (digital object identifier). When a model has no retrieved record to copy from, it assembles plausible parts: a real author's name with a title that author never wrote, a real journal with an invented article, or a correct title with the wrong year. The result is a fabricated reference, one that describes a publication that does not exist, or a misattributed reference, one that points to a real publication but gets its details wrong or credits a claim to the wrong source.

Walters and Wilder (2023) measured the problem directly. They asked GPT-3.5 and GPT-4, the two versions of ChatGPT available in 2023, to write short literature reviews on 42 topics and checked all 636 references in the 84 reviews. Of the GPT-3.5 references, 55 percent were fabricated, compared with 18 percent of the GPT-4 references. Among the references that did exist, 43 percent of those from GPT-3.5 and 24 percent of those from GPT-4 contained substantive errors in their details. Newer models have continued to improve without solving the problem. In a 2026 study, Bernstein and colleagues asked a late-2025 version of ChatGPT for references supporting orthopaedic clinical practice guideline recommendations: 7.1 percent of its 2,736 references were fabricated, and only about half were correct in every bibliographic detail checked.

Retrieval changes the picture, because a tool that searches before it answers can cite documents that exist. Fabrication becomes rare, and a different error becomes the main concern: a real source cited for a claim it does not make. Wu and colleagues (2025) built an automated system to check whether the sources cited by seven large language models supported the statements they were cited for, across 800 medical questions and 58,000 pairs of statements and sources. Between 50 and 90 percent of the models' responses were not fully supported, and some were contradicted, by the sources they cited. Even for a model with web search, about 30 percent of individual statements were unsupported and nearly half of its responses were not fully supported. Retrieval makes references real, and the check described below establishes whether they support the claims made for them.

Table 5.7. Four outcomes of a citation check.

Table 5.7 defines the four outcomes that a citation check can reach, with the typical sign of each and the action it calls for.

Every cited reference ends in one of these four outcomes, and the next part sets out the four steps that decide which one applies.

A Four-Step Citation Check

The check below takes a few minutes per reference and applies to every source a student cites, whether an AI tool supplied it or not. Figure 5.4 shows the four steps and the outcome that each failure points to.

Step 1: confirm that the reference exists. Search the exact title, in quotation marks, in PubMed, Google Scholar or the library's discovery tool, and enter any DOI at doi.org or search for it in Crossref, the agency that registers most journal DOIs. Compare the authors, year and journal with the record you find. A DOI can resolve to a different paper, so the match has to be checked. A reference that none of these systems can find is treated as non-existent.

Step 2: open the source. Read at least the abstract and, for any source that carries weight, the relevant part of the full text, through the library if necessary. Note the article type, since a commentary, protocol or letter cannot support a claim about study results, and check the publisher's page for a retraction or correction notice.

Step 3: find the claimed finding in the text. Locate the passage that supports the claim and compare it on the four points where AI text drifts: the population and setting, the design, the direction and size of the result, and its certainty. A claim found only in a paper's introduction, where the authors describe other people's work, is a secondary citation, and the original source should be found and cited instead. If the original supports the claim as worded, the citation is classed as misattributed and only the reference changes; if it does not, the claim is classed as inaccurate and is rewritten to match what the original found.

Step 4: record the result. Enter the reference, the outcome of each step, the verdict and the action in a verification log, a simple table kept with the AI use log from Lesson 3. The log shows a supervisor or team lead what was checked, and it saves the student from checking the same source twice.

HSCI 241 Lesson 6 teaches a closely related four-step procedure for systematic reviews, in which the last step checks a source against the review's eligibility criteria and its retraction status. The check in this lesson is the general version for any cited claim.

Worked Example 5.2 applies the four steps to the first ten citations in a deep research report on wildfire smoke and the health of older adults, and Table 5.8 gives the result of each check.

The audit applied all four steps to every citation it examined. The next part considers how the depth of checking should depend on how a source will be used.

Matching the Check to the Stakes

Lesson 3 taught that verification effort should rise with the consequences of an error. Every source that a student cites in work that others will read or act on goes through all four steps. Sources used only for orientation need less: confirming that the source exists and reading the abstract before relying on it. Material that will inform a program or policy decision justifies a second reader who repeats Step 3 for the claims that carry the most weight.

The next part describes the further rules that apply when the work is a systematic or scoping review.

Additional Rules for AI in Systematic Reviews

Systematic and scoping reviews add rules to everything in this lesson, because a review makes stronger promises to its readers. In 2025, Cochrane, the Campbell Collaboration, JBI and the Collaboration for Environmental Evidence issued a joint position statement on AI in evidence synthesis (Flemyng and colleagues, 2025). It states that evidence synthesists remain ultimately responsible for their work, including the decision to use AI; that AI may be used only when the authors can show it will not compromise the rigour or integrity of the synthesis; that AI should be used with human oversight; and that any use of AI that makes or suggests judgements must be fully and transparently reported. The statement supports the RAISE recommendations (Responsible use of AI in evidence SynthEsis). Reporting follows PRISMA 2020 (Page and colleagues, 2021), in which studies that an AI tool found enter the flow diagram as records identified by other methods. HSCI 241 Lesson 6 develops these rules, together with the AI-assisted search log, disclosure statements and active-learning screening.

Two boxes complete the section. Box 5.17 suggests a way to build judgement about the tools by testing them on a familiar topic, and Box 5.18 draws together the strengths and limits described across the four sections, with Table 5.9 setting out six tasks, how AI performs on each and the check that applies.

The reflection and knowledge check that follow close this final section of the lesson.

Bringing It All Together

This lesson followed four tasks in which AI tools now save students and practitioners a great deal of time: understanding an unfamiliar topic, assembling a starting set of sources, reading and extracting from papers, and verifying citations. The tools fall into four categories, namely assistants with web search, scholarly AI search engines, citation-context tools and deep research agents, and all of them rank and select. That design makes them excellent for exploration and unsuited to searches that must be complete and reproducible, which remain the work of bibliographic databases and of the review methods taught in HSCI 241.

Across the lesson, the same pattern recurred. AI output was strongest where the task was work with language, such as explaining concepts, supplying vocabulary, structuring a table or drafting a summary, and weakest where it depended on exact facts about a particular system or source: which subject headings a thesaurus contains, which study design a review included, or which paper a finding came from. The checks that catch these errors are specific and quick: testing a draft search in the database, running a known-item test, requiring supporting quotations, comparing summaries with the authors' conclusions, and applying the four-step citation check.

The wildfire smoke audit showed what those checks find in practice. Most citations in an AI research report pointed to real papers, and half were accurate in every respect, while others credited a real finding to the wrong paper, overstated what a paper showed, or rested on a source that did not exist. Each of those errors would have reached the reader without the check.

The final reflection asks you to bring the whole lesson together in a workflow for a short evidence brief.

Final Knowledge Assessment

Terms, tools and researchers that appear in this lesson on AI-assisted literature searching and reading.