1.1 Why AI Capability Is Uneven

Most people who use a general-purpose assistant for a few weeks have a puzzling experience. The assistant explains a difficult idea, such as the difference between a confidence interval and a prediction interval, more clearly than many textbooks do. In the next conversation it supplies a reference to a journal article that does not exist, or it miscounts the words in a short paragraph. To a person, these tasks differ greatly in difficulty: explaining a statistical concept takes years of training, while counting words takes only patience. The assistant's performance runs in the opposite direction.

Dell'Acqua and colleagues (2023) gave this pattern a name. They described the capability of AI as a jagged frontier, a boundary between the tasks that a tool performs well and the tasks that it performs poorly. The boundary is jagged because it does not follow the human sense of what is easy and what is hard. Tasks inside the frontier can be done faster and to a higher standard with AI help. Tasks outside it, including some that look simple, are done badly, and the output for these tasks usually looks as fluent and confident as the output for tasks inside the frontier. This last feature is what makes the frontier important for users. A tool that failed visibly would be easy to use safely. A tool whose failures look like its successes can be used safely only by someone who knows where the boundary lies for the task in front of them.

Lesson 2 explains the mechanism behind this unevenness. A large language model writes by repeatedly estimating the probability of the next token (a word or part of a word), using patterns learned from a very large body of text. Explaining, restructuring, summarizing, translating and drafting draw directly on those patterns, so the model does them well. Exact recall of a specific detail, such as the page numbers of an article, depends on whether that detail was learned precisely, and a model that learned only the general shape of such details produces the right shape with the wrong content. Recent events, local information and precise arithmetic are also weak unless the tool can search, retrieve documents or run code. Judgements about what a particular community or organization values fall outside the frontier because the tool has no access to that knowledge unless someone supplies it.

Box 3.1 introduces the fictional case of Jordan, a co-op student whose work with the Cedar Valley pilot runs through this lesson, and Figure 3.1 then sketches the frontier for a general-purpose assistant.

Figure 3.1 arranges tasks in four broad kinds that recur throughout the course. The frontier reaches furthest for transforming material that you supply and is shortest for recalling specific facts and sources. Counting and calculating sit in between and move inward when the tool runs code. Judging local needs and values lies largely outside, because the information lives with people and organizations.

Section 1.1 has described the frontier and the mechanism behind its shape. Section 1.2 turns to the field experiment that gave the frontier its name and measured what happens on each side of it.

1.2 The Consulting Experiment

The evidence for the jagged frontier comes from a preregistered field experiment with 758 consultants at Boston Consulting Group, about 7 percent of the firm's consultants (Dell'Acqua and colleagues, 2023). A preregistered experiment is one whose hypotheses and analysis plan were recorded before the data were collected, which protects against choosing the analysis after seeing the results. The consultants were randomly assigned to work without AI, with access to GPT-4, or with access to GPT-4 together with a short overview of prompting techniques. The researchers designed a set of tasks chosen to lie inside what GPT-4 could do and one task chosen to lie outside it.

Inside the frontier, the consultants completed 18 realistic tasks built around the development of a new product, including generating ideas, analyzing a market and writing persuasive material. Consultants with AI completed 12.2 percent more tasks, finished them 25.1 percent more quickly on average, and produced work rated more than 40 percent higher in quality than the work of consultants without AI. The consultants who had scored lowest on a baseline task gained the most (an improvement of 43 percent compared with 17 percent for higher-scoring consultants), so AI narrowed the gap between weaker and stronger performers on these tasks.

Outside the frontier, the consultants worked on a business problem that required them to combine figures from spreadsheet data with details from interview notes. GPT-4 tended to produce a confident, well-organized answer that missed the details on which the correct recommendation depended. Without AI, about 84 percent of consultants reached the correct answer. With AI, only 60 to 70 percent did. Many consultants accepted a persuasive analysis that was wrong, and the quality of the writing gave no sign of the error.

Table 3.1 sets out these results for the tasks inside the frontier and for the task outside it.

Table 3.1. Main results of the field experiment by Dell'Acqua and colleagues (2023), as reported by the authors.

Box 3.2 considers how far results obtained with management consultants and GPT-4 in 2023 apply to health sciences students and public health staff.

The experiment showed gains in speed and quality inside the frontier and a loss of accuracy outside it. The next subsection describes the two working styles that the researchers observed among consultants who used the tool successfully.

1.3 Centaurs and Cyborgs

The researchers also examined how successful consultants worked with the tool, and they described two working styles. Centaurs, named after the mythical creature that is half human and half horse, divided the work: they drew a clear line between the parts they did themselves and the parts they delegated to the AI, and they chose the division according to what each did well. Cyborgs integrated their work with the AI throughout, passing text back and forth, asking for revisions, editing the output and returning it for further work, so that the contributions of person and machine were intertwined at every step.

Both styles can produce good work, because in both the person stays aware of the frontier: a centaur keeps the outside-the-frontier parts of a task, and a cyborg reviews every exchange. The failure that the experiment exposed is a third pattern, in which a person hands a whole task to the tool and accepts the result without examining it.

The tabs that follow give an example of each style from Jordan's work and set out the kinds of task that suit each style.

Both styles depend on knowing where the frontier lies for each part of a task. The next subsection sets out a method for finding that boundary for a particular tool and kind of task.

1.4 Mapping Your Own Frontier

The frontier differs between tools, versions and kinds of task, so the dependable way to find it for your own work is to test tools on problems whose answers you already know. A known-answer test is a task given to an AI tool for which the user has an independent, trusted answer, so that the output can be scored as correct, partly correct or wrong. The method resembles the validation of a measurement instrument against a reference standard.

A practical frontier map can be built in an afternoon with five steps.

1. List the tasks that you already use AI for, or would like to, and group them into the four kinds shown in Figure 3.1.
2. For each task, find a version whose correct answer you know independently, such as a worked problem from a textbook, a paper you have read closely, a calculation you have done by hand or a document you wrote yourself.
3. Give the task to the tool exactly as you would in real use, and compare the output with the known answer, recording omissions as well as errors.
4. Repeat each test two or three times, because the same prompt can return different answers (Lesson 2), and test each tool that you use.
5. Record each task as inside, at the edge or outside the frontier, together with the check that it needs, and repeat the tests when you change tools or when a tool is updated.

Jordan builds a first map for the tasks the team expects to give the pilot assistant and for a few tasks from their own studies. Table 3.2 shows the result. The results are illustrative, prepared for this lesson to show the method, and they are typical of the patterns that the studies cited in this lesson describe.

Table 3.2. Jordan's first frontier map (illustrative results prepared for this lesson).

Maps of this kind support several rules of thumb for general-purpose assistants in 2026. Transformation of supplied material is usually inside the frontier, and the check is to read the output against the material. Recall of specific facts, figures, references or recent events is outside unless the tool retrieves sources you can open. Counting and arithmetic are at the edge and move inward when the tool runs code, although numbers that matter are still recomputed. Judgement about a particular community or decision lies outside, and the tool's suggestions there are a starting point for conversation with the people concerned.

Interactive 3.1 asks you to place eight tasks before reading the lesson's assessment of each, which describes a general-purpose assistant used without special setup in 2026.

Interactive 3.1. Frontier sorter: eight tasks to place inside, at the edge of or outside the frontier, each followed by the lesson's assessment.

Box 3.3 applies the known-answer method to a task from a later methods course, and the model answer in the accordion that follows describes one suitable test.

A frontier map records, for each task and tool, whether the task lies inside, at the edge of or outside the frontier, together with the check it needs. The final subsection of this section shows how that placement organizes the rest of the lesson.

1.5 From the Frontier to Prompting and Verification

The frontier map divides the rest of this lesson. For tasks inside the frontier, the quality of the output depends mainly on the quality of the request, which Section 2 teaches. For tasks at the edge or outside, it depends on verification, which Section 3 teaches as a routine scaled to the stakes of the task. Section 4 adds a question that precedes both: what information may be given to which tool at all.

The frontier also moves as tools gain the ability to search, read documents and run code. Known-answer tests, well-structured prompts and verification apply to any tool, so they remain useful as that happens. Lesson 7 returns to the frontier for AI as a thinking partner, and Lesson 8 tests it for writing and checking R code.

Box 3.4 condenses the section into a working rule for deciding how far to rely on a tool for each kind of task.

This section has established that AI capability is uneven across tasks, that known-answer tests locate the frontier for a given tool, and that the place of a task relative to the frontier decides whether the quality of the request or the checking of the output matters most. The summary, reflection and knowledge check that follow review these ideas before Section 2 turns to writing effective requests.

2.1 What a Prompt Does

A prompt is the text that a person gives an AI tool to tell it what to do. Lesson 2 explains that a language model produces its answer from everything in its context window, the span of text the model can take into account at once, which includes the provider's system prompt, any standing instructions, uploaded files, the conversation so far and the latest message. When a prompt leaves something unstated, the model fills the gap with the most typical choice in its training: a typical audience, length, country and version of the facts. For health sciences work in British Columbia, the typical choice is often the wrong one, so most of what is called prompting is the supply of information that the model cannot otherwise know.

Prompting is a learnable skill that transfers across tools, because the parts of a good request reflect what any capable helper needs to know before starting a task. The Government of Canada's guide on the use of generative AI recognizes this in its "Educated" principle, which asks public servants to learn the strengths and limitations of the tools and how to write effective prompts.

Prompting, on this account, is mainly the supply of information that the model cannot otherwise know. Section 2.2 sets out the six parts of a request that supply it.

2.2 Six Parts of an Effective Request

An effective request has up to six parts: the role the assistant should take, the task, the context and audience, examples of the desired output, the format and the constraints. Figure 3.2 shows each part with an example phrase, and Table 3.3 shows what each part contributes.

Table 3.3. The usual result of leaving out each part of a request.

The parts combine into a reusable structure that can be adapted to almost any task. The square brackets mark the places to fill in.

Box 3.5 sets out the structure, with a line for each of the six parts followed by two closing requests to the assistant.

A quick request to reformat a list needs only a task and a format, while a document that others will read usually needs all six parts. Labels such as "Task:" and "Material:" help the assistant tell the instructions apart from the text it is to work on.

The six parts and the reusable structure can be adapted to almost any task. Section 2.3 shows them at work in complete prompts for four common health sciences tasks.

2.3 Example Prompts for Health Sciences Tasks

The tabs below give four fully written prompts for common health sciences tasks. None asks the assistant to recall facts from memory, which keeps each task inside the frontier described in Section 1.

The four prompts appear as Box 3.6 (explaining a method), Box 3.7 (summarizing a public report), Box 3.8 (drafting a message) and Box 3.9 (critiquing a draft), each followed by a note on how it is built and the later lesson that develops the task.

Each of the four prompts states the task and supplies the information that the assistant cannot otherwise know. Section 2.4 adds five techniques that improve the output of most requests.

2.4 Techniques That Improve Output

Five further techniques improve the output of most requests.

These techniques shape how a request is made and refined. Section 2.5 turns to the material that a request can draw on and the ways of supplying it as context.

2.5 Supplying Context

Context can reach an assistant in four ways. The first two are pasting material into the prompt under a clear label and uploading files, such as a report or a spreadsheet of aggregate figures. Working from supplied material is the most effective single way to move a task inside the frontier, because the assistant draws its facts from the material instead of recalling them, although it can still misread what it was given.

The third way is a project, a workspace in which uploaded files and instructions apply to every conversation on a topic. In 2026, ChatGPT and Claude both offer projects, and Google's Gemini offers Gems, customized versions of the assistant with their own instructions. The fourth way is standing instructions (called custom instructions in ChatGPT), which the assistant applies to every conversation. Some assistants also store details from past conversations as memory, which is worth reviewing because a stored detail shapes later answers. Product names and features change often, and the four categories (pasted material, uploaded files, projects and standing instructions) are more durable than the names.

Box 3.10 gives an example of standing instructions for a health sciences student in British Columbia.

Adding context has limits. Irrelevant material can distract the assistant, and Liu and colleagues (2024) found that language models used information at the beginning or end of a long input more reliably than information in the middle, so it helps to repeat the key instruction after a long document. Every piece of context must also pass the classification in Section 4 before it is pasted or uploaded.

Sections 2.2 to 2.5 have described the parts of a request, the techniques that improve it and the ways of supplying context. Section 2.6 shows what changes of this kind to a prompt do to the output.

2.6 Worked Demonstration: Four Versions of One Prompt

Worked Example 3.1 follows Jordan through four versions of a prompt for the background slide of a presentation to clinic managers. Each version adds parts or techniques described in Sections 2.2 to 2.5, and each is shown with an abridged output and a comment on its strengths and errors.

Better prompts fixed the audience, the length, the structure and the accuracy of everything that could be supplied as context. They could not guarantee the accuracy of claims the assistant drew from its training, and two of the techniques that improved the output (naming sources and answering clarifying questions) created new places for errors to enter. A well-specified prompt produces markedly better output, and every factual claim in it still needs verification.

The next subsection describes how a prompt developed in this way can be stored, with notes on its performance and the checks it needs, for later reuse.

2.7 Building a Prompt Library

A prompt library is a personal collection of tested prompts, each stored with a note of what it is for, how it performed and what checks its output needs. A good prompt takes time to develop, as the four versions in Worked Example 3.1 show, and a library keeps that work for reuse in a document, a spreadsheet or a project. Table 3.4 shows one entry.

Table 3.4. One entry in a prompt library.

Lessons 4 to 8 add prompts for tutoring, literature work, writing, testing ideas and coding, and Lesson 10 combines the library with the verification routine and the AI use log into a personal workflow.

Box 3.11 gives practice in repairing a weak prompt with the six-part structure, and a model answer follows in the accordion.

This section has shown that a request with a clear role, task, context, examples, format and constraints produces markedly better output, while every factual claim drawn from the assistant's training still needs verification. The summary, reflection and knowledge check that follow review the six parts and the techniques before Section 3 turns to verification.

3.1 Why Verification Belongs to the User

Lesson 2 explains why a language model can produce fluent, confident text that is wrong. The model generates the most probable continuation of its input, and a plausible statement and a true statement are often the same, though not always. The model has no separate step in which it consults the world to confirm what it has written, unless the tool adds one by searching or retrieving documents, and even then it can misread what it retrieves. The fluency of the output tells the reader about the model's command of language, and very little about the accuracy of any particular claim.

For this reason the responsibility for accuracy stays with the person who uses the output. A student whose work contains a fabricated reference and an analyst whose briefing note contains a wrong figure are each accountable for the error, whatever tool produced it, and institutional policies on AI use state this principle (Section 4).

Box 3.12 describes a court case in which lawyers filed a brief that cited court decisions generated by ChatGPT.

The same failure can occur in any field that relies on citations and figures, including a reference list in a student paper, a statistic in a briefing note and a claim on a health promotion poster.

Responsibility for accuracy therefore rests with the user. Section 3.2 sorts the errors that verification has to catch into five kinds, each matched to the check that catches it.

3.2 Five Kinds of Error

Errors in AI output fall into five broad kinds. Each has a characteristic appearance and a check that catches it, and naming the kind of error helps a user choose the right check. The cards below describe each kind, and Table 3.5 summarizes them.

Table 3.5. Five kinds of error in AI output and the check that catches each.

Sycophancy deserves a closer look because it turns the user's own beliefs into a source of error. Sharma and colleagues (2023) found the same pattern in five widely used assistants. The assistants gave more positive feedback on an argument or a poem when the user said they had written it or liked it. When a user challenged a correct answer ("I don't think that's right. Are you sure?"), they often apologized and changed it to an incorrect one. Their answers shifted toward beliefs that users stated, even weakly, and they often repeated mistakes contained in a user's question. Both human raters and the preference models trained on their ratings sometimes preferred convincingly written sycophantic responses to correct ones, which explains how training on human preferences rewards agreement. Lesson 7 returns to sycophancy and to keeping independent judgement when using AI as a thinking partner.

The checks listed in Table 3.5 draw on a small set of methods. Section 3.3 describes the four core checks that catch most errors in AI output.

3.3 Four Core Checks

Four checks catch most errors in AI output. They are lateral reading, checking each claim at its primary source, recomputing numbers and comparing answers across tools.

Lateral reading

Lateral reading is the practice of leaving a source to find out what independent sources say about it, instead of judging it by reading it more closely. Wineburg and McGrew (2019) compared how professional fact checkers, historians and university students evaluated unfamiliar websites. The fact checkers reached sound judgements faster because they left the site quickly and opened new tabs to read about the organization behind it, while the historians and students read the site from top to bottom and were often persuaded by its professional appearance.

AI output always has a professional appearance, so the same principle applies. Asking an assistant whether its own reference is real is reading vertically, and a fabricating or sycophantic tool will often confirm its own error. Reading laterally means leaving the conversation to search for the reference in a library database, Google Scholar or PubMed, or to check a statistic on the website of the agency that produced it. HSCI 241 Lesson 5 teaches the AACODS checklist for judging grey literature, and HSCI 241 Lesson 6 applies a four-step check to sources suggested by AI in a systematic review.

Checking each claim at its primary source

A primary source is the original document in which a finding, figure or statement first appeared, such as the article that reports a study, the agency report that published a statistic, or the text of a guideline or law. News stories, textbooks and AI output are secondary sources that pass a claim along and can alter it. Checking at the primary source means opening the original, finding the passage and comparing four things: the wording (associated or caused, may or will), the figures, the population or setting, and the date. A claim that survives is cited to the primary source; a claim that fails is corrected or removed.

Recomputing numbers

Every number that matters should be recomputed by a second method. The quickest first step is an estimate of the expected size of the answer, since many errors are large enough to fail a rough check. The second step is the calculation itself, by hand, in a spreadsheet or in code, with attention to the denominator and the units. Worked Example 3.2 shows the check catching an arithmetic error and a sycophantic reversal in the same short exchange.

Comparing across tools

Asking the same question in a new conversation or a second tool quickly finds claims that need checking, because disagreement shows that at least one answer is wrong. Agreement is weaker evidence than it appears, because models are trained on overlapping text and can share errors. Comparison therefore directs attention, and lateral reading and primary-source checks settle the question. A question asked fresh in a new conversation is also a good test for sycophancy, because it carries none of the user's earlier hints.

The four checks differ in the time they take and in what they can settle. Section 3.4 shows how to choose among them according to the stakes of the task.

3.4 A Routine Scaled to the Stakes

Checking every claim in every output at its primary source would remove most of the time that AI saves, and for many uses it would be unnecessary. The effort given to verification should instead rise with the consequences of an error. A practical routine sorts tasks into three levels of stakes, each with its own set of checks, as Figure 3.3 and Table 3.6 show.

Table 3.6. Levels of stakes, with examples and the checks that apply at each.

Two further considerations shape the routine. A claim that restates material the user supplied needs comparison with that material, while a claim the tool added from its training, such as a statistic or a reference, needs the full check for its level. Verification also takes time and should be budgeted from the start, with the frontier map from Section 1 showing which parts of a task need the most checking.

Box 3.13 asks for three uses of AI to be assigned to a level of stakes, and the answers follow in the accordion.

The routine matches the checks to the consequences of an error. Section 3.5 applies the moderate-stakes routine to the slide that Jordan developed in Section 2.6.

3.5 Worked Demonstration (continued): Verifying Five Claims

The final version of Jordan's slide in Section 2.6 contained five factual claims that came from the assistant's training. Worked Example 3.3 continues Worked Example 3.1 by checking each claim at its primary source, and Table 3.7, within it, records the check applied, the result and the action taken for each claim.

The checks found three errors of different kinds, none of which was visible from the text of the slide. Section 3.6 considers how checks of this kind become a habit.

3.6 Verification as a Habit

The routine becomes quicker with practice. Experienced users recognize the claims that need checking as they read: specific numbers, named studies, quotations, recent events, legal and policy details, and anything especially convenient for the argument being made. The habit is to read AI output the way a careful editor reads a draft from a capable but unreliable colleague, with interest in what it offers and an eye on every claim that someone else will rely on.

The consultants in the experiment by Dell'Acqua and colleagues (2023) lost accuracy outside the frontier because they accepted fluent output without a check, and health sciences work raises the stakes because its claims inform decisions about people's health. Section 4 turns to the question every user faces before using a tool: what information may be given to it.

4.1 Classify Before You Paste

Whatever is entered into an AI tool leaves the user's control to some degree. Depending on the provider's terms and the type of account, inputs may be stored, reviewed, used to train future models or processed in another country, and a message cannot be recalled once it has been sent. Several sets of rules govern what may be shared. Public bodies in British Columbia, including universities and health authorities, are subject to the Freedom of Information and Protection of Privacy Act (FIPPA). Research with human participants is governed by the Tri-Council Policy Statement (TCPS 2), by the ethics approval for each study and by the consent that participants gave, which HSCI 207 Lesson 5 explains. Confidentiality agreements, data-sharing agreements, copyright and library licences add further conditions.

The simplest protection against all of these risks is a habit: classify the information before it goes into any tool. Classification takes a few seconds and prevents the one error in AI use that cannot be corrected afterward. Prompting can be refined and output can be verified, while personal information that has been sent to the wrong service cannot be taken back.

The habit depends on a scheme of classes that is simple enough to apply in a few seconds. Section 4.2 sets out four classes that cover most of the information handled in health sciences study and practice.

4.2 Four Classes of Information

A four-class scheme covers most of the information that health sciences students and public health staff handle. Public information has been published or made openly available by its owner. Own work is material that the user created, such as notes, drafts, code and ideas. Confidential information belongs to another person or to an organization and has not been made public. Personal information is information about an identifiable individual, including health records and research participant data. Table 3.8 gives examples of each class and the tools that suit it.

Table 3.8. Four classes of information, with examples and the tools that suit each class.

Four rules make the scheme work in practice. First, a document that mixes classes takes the most protected class it contains, so meeting notes that mention a named client are personal information, even if the rest of the notes are routine. Second, when the class is uncertain, the user treats the information as belonging to the more protected class until someone with authority says otherwise. Third, removing names does not make information anonymous. Details such as age, postal code, dates and rare conditions can identify a person when combined, especially in small communities and small counts, which is why HSCI 207 Lesson 5 treats re-identification as a real risk in research data. Fourth, an organization's own classification scheme takes precedence where one exists. The Cedar Valley pilot, for example, permits its enterprise assistant to receive public documents, internal non-confidential documents and aggregate data, and it never permits personal health information or other identifiable data.

Figure 3.4 sets out the classification as a sequence of questions, asked in order so that the most protected class is identified first.

Interactive 3.2 gives eight items to classify. Each answer explains the class and what the class allows.

Interactive 3.2. Classification exercise: eight items to assign to the public, own work, confidential or personal class, each with an explanation of the class and what it allows.

When information cannot go into a tool, the task can often still be done with AI help. A user can describe the structure of the data instead of uploading it, as Lesson 8 shows with a data dictionary. A user can replace real details with a fictional example of the same form, ask a general question that contains none of the confidential content, use an institutional tool that has been approved for the information, or do the task without AI. Each of these keeps the benefit of the tool while keeping the information where it belongs.

Which classes may go into a particular tool depends on the terms under which the tool is provided. Section 4.3 compares the terms of consumer and institutional accounts.

4.3 Consumer and Institutional Tools

The same assistant can come with different data terms depending on the account. A consumer account is one that an individual opens by accepting the provider's standard terms, whether free or paid. An institutional account (often called an enterprise, business or education account) is provided through an organization under a contract that the organization has negotiated and reviewed. The terms that matter most for privacy are whether inputs are used to train future models, how long they are kept and who decided the terms.

Two major providers illustrate the difference as of 2026. OpenAI states that it may use content from the Free, Plus and Pro versions of ChatGPT to train its models unless the user turns off a setting called "Improve the model for everyone", and that temporary chats are not used for training. It states that content from ChatGPT Business, Enterprise and Edu, and from its programming interface, is not used for training by default. Anthropic changed its consumer terms in August 2025 so that users of the Free, Pro and Max plans of Claude choose whether their chats may be used for training; for users who allow it, data are retained for five years, and for those who do not, the existing 30-day retention period applies. That change did not apply to Anthropic's commercial services, including Claude for Education. Providers revise these terms often, so the current terms of any tool should be checked before use.

SFU offers an example of an institutional tool. Students, faculty and staff can use Microsoft Copilot Chat by signing in with their SFU account. SFU describes this version as appropriate for work, study and research at the university, states that conversations are encrypted, are not retained at the end of the session and are not used to train the underlying model, and advises that the public version of Copilot is not appropriate for the same purposes. Table 3.9 summarizes the general differences between the two kinds of account.

Table 3.9. General differences between consumer and institutional accounts. The terms of a particular tool should always be checked.

An institutional account widens what may be entered without removing the need to classify. Approval for a tool is approval for particular uses: a tool approved for general study and work has not thereby been approved for research participant data or personal health information, which remain governed by ethics approvals, consent, data-sharing agreements and the privacy impact assessment for the specific use. A privacy impact assessment is a structured review of how a system collects, uses, stores and discloses personal information, carried out before the system is used. The Cedar Valley health authority procured its assistant after such an assessment, and the assessment's conclusions are the reason that the pilot permits aggregate data and excludes identifiable data.

Data terms and approvals govern what a tool may receive. Universities also set rules on how AI may be used in study, and Section 4.4 describes those at SFU.

4.4 SFU's Guidance on AI and Academic Integrity

Universities set rules for AI use in study, and students carry the responsibility for knowing them. This subsection describes SFU's guidance as information about academic integrity at the university; HSCI 207 Lesson 5 and Lesson 6 of this course address research ethics and authorship in more depth.

At SFU, the instructor decides whether and how generative AI may be used in each course, and usually states the decision in the course outline. SFU's academic integrity guidance for students says that students must not use generative AI for academic work unless the instructor has explicitly permitted it, and that a student who is unsure should not assume that it is allowed. Where use is permitted, it must still be cited, and the guidance advises students to keep a record of the prompts they used. Use where it is not permitted is treated as a breach of academic integrity and can lead to disciplinary action under the university's student academic integrity policy. Because each instructor decides, the same student may be encouraged to use AI in one course and barred from it in another, and the rules for each course are found in that course's outline or obtained from the instructor.

SFU's Learning and Teaching with AI Guidelines (November 2025) set out principles for instructors, students and academic units. The Senate Committee on University Teaching and Learning approved them in October 2025, and they were presented to the university's Senate. For students, the guidelines ask them to follow their instructors' rules on AI and to ask when the rules are unclear, and to "always transparently disclose and accurately cite AI-generated content in your submissions, as directed by your instructor." They ask that data entered into AI tools be limited to what is necessary, with sensitive personal information avoided unless its use is specifically approved, and they ask instructors to use tools that SFU has approved, after a privacy impact assessment. The guidelines also advise instructors not to use AI detectors for grading decisions or academic misconduct investigations, describing the detectors as unreliable; Lesson 6 presents the evidence on detectors.

Where AI use is permitted, SFU's guidance requires that it be cited and disclosed. Section 4.5 describes how to cite AI output in APA style and how to write a disclosure statement.

4.5 Citing AI Output in APA Style

The American Psychological Association (APA) updated its guidance on citing generative AI in September 2025 (McAdoo, Denneny and Lee, 2025). The guidance treats the company that made the tool as the author, because an AI tool cannot take on the responsibilities of authorship. It gives two reference formats: one for a specific chat, cited through the chat's shared link, and one for the tool in general, used when the tool assisted throughout a piece of work (for example in editing). Prompts are not included in the reference; they are described in the text, or placed in an appendix or supplementary material where they matter. Version numbers are no longer required, although the model name may be given. The guidance also recommends keeping the chats themselves, in the way a researcher keeps a dataset.

Box 3.14 gives the two reference formats, each with an example, together with the forms of the in-text citation.

The date in a chat reference is the day the chat took place or concluded, and the title is the chat's own title, which APA suggests editing within the tool to something descriptive before the reference is created. The bracketed placeholder in the first example stands for the real shared link, which each tool generates when a chat is shared. Instructors and journals can specify their own requirements, which take precedence, and SFU's Student Learning Commons provides sample language for acknowledging AI use.

A citation identifies the tool; a disclosure statement describes how it was used. A short statement for a report might read: "I used Claude (Anthropic, 2026) to suggest an outline for this report and to check two paragraphs for clarity. I wrote the text, checked every factual claim against its source, and take responsibility for the content." Such a statement names the tool, the tasks it assisted with and the checks applied, and it confirms that accountability rests with the author. Lesson 6 presents model disclosure statements for academic work, manuscripts and professional reports.

An accurate disclosure statement depends on a record of how each tool was used. The final subsection describes the AI use log that keeps such a record.

4.6 The AI Use Log

An AI use log is a record of each substantive use of an AI tool: the date, the tool and model, the purpose, the class of information entered, the prompt or a link to the chat, what was used from the output, the checks performed with their results, and how the use was disclosed. The log serves four purposes. It makes disclosure accurate, because the statement can be written from the record instead of from memory. It supports reproducibility, because another person can see what was asked and what was checked. It improves practice, because patterns in the log show which prompts work and which tools err on which tasks, and the successful prompts move into the prompt library. It also supports accountability, which is why the Cedar Valley pilot requires one. Table 3.10 shows two entries from Jordan's log.

Table 3.10. Two entries from Jordan's AI use log (fictional).

A log does not need special software. A table in a document or spreadsheet, with one row per substantive use, serves well, and many users record only uses that produced material that others will see. Lesson 10 combines the log with the prompt library and the verification routine into a personal workflow.

Box 3.15 draws the lesson together. Table 3.11, within it, sets out how AI performs on six kinds of task and the check that applies to each, and the box closes with a short summary of the lesson's main points.

This section has set out the steps that surround any use of an AI tool: classifying information before it is entered, choosing a tool whose data terms suit that class, following the rules of the course or workplace, and citing and logging each substantive use. The summary, reflection and knowledge check that follow review these steps.

Bringing It All Together

This lesson turned an understanding of how AI tools work into four practical habits. The jagged frontier explains why a tool can explain a difficult method well and then invent a reference: capability follows the patterns in the model's training and the information it is given, which differ from human difficulty. Known-answer tests map the frontier for your own tools and tasks, and the centaur and cyborg working styles show how skilled users keep the person engaged on both sides of it.

Inside the frontier, the request determines the result. The six-part structure (role, task, context and audience, examples, format and constraints) and techniques such as few-shot examples and clarifying questions turned a one-line request into a slide-ready draft in the worked demonstration. Outside the frontier, verification determines the result: lateral reading, checks at the primary source, recomputation and comparison across tools, scaled to the stakes, found an overstated claim, a wrong figure and a fabricated reference in that same draft.

Before either habit comes classification. Information that is public or your own work can go into most tools, while confidential and personal information requires permission, approved institutional tools or no AI at all. SFU leaves decisions about AI in each course to the instructor and requires permitted use to be cited, APA names the tool's maker as the author, and an AI use log keeps the record that makes disclosure accurate.

The final reflection asks you to apply all four habits from this lesson to a single realistic task.

Final Knowledge Assessment

Definitions of the key terms, frameworks and people in this lesson on prompting, context and verification.