Claude Certified Associate (CCAO-F): Complete Exam Prep

How Claude Actually Works (and Why It Matters)

Lecture Overview

This lecture explains the mechanics behind Claude and why understanding them changes how you work with it. People naturally expect an AI assistant to know current facts and to remember previous conversations. By default it does neither. Claude is a large language model that predicts the most likely next words from patterns learned during training, working only from what is in front of it right now.

What You Will Learn

• Understand that Claude predicts likely next words from learned patterns rather than looking information up

• Recognise that every new chat starts blank, with no memory carried across conversations

• Understand the training cutoff and why recent events are absent unless supplied or searched

• Explain why hallucinations occur when a knowledge gap is filled with something plausible

• Identify why confident, fluent phrasing is not evidence of accuracy

• Apply the practical rule that you must supply the context Claude works from

Topics Covered

• Expectations versus reality: knowing and remembering

• Next-word prediction and pattern matching

• The improviser analogy: a fresh stage with no script

• Blank chats and the absence of cross-conversation memory

• Training data cutoff and its consequences

• Hallucination: how plausible gaps get filled

• Why vague, open-ended prompts produce weak results

• Bringing context through documents, links and clear goals

Practical Takeaways

If Claude cannot access the internet, questions about today's news will produce invented answers rather than an admission of ignorance. Starting a new chat resets the context entirely unless you re-supply it through pasted material, files or a Project. Because the model completes patterns rather than retrieving facts, the quality of what you provide — documents, specifics, and a clearly stated goal — directly determines the quality of what comes back.

Summary

Understanding that Claude has no script and no memory, and that you set the table, is the single idea that makes every later technique in this course make sense.

The Claude Family — Fable, Opus, Sonnet and Haiku

Lecture Overview

This lecture introduces the four current Claude models and explains how to choose between them. A single model cannot suit every task: an oversized model on a small job wastes time and money, while an undersized model on a hard job returns a shallow answer. Using the analogy of choosing a vehicle for a trip, the lecture maps each model to the kind of work it is built for and closes with a look at the official pricing page.

What You Will Learn

• Understand why model choice is a trade-off between capability, speed and cost

• Identify Fable as the most capable option for the hardest and longest jobs

• Understand where Opus fits for demanding reasoning and complex problems

• Recognise Sonnet as the balanced everyday workhorse for most professional tasks

• Apply Haiku to simple, high-volume work such as tagging and short replies

• Learn a practical rule of thumb for stepping up or down between tiers

• Verify current model pricing on the official documentation rather than relying on memory

Topics Covered

• Why one model cannot fit every task

• The vehicle analogy: jet, sports car, sedan and scooter

• Fable — highest capability, highest cost, slowest response

• Opus — deep reasoning for hard problems

• Sonnet — the balanced choice for daily drafting, summarising and light coding

• Haiku — fastest and cheapest for simple, high-volume jobs

• Comparing capability, speed and cost across the tiers

• Checking the official pricing page for current figures

Practical Takeaways

Start with Sonnet, which handles roughly nine out of ten everyday tasks such as emails, small presentations, HTML pages and documents. Step up to Opus when quality falls short on genuinely hard problems, and reserve Fable for exceptional work where nothing less will do — noting that it is both the most expensive and the slowest. Step down to Haiku for simple, repetitive, high-volume work. Because versions and prices change, treat the tiers as stable and confirm the current numbers on the official site.

Summary

You will leave this lecture able to match a task to the right model tier and to justify that choice on capability, speed and cost.

What Claude Can Do — Extended Thinking, Tool Use and Artifacts

Lecture Overview

Most people use Claude as a plain chat box: ask, copy the reply, move on. This lecture surveys the four capabilities that sit unused behind that habit — extended thinking, web search, Artifacts, and file and image analysis — and gives a simple guide for reaching for the right one at the right moment. Each capability is explored in greater depth later in the course.

What You Will Learn

• Understand extended thinking and how step-by-step reasoning improves difficult answers

• Recognise that thinking depth affects both answer quality and token usage

• Learn how web search supplies current information instead of guesses from training data

• Explore Artifacts as editable documents, code and visuals that open beside the chat

• Apply file and image analysis to PDFs, spreadsheets, documents and photos

• Match a given need to the correct capability using a simple decision guide

Topics Covered

• The limits of treating Claude as a plain chat box

• Extended thinking and visible reasoning

• Thinking levels and their effect on cost and output

• Web search and current information

• Artifacts as an editable workspace beside the conversation

• Uploading files and images for analysis and summarisation

• A quick reference: which feature to use for which need

• Other Claude surfaces introduced later in the course

Practical Takeaways

Use extended thinking for tricky problems that need careful reasoning, enable web search for anything recent, use Artifacts when the output is something you will keep editing, and upload the file when the answer must come from your own material. Knowing the toolkit exists is what stops Claude being used as a slightly better search box.

Summary

This lecture gives you a working map of Claude's core capabilities so you can select the right one deliberately rather than by habit.

Working With Claude — Surfaces, Models and Context

Lecture Overview

This lecture turns everything learned so far into three practical habits: choosing where you work, choosing which model fits, and keeping the session context clean. Context management matters more than most people expect, because a cluttered conversation consumes tokens quickly and dilutes the quality of the answer. The lecture covers the surfaces Claude lives on, the four model tiers, and the whiteboard analogy for the context window.

What You Will Learn

• Ask three orienting questions before every session: where, which model, and how to stay sharp

• Identify the five Claude surfaces and recognise which two matter for everyday work

• Distinguish the general-purpose web app from a persistent Project workspace

• Match the four model tiers to task difficulty, stakes, speed and cost

• Understand the trade-off between quality, speed and cost when selecting a model

• Explain the context window and how long conversations degrade responses

• Apply three habits: start fresh, feed only what is relevant, and let Projects remember

Topics Covered

• The three questions to ask every session

• One chef, many venues: matching the setting to the job

• Five front doors: claude.ai, Projects, the API, Claude Code and Claude for Chrome

• The two everyday doors for non-developers

• The four model tiers and what each is built for

• Fast, cheap, good — the trade-off you cannot avoid

• The whiteboard analogy and the context window

• Starting a new chat for a new task

• Supplying only relevant material

• Using Projects so context is loaded once

Practical Takeaways

Think in tiers rather than version names, because versions change while the roles stay stable. When a new task has no dependence on the previous conversation, start a fresh chat — long threads slow responses, raise cost and increase the chance of drift. Load files and standing instructions into a Project once so every conversation there begins already informed. Door, model, clear board: the same three moves every session.

Summary

You will finish this lecture with a repeatable working routine for choosing a surface, selecting a model, and keeping context clean.

The Four Entry Points — Chat, Projects, Artifacts and Research

Lecture Overview

Most people simply start typing, then re-explain the same context in one endless conversation while the actual deliverable is lost in the scroll. This lecture demonstrates the four entry points inside Claude — Chat, Projects, Artifacts and Research — and shows each one live in the interface, so that choosing the right room becomes a deliberate decision made before the first prompt.

What You Will Learn

• Understand that selecting an entry point is a decision made before prompting begins

• Use Chat for quick, one-off questions and lightweight edits

• Create and configure a Project with a name, custom instructions, files and folders

• Recognise how Artifacts open a deliverable beside the conversation for editing and sharing

• Use Research mode to run a multi-source investigation and receive a cited report

• Identify which capabilities depend on a paid plan

• Understand where connectors fit alongside these entry points

Topics Covered

• Differences between free and paid plan availability

• Chat as the lightweight default

• Projects: instructions, files, folders and scheduling

• Artifacts: building a small site or document from a prompt

• Research mode: multi-source investigation and reports

• Connectors available during research

• The Claude desktop application and other surfaces

• A decision guide matching task types to entry points

Practical Takeaways

Recurring work that reuses your own files and rules belongs in a Project, not in a fresh chat each time. Anything you intend to keep editing is better produced as an Artifact than buried in conversation. Research is the right choice when a question needs several sources synthesised rather than a single-turn answer. The desktop application is recommended for a more stable working experience than the browser.

Summary

By the end of this lecture you will be able to name the correct entry point for a given task — a judgement the exam tests directly.

The Capability Layer — Skills, Code Execution and Memory

Lecture Overview

Plain chat has three blind spots: the same task comes out differently each time, numbers can sound certain without being verified, and everything is forgotten when the conversation ends. This lecture introduces the three capabilities that close those gaps — Skills, Code Execution and Memory — explains which problem each one solves, and shows how they can be combined. Each is demonstrated live in the lectures that follow.

What You Will Learn

• Identify the three weaknesses of plain chat that the capability layer addresses

• Understand Skills as reusable instruction sets that make repeated work consistent

• Learn how Code Execution runs real code in a sandbox to verify numeric work

• Understand Memory as facts that persist across sessions and require occasional curation

• Match a stated problem to the correct capability

• Recognise how Skills, Code Execution and Memory stack within a single Project

• Apply a trust and permissions review before using third-party Skills

Topics Covered

• Inconsistency, unverified math and forgetfulness in plain chat

• Skills as reusable procedures and their real-world uses

• Code Execution for calculations, transformations, charts and downloadable files

• Memory for facts that should survive the next session

• Scoping memory per Project to keep separate work separate

• Combining capabilities for compounding benefit

• Exam-relevant distinctions between the three capabilities

• Third-party Skills and trust considerations

Practical Takeaways

When an answer is numeric, transformed, charted or downloadable, Code Execution is the trustworthy route rather than an unverified estimate. When consistency across repeated outputs matters — a house presentation style, for example — build or use a Skill. When facts such as names, preferences or project details should carry forward, use Memory, and scope it per Project so unrelated work never mixes. Skills reduce variance but do not remove the need to review the output.

Summary

This lecture gives you a clear decision rule: name the problem, and the capability picks itself.

Hands On — Enabling Code Execution and File Creation

Lecture Overview

This hands-on lecture enables the Code Execution and File Creation capability and puts it to work on a real spreadsheet. Working from a sample monthly sales file, Claude calculates variance against target, identifies the months that missed, builds a chart and produces a formatted Excel file that can be downloaded and opened locally. The same settings and workflow apply in both the web app and the desktop application.

What You Will Learn

• Locate the capability settings and enable Code Execution and File Creation

• Upload a spreadsheet as context for an analysis task

• Write a prompt that specifies the calculations, the output format and the deliverable

• Understand the difference between running a task in chat and running it autonomously

• Review a generated chart and a formatted Excel output

• Open and verify the downloaded file in a local spreadsheet application

Topics Covered

• Customization settings and the capability panel

• Enabling code execution and file creation

• Attaching a data file to a conversation

• A worked prompt: variance, percentage variance, annual total and shortfalls

• Chat versus autonomous execution of a multi-step task

• Generated charts and formatted Excel output

• Downloading results and opening them locally

• Connectors as an alternative destination for generated files

Practical Takeaways

File creation only produces downloadable deliverables when the capability is enabled first, so check settings before assuming a limitation. A precise prompt that names every required calculation and the exact output format removes most follow-up rounds. Because the analysis runs as real code rather than as estimation, the resulting figures are verifiable rather than guessed.

Summary

You will finish this lecture able to turn a raw spreadsheet into a verified, formatted, downloadable analysis in a single pass.

Hands On — Adding and Using Skills

Lecture Overview

This lecture demonstrates the full lifecycle of a Skill: where Skills live in the interface, how to browse the ones provided by Anthropic, how to add your own, and how to invoke one in a conversation. A meeting-recap Skill is created from scratch and then run against a sample transcript, showing how a well-written Skill removes the need to re-prompt for the same structure every time.

What You Will Learn

• Find the Skills panel inside the customization settings

• Browse and enable Skills provided by Anthropic

• Understand that Claude may apply a relevant Skill even without an explicit instruction

• Create a Skill by writing instructions directly or by uploading a file

• Recognise the SKILL.md markdown format used to define a Skill

• Invoke a Skill in a chat and apply it to real source material

• Combine a Skill with code execution to produce a downloadable deliverable

• Adjust model and effort settings to match the weight of the task

Topics Covered

• Where Skills live and how they are listed

• Browsing built-in Skills

• Community and third-party Skills published as repositories

• The SKILL.md file and markdown format

• Creating a Skill by name, description and instructions

• Running a meeting-recap Skill on a transcript

• Producing a downloadable text file from the result

• Choosing an appropriate model and effort level for simple tasks

Practical Takeaways

A Skill turns a repeated instruction set into something you invoke once, so the output shape stays consistent without re-explaining it. Skills are plain markdown files, which makes them easy to read, adapt and share. Pair a Skill with code execution when the result should leave the chat as a file, and match the model tier to the difficulty of the work rather than defaulting to the most powerful option.

Summary

After this lecture you will be able to add, write and run Skills, and to recognise when a task deserves one.

Hands On — Memory, Curation and Incognito

Lecture Overview

This lecture covers the three controls that determine what Claude retains about you: incognito chats, memory, and curation. It shows how to start a conversation that leaves no history, how to enable and populate memory — including importing context from another AI tool — and how to review, add, delete, pause or reset stored memories so they stay accurate and appropriate.

What You Will Learn

• Start an incognito chat when a conversation should not be saved

• Enable memory and understand how it improves continuity across chats

• Import existing context from another AI tool using the provided prompt

• Review how memories are grouped into areas and drawn on in relevant chats

• Curate memory by adding useful facts and deleting entries you no longer want

• Pause or reset memory entirely when circumstances require it

• Judge when memory is appropriate and when it should be avoided

Topics Covered

• Incognito chats and unsaved history

• Locating memory settings in customization

• Enabling memory and importing prior context

• Memory areas and how they are recalled

• Adding and deleting individual memories

• Pausing and resetting stored memory

• Web application and desktop application parity

• Sensitivity considerations when deciding to use memory

Practical Takeaways

Memory improves output quality over time because Claude stops needing the same background repeated, but it must be curated to stay correct. Incognito is the right choice for a conversation that should leave no trace. If your work regularly involves sensitive material, weigh that carefully before enabling memory at all — and remember that a reset clears everything stored.

Summary

This lecture leaves you in full control of what Claude remembers, what it forgets, and what it never records.

Chat Deep Dive — Getting More From a Conversation

Lecture Overview

Chat looks simple, but the controls surrounding it change the quality, cost and currency of every answer. This lecture walks through the chat interface in detail: attaching files and images, invoking Skills, enabling or disabling web search, selecting a model, adjusting effort and thinking, using dictation and voice, and working with the response controls that follow each answer.

What You Will Learn

• Attach files, images and screenshots, and save a conversation into a Project

• Invoke a Skill directly from the message box

• Enable or disable web search and understand its effect on currency of information

• Select a model and understand which models a given plan makes available

• Adjust the effort setting and understand its impact on quality, speed and token use

• Enable or disable thinking depending on task complexity

• Use the response controls: copy, read aloud, feedback and retry

• Request sources for claims made during a conversation

Topics Covered

• Attachments, screenshots and saving a chat to a Project

• Skills invoked from within a chat

• Connectors and plugins as more advanced topics covered later

• Research mode and search mode toggles

• Model selection and plan-based availability

• The effort setting and the effort/model combination

• Thinking on and off, and when each is appropriate

• Dictation and voice modes

• Copy, read aloud, feedback and retry controls

• Asking for sources when web search is enabled

Practical Takeaways

Model and effort work as a pair: a mid-tier model at high effort can outperform a stronger model set to low effort, though higher effort consumes more tokens. Turn thinking off for speed and economy on simple work, and on for complex problems where quality would otherwise suffer. If a question depends on current information, confirm web search is enabled and ask explicitly for sources.

Summary

After this lecture the chat interface stops being a text box and becomes a set of deliberate controls you tune to the task.

Research Mode End to End

Lecture Overview

This lecture demonstrates Research mode from prompt to published document. Research runs a deeper, multi-source investigation than a normal conversation, checking and re-checking sources along the way. The lecture walks through enabling research, choosing sensible model and thinking settings, running a real briefing request, and then copying, downloading or publishing the finished result.

What You Will Learn

• Enable Research mode and recognise the settings that support it

• Choose an appropriate model and enable thinking for a research task

• Write a research prompt that names the topic, the deliverable and the length

• Understand why research takes longer and consumes more resources than a normal chat

• Review the sources gathered during the investigation

• Export the result by copying, downloading as PDF or markdown

• Publish a research output and share it as a publicly accessible link

Topics Covered

• Enabling research from the input menu

• Model and thinking choices for research tasks

• Writing a research prompt with a defined deliverable

• Declining unnecessary connector access for a task

• Multi-source gathering and repeated verification

• Reviewing the finished, formatted output

• Copy, PDF and markdown export options

• Publishing an artifact and testing the public link

Practical Takeaways

Research is the right entry point when an answer needs several sources synthesised and verified rather than a single-turn reply — and it is correspondingly slower and more expensive. Specify the deliverable and length in the prompt so the output arrives in the form you need. Published research is publicly accessible to anyone with the link, which is worth verifying before sharing.

Summary

You will finish this lecture able to run a research task end to end and turn the result into a shareable document.

Artifacts End to End — Build, Iterate and Share

Lecture Overview

This lecture builds Artifacts from scratch and follows them through to publishing. Starting from the Artifacts panel and its starter categories — productivity tools, games, documents, apps and websites, creative projects and quizzes — it creates a small game and a personal website, compares how the same work behaves in the browser versus the desktop application, and demonstrates downloading, publishing and sharing the result.

What You Will Learn

• Create a new Artifact from a starter category or from scratch

• Write a prompt that describes a small application clearly enough to build

• Choose a stronger model and higher effort for genuinely complex builds

• Understand why the desktop application handles background and parallel work better

• Run several pieces of work at once across different entry points

• Download, publish and share a finished Artifact

• Recognise how sharing differs between individual and organisational plans

Topics Covered

• The Artifacts panel and its starter categories

• Building a simple game as an Artifact

• Building a personal website from supplied profile information

• Effort, model and thinking settings for complex builds

• Browser limitations with background processing

• Multitasking in the desktop application

• Downloading and publishing Artifacts

• Public links versus organisational sharing

Practical Takeaways

Artifacts let non-developers produce small, usable tools and sites without writing code. Complex builds such as games benefit from a stronger model with high effort and thinking enabled, while simpler documents do not. The browser app can lose background work when you navigate away, so prefer the desktop application for long-running builds. Publishing an Artifact makes it publicly reachable, so check the sharing scope before distributing the link.

Summary

This lecture takes you from an empty Artifact panel to a working, published, shareable deliverable.

Projects End to End — Real Workspace Walkthrough

Lecture Overview

This lecture builds a complete Project from an empty workspace to a shareable assistant. Using a hypothetical people-operations scenario, it adds custom instructions covering grounding, source citation, tone and sensitivity; loads company documents such as a handbook, leave policy and benefits guide as project knowledge; then answers real employee questions from that knowledge base and finally turns the whole thing into a published Artifact.

What You Will Learn

• Create a Project with a clear name, description and purpose

• Write custom instructions that govern grounding, citation, tone and escalation

• Add documents to project knowledge and understand why context beats per-chat uploads

• Ask realistic questions and observe answers being grounded in supplied files

• Choose a lighter model when the task is simple lookup against known documents

• Share or pin a Project so a team can use it

• Generate a publishable Artifact from an existing Project

• Understand access differences between logged-in and anonymous visitors

Topics Covered

• Creating a Project in the web app versus attaching folders in the desktop app

• Custom instructions: grounding, sourcing, tone, sensitivity and escalation contact

• Uploading files into project knowledge

• Files in context versus files attached to a single chat

• Answering policy questions from project documents

• Model selection for straightforward retrieval tasks

• Sharing a Project via a link

• Turning project content into a published Artifact

• Constraints and disclaimers on shared artifacts

Practical Takeaways

Custom instructions define behaviour while knowledge files supply reference material — the two roles are distinct and the exam tests that distinction. Loading documents into project context, rather than re-attaching them to every conversation, is what makes a Project worth creating. Instructions such as always cite the source and never give legal or medical advice give an internal assistant guardrails before anyone uses it.

Summary

By the end of this walkthrough you will be able to design, populate, test and share a working Project rather than merely describe one.

Claude Code and Claude for Chrome — A Quick Overview

Lecture Overview

This lecture gives a deliberately brief overview of two developer-oriented surfaces so that you can recognise them without needing to use them. Claude Code behaves much like a Project whose subject matter is a software codebase, working against a repository or folder. Claude for Chrome operates in the browser and can act on the page in front of it, which makes it useful for testing, checking and debugging web pages.

What You Will Learn

• Understand Claude Code as a project-style workspace for software development

• Recognise how a repository or local folder becomes the working context

• Identify scheduled routines and remote dispatch as additional Claude Code features

• Understand what the Chrome extension does and how it reads the current page

• See a practical browser example such as measuring page load performance

• Judge which surfaces an associate-level user needs and which are for developers

Topics Covered

• Claude Code as a project for code

• Adding a repository or folder as context

• Publishing small applications from code

• Scheduled routines and dispatch

• The Claude browser extension and signing in

• Acting on the current page: performance and page checks

• Typical developer uses such as testing and debugging

• Why these surfaces sit outside everyday associate-level work

Practical Takeaways

Claude Code and the browser extension are recognition-level knowledge for this course: know what each one is for, and know that neither is required for day-to-day non-developer work. The browser extension is notable because it can observe and act on a live page rather than only on text you paste in.

Summary

This short lecture ensures you can identify Claude Code and Claude for Chrome correctly without spending study time you do not need to spend.

Customization — Styles, Preferences and Personal Setup

Lecture Overview

This lecture covers the account-level settings that quietly shape every conversation. It walks through language selection, profile details such as what Claude should call you and what you do, general guidelines that apply across all chats, appearance and accessibility preferences, voice settings, and the account controls covering sessions, privacy, data export, memory and usage.

What You Will Learn

• Set your preferred language so Claude communicates in it consistently

• Complete profile details including name, role and area of work

• Write general guidelines that apply across every conversation

• Adjust appearance settings such as theme, font and reduced animation

• Configure voice language, style and speed

• Manage sessions, including signing out of all devices

• Locate privacy settings, data export, file management and memory preferences

• Review billing and usage information

Topics Covered

• Language preferences

• Account profile: name, role and context

• General guidelines applied to all chats

• Appearance: theme, font size and animation

• Voice and notification settings

• Session management and account deletion

• Privacy settings and data export

• Managing files and memory preferences

• Billing and usage visibility

Practical Takeaways

General guidelines are a low-effort, high-leverage setting: a single instruction such as maintaining a professional tone applies everywhere without being repeated in each prompt. Profile details help Claude pitch answers at your field. The remaining settings govern privacy, data and access, which are worth reviewing once rather than discovering later.

Summary

After this lecture your account will be configured so that every conversation starts closer to what you actually want.

Claude Design — Slides, Prototypes and One-Pagers

Lecture Overview

Claude Design opens as a separate workspace focused on visual output, particularly presentations. This lecture, presented as good-to-know material rather than examinable content, shows how a design system is configured with logos, fonts, assets and reference files so that generated slides follow a consistent house style, and how the finished deck can be exported or shared.

What You Will Learn

• Understand what Claude Design is and that it operates as a separate beta workspace

• Explore prebuilt templates as a starting point

• Configure a design system using logos, fonts, assets and reference documents

• Supply existing presentations or PDFs so the design language can be matched

• Generate a short presentation from a simple prompt

• Export the result as an Artifact, PDF, Google Slides or PowerPoint

Topics Covered

• Opening Claude Design and its beta status

• Templates and starting points

• Creating a design system

• Uploading brand assets, fonts and reference files

• Generating slides that follow a configured style

• Model selection for design tasks

• Export and sharing options

Practical Takeaways

A configured design system is what makes generated decks look like yours rather than generic — the same prompt produces very different output depending on the assets and reference material supplied. Export options cover Artifacts, PDF, Google Slides and PowerPoint, so the result fits existing workflows. This is a capability worth experimenting with, though it sits outside the associate exam scope.

Summary

This lecture shows how presentation work can be produced to a consistent visual standard, and marks clearly where it falls outside exam requirements.

Scheduled Tasks — Letting Claude Work on a Schedule

Lecture Overview

Scheduled tasks let Claude perform work automatically on a recurring basis. This lecture creates a task end to end: scanning the web each morning for AI news, updating an Artifact with the results, and keeping an archive so previous days remain viewable. It also shows where scheduled tasks are managed afterwards and discusses other practical use cases.

What You Will Learn

• Create a scheduled task and let Claude help define it

• Write a task description that specifies the work, the output and the frequency

• Combine scheduled execution with an Artifact that updates over time

• Include archiving so historical results remain accessible

• Review, locate and manage scheduled tasks after creation

• Understand the practical conditions required for a schedule to run

• Recognise other use cases such as recurring document generation or connector-based updates

Topics Covered

• Creating a new scheduled task

• Describing the task and answering clarifying questions

• Combining scheduling with Artifacts

• Archiving results by date

• Where scheduled tasks appear once created

• Pinned artifacts and repeat access

• Practical conditions for automated runs

• Other use cases, including connector-driven workflows

Practical Takeaways

Scheduling turns a repeated manual request into standing infrastructure — the value comes from combining it with an output surface such as an Artifact so results accumulate somewhere you can return to. Build archiving into the task description from the start, since retrofitting history is harder than planning for it. Sharing an automatically updated artifact with colleagues depends on your plan and team setup.

Summary

This lecture moves you from asking Claude for things to having Claude deliver them on a schedule without being asked.

Anatomy of a Good Prompt

Lecture Overview

A vague request produces a vague answer. This lecture breaks a strong prompt into five parts — Role, Context, Task, Format and Examples — and shows how each one changes the output. It uses the analogy of briefing a capable new hire: the person is talented, but they still need to know who to be, what the background is, what the job is, and what finished work should look like.

What You Will Learn

• Understand why open-ended requests return generic, unusable output

• Apply the five parts of a prompt: Role, Context, Task, Format and Examples

• Use Role to set voice and expertise for the answer

• Supply the background facts the model could not otherwise know

• State one clear task rather than a vague verb such as help with

• Specify format including length, tone and structure to avoid extra revision rounds

• Use an example to pin a voice that adjectives cannot capture

• Select only the parts a given job actually requires

Topics Covered

• Vague prompts and generic results

• The new-hire brief analogy

• Role — who the model should be

• Context — the background it needs

• Task — the single clear job

• Format — length, tone and structure

• Examples — showing rather than describing

• Before and after: the same task with and without the five parts

• Matching prompt depth to task stakes

• Worked examples using two, three and all five parts

Practical Takeaways

The five parts are a checklist to reach for, not a form to complete. A quick ask often needs only task and format; a piece someone else will read usually wants role, task and format; high-stakes or repeated work justifies all five. When a long conversation is already carrying context, later prompts can be much shorter. A good prompt is not longer — it is clearer, and it names the deliverable precisely.

Summary

You will leave this lecture able to construct prompts deliberately and to judge how much structure a given task actually deserves.

Giving Context and Examples (Few-Shot)

Lecture Overview

This lecture focuses on the two moves that most improve output quality: supplying context the model could not know, and showing one or two worked examples. Few-shot prompting works the same way as handing a new colleague three finished reports before asking for the fourth — the pattern is absorbed instantly, without a paragraph of rules.

What You Will Learn

• Recognise why a request with no context returns interchangeable, generic writing

• Supply context covering audience, product and goal

• Apply few-shot prompting using one or two input-to-output pairs

• Understand why concrete examples outperform descriptive adjectives

• Use example pairs to define a classification scheme without listing categories

• Use a single pair to lock an exact output shape for reformatting tasks

• Carry a specific voice into new content using sample outputs

Topics Covered

• Generic output as a symptom of missing context

• The three-reports analogy for few-shot learning

• Context: audience, product and goal

• Few-shot examples as input-to-output pairs

• Why examples beat adjectives for tone

• Before and after on a single writing task

• Tagging and classification taught by example pairs

• Reformatting messy notes into a fixed structure

• Matching an established voice across new items

Practical Takeaways

Two labelled examples can define an entire category set without the categories ever being listed. One well-chosen pair can specify a structure that would otherwise take a paragraph to describe. Instructions such as make it punchy mean different things to different readers, while a sample line means exactly one thing. Paste the facts and a pair of examples before you ask, and the answer arrives much closer to what you pictured.

Summary

This lecture turns context and few-shot examples into a repeatable habit that visibly raises the quality of everyday output.

Iterating and Refining a Prompt

Lecture Overview

The first answer is rarely the final one. This lecture presents refinement as a repeatable loop — read, diagnose, adjust, repeat — modelled on a sculptor who roughs out a shape before working the detail. Rather than rewriting from scratch, you steer the output with small, targeted edits that preserve what already works.

What You Will Learn

• Adopt a read, diagnose, adjust and repeat cycle for improving output

• Diagnose the specific gap rather than declaring the whole answer unsatisfactory

• Give feedback that names what to keep as well as what to change

• Make small targeted edits instead of restarting the task

• Refine a draft across successive passes toward a sharper result

• Correct a single line or bullet while leaving the rest untouched

• Reference an earlier version when a later one drifted in the wrong direction

Topics Covered

• Why first outputs fall short on harder tasks

• The sculptor analogy: rough shape, then refinement

• The refinement loop: read, diagnose, adjust, repeat

• Steering rather than rewriting

• A two-step refinement of a product description

• A three-pass refinement of a call summary

• Diagnostic phrases for common gaps: too generic, too long, wrong tone, missed point, one detail wrong

• Follow-ups that preserve the good parts

• Referring back to a preferred earlier version

Practical Takeaways

Name the gap out loud and the fix becomes obvious: too generic asks for a named audience and a concrete number, too long asks for a bullet and word cap, wrong tone is best fixed by pasting one sentence in the voice you want. Instructions such as keep the structure, halve the length or redo just that bullet protect work that is already correct. Refinement is a skill of precision, not persistence.

Summary

This lecture replaces frustrated re-prompting with a disciplined method for steering output toward exactly what you need.

Common Prompting Patterns for Work Tasks

Lecture Overview

Many people know what they want but not how to ask for it. This lecture supplies five reusable prompting patterns — summarise, extract, rewrite, classify and draft — that cover a large share of everyday professional work. Each pattern is demonstrated on a realistic task, and the lecture then shows how patterns combine and how constraints sharpen them further.

What You Will Learn

• Apply the summarise pattern to condense long threads into decisions, owners and dates

• Use the extract pattern to pull structured fields out of messy documents or images

• Apply the rewrite pattern to change tone while preserving the message

• Use the classify pattern to label items against a defined set of categories

• Use the draft pattern when the output is a starting point you will refine

• Combine two or more patterns across consecutive prompts

• Add constraints such as source scope, audience, tone and length

Topics Covered

• Why short prompts can still be powerful

• Summarise — threads, meetings and long documents

• Extract — structured fields from unstructured input

• Rewrite — softening or professionalising a message

• Classify — labelling tickets or comments consistently

• Draft — producing a first version for refinement

• Matching a real situation to the right pattern

• Chaining patterns across a conversation

• Adding analysis constraints and source requirements

• Specifying audience, tone and length together

Practical Takeaways

Naming the operation you want — summarise, extract, rewrite, classify, draft — does much of the work a long prompt would otherwise do. Real tasks often combine patterns: summarise a thread, then draft the reply from those bullets. Constraints make each pattern sharper, whether that is restricting the analysis to one data tab, requiring recent sources with links, or naming the audience and word count for a draft.

Summary

This lecture gives you five dependable patterns you can reach for immediately, plus the habit of combining and constraining them.

Practice — Exercise and Exam Questions

Lecture Overview

This lecture has two halves. The first is a hands-on repair job: a colleague's prompt that has been producing vague output for weeks is diagnosed against the five-part framework, rebuilt, and compared side by side with the original. The second half is a set of eleven exam-style questions covering the prompting domain, each with the correct answer and an explanation of why the near-misses fail.

What You Will Learn

• Diagnose a failing prompt by checking it against Role, Context, Task, Format and Examples

• Rebuild a broken prompt so that every part the task needs is supplied

• Compare original and repaired output to see the effect of each added element

• Identify which prompt element controls expertise and voice

• Recognise when an element such as Role adds little value to a task

• Explain why a prompt that works for its author may fail for a colleague

• Constrain length with enforceable numbers rather than adjectives

• Choose worked examples over written category definitions for consistent labelling

Topics Covered

• A real broken prompt and the output it produces

• Diagnosing missing prompt elements one by one

• The repaired prompt with role, context, task, format and example

• Actionable constraints versus aspirational words such as high quality

• Role as the control for expertise and voice

• Recognising when not every element is needed

• Prompt portability and invisible surrounding context

• Precise length constraints

• Few-shot examples for consistent classification at scale

Practical Takeaways

Vague output is usually an accurate reflection of a vague instruction rather than a model failure. Numbers are enforceable while adjectives are not, so specify counts and word limits instead of asking for brevity. Prompts are not portable on their own — the Project, files and prior conversation travel invisibly with the author, which is why sharing a workflow means sharing the whole setup. And for a large labelling job, two or three worked examples define the label set more reliably than written definitions.

Summary

This lecture converts prompting theory into a demonstrated repair skill and then verifies it against exam-style questions.

Why Evaluation Matters Most

Lecture Overview

Output evaluation is the highest-weighted domain in the exam and the most consequential skill in real work, because using AI makes you responsible for what it produces. This lecture establishes the mindset: like an editor who checks a reporter's story before it goes to print, you trust the output enough to work with it but never enough to ship it unchecked.

What You Will Learn

• Understand why output evaluation carries the largest share of the exam

• Recognise the three ways output fails: confidently wrong, quietly incomplete, and off-target

• Identify omissions that leave a summary factually true but materially misleading

• Apply the editor mindset — trust, then verify — to every AI-assisted deliverable

• Understand that accountability for published work remains with the person, not the tool

• Weigh the cost of checking now against the cost of correcting later

Topics Covered

• Output evaluation as the largest exam domain

• A confident but unsupported claim as a worked example

• The reporter and editor analogy

• Confidently wrong output

• Quietly incomplete output and dropped conditions

• Output that is accurate but pitched at the wrong reader or level

• Human in the loop for sensitive material

• Accountability and the byline

• Prevention versus correction

Practical Takeaways

A summary can be entirely accurate and still fail if it drops the one condition that determines the outcome — omissions carry weight, not just errors. Saying that an AI wrote it has never been an acceptable explanation to a client or a stakeholder, because accountability does not transfer to the tool. Spending twenty seconds verifying before sending is cheaper than spending hours correcting afterwards.

Summary

This lecture sets the standard for the whole section: nothing you did not check is something you can defend.

Spotting Hallucinations and Fabrications

Lecture Overview

A hallucination is not a lie. A lie requires knowing the truth and choosing otherwise; a hallucination produces the shape of a correct answer — a plausible name, number or citation — with nothing behind it, and with no internal alarm to signal the problem. This lecture explains why hallucinations happen and teaches the recognisable patterns that should trigger verification.

What You Will Learn

• Distinguish hallucination from deliberate falsehood and understand why the distinction matters

• Recognise citations that look complete but reference material that does not exist

• Identify statistics presented without an attributable source

• Treat claims about very recent events with extra caution given training cutoffs

• Notice uncertainty signals such as inconsistent figures or muddled context

• Apply stricter verification to numeric, legal, medical, financial and personal claims

• Use follow-up techniques such as requesting links and cross-checking elsewhere

Topics Covered

• The intern who never says I don't know

• Why a hallucination is not a lie

• Fabricated citations with convincing detail

• Unattributed numbers and statistics

• Claims about recent events beyond the training cutoff

• Signals of uncertainty in an answer

• High-stakes categories that always require verification

• Finding fabrications hidden inside otherwise sound paragraphs

Practical Takeaways

The most convincing hallucinations look too perfect — complete author names, journal titles and page numbers that lead nowhere. Any figure without a traceable source should be treated as unverified rather than approximately right. Request links, open them, and check whether they support the claim; a second tool or a fresh conversation can help surface what a single answer conceals. Accountability rests with you, so nothing unverified belongs in published work.

Summary

You will finish this lecture able to recognise the specific shapes hallucinations take before they reach anyone else.

Fact-Checking and Verifying Claims

Lecture Overview

This lecture provides a practical toolkit for verification, built on the principle a journalist works by: the story does not run until the source holds up. It covers several complementary techniques, explains why some are stronger than others, and sets out how much verification different categories of work deserve.

What You Will Learn

• Ask for sources and open the links rather than accepting a claim at face value

• Cross-check a claim in a fresh conversation to avoid inherited context

• Ask how a figure or conclusion was reached to expose weak reasoning

• Prompt the output to identify its own likely weak spots

• Use a second tool as an independent check where appropriate

• Understand why asking are you sure is not a real verification step

• Scale verification effort to the stakes of the deliverable

Topics Covered

• The journalist's rule on sources

• Technique 1: request the source and the link

• Technique 2: cross-check in a fresh conversation

• Technique 3: ask how the answer was derived

• Technique 4: ask the output to flag its own weak points

• Using a second AI as a cross-check

• Why a simple confirmation question proves nothing

• Risk tiers: internal notes, summaries with figures, and customer, legal or financial material

• Why a single source is not enough

Practical Takeaways

A fresh conversation is a genuinely useful check because it does not inherit the assumptions of the original thread. Asking the model whether it is sure adds nothing — the same process that produced the claim produces the reassurance. Match effort to stakes: an internal note with no claims needs little, while anything touching customers, money, law or the public deserves multiple independent sources before it goes out.

Summary

This lecture turns verification from a vague intention into a set of specific, repeatable moves.

Demo — Fact-Checking an Answer Line by Line

Lecture Overview

This demonstration puts verification into practice inside a Project. A draft market brief said to have been produced by an AI assistant is supplied along with a CSV file, and the task is to extract every claim from the draft into the existing structure so that each one can be examined individually rather than accepted as a block of prose.

What You Will Learn

• Set up a Project around a folder containing the source material

• Supply a draft of unknown reliability as the object of verification

• Write a prompt that extracts claims into a defined structure

• Reuse an existing file and its headings rather than generating a new format

• Constrain the task so that facts are transferred without alteration

• Understand why separating claims individually makes checking practical

Topics Covered

• Creating a Project from a local folder

• Working with a supplied draft and a CSV template

• Prompting for claim extraction

• Specifying the output format and existing headings

• Instructing the model not to alter the supplied facts

• Preparing extracted claims for line-by-line checking

Practical Takeaways

Verification becomes manageable when claims are pulled out of prose and listed separately, because a paragraph invites a single overall judgement while a list forces one decision per claim. Instructing the model to transfer facts without changing them keeps the extraction faithful to the source under review.

Summary

This demo shows how a document of uncertain reliability is broken down into individually checkable claims before any of it is trusted.

Judging Quality — Relevance, Completeness and Accuracy

Lecture Overview

Without a shared standard, one person ships an output and another rewrites it, and nobody can articulate why. This lecture supplies that standard: four questions applied to every output — is it accurate, is it relevant, is it complete, and is it consistent. Each is illustrated with a realistic failure so the fault becomes recognisable rather than intuitive.

What You Will Learn

• Apply four evaluation questions consistently to any output

• Check accuracy across every fact, figure, date and name

• Test relevance by asking whether the actual question was answered

• Detect incompleteness where an omitted condition changes the outcome

• Identify internal contradictions, factual drift and tone drift

• Record results as pass or fail so failures trigger revision rather than debate

Topics Covered

• Why evaluation without a standard produces inconsistent decisions

• The four questions: accurate, relevant, complete, consistent

• Accuracy failures, including invented details

• Relevance failures where the answer avoids the decision asked for

• Completeness failures where a dependency is dropped

• Consistency failures: internal contradiction, contradicting known facts, and tone drift

• Turning the four questions into a simple pass-or-fail check

Practical Takeaways

An answer that discusses the topic without answering the question has failed on relevance, however well written it is. A summary that omits a blocking dependency is incomplete even though every stated sentence is true. Contradictions and tone shifts within a single piece signal that the output was assembled rather than reasoned. Run all four checks and treat any failure as a rewrite trigger.

Summary

This lecture replaces gut feeling with four repeatable questions that make quality judgements explicit and defensible.

When a Human Must Review Before It Ships

Lecture Overview

Both extremes fail: reviewing everything destroys the time saving that justified using AI, while reviewing nothing eventually ships something serious. This lecture provides a method for placing review where it belongs, assessing stakes through three questions and sorting work into green, amber and red zones.

What You Will Learn

• Assess stakes using harm, reach and reversibility

• Sort work into low, moderate and high-risk zones

• Recognise green-zone work that needs no formal review

• Identify amber-zone work that needs one careful read

• Identify red-zone work that requires a second human reader without exception

• Classify realistic examples correctly by zone

• Agree the review line in advance rather than under deadline pressure

Topics Covered

• Why reviewing everything and reviewing nothing both fail

• The preflight check analogy

• Question one: harm — what is the worst outcome

• Question two: reach — who will see it

• Question three: reversibility — can it be undone

• Green zone: private drafts, brainstorms and reformatting

• Amber zone: internal messages, documentation and summaries with figures

• Red zone: legal, medical, financial and safety matters, published or large-scale content, money, commitments and personal data

• Worked classification of everyday examples

Practical Takeaways

Anything that leaves your organisation, mentions money, names a person or touches a customer gets a second reader — no exceptions, regardless of deadline. Deciding that line before you are under pressure is what makes it hold. Reversibility matters as much as severity: a mistake you can correct in a minute is a very different risk from one that cannot be recalled.

Summary

You will finish this lecture with a defensible rule for where human review belongs and where it is simply overhead.

Building a Personal Validation Checklist

Lecture Overview

Judgement varies with fatigue, deadlines and time of day, which is exactly why professionals who cannot afford mistakes work from checklists rather than memory. This lecture builds a six-question validation checklist, applies it to a real draft to expose its faults, and shows how to adapt it to different roles and different levels of risk.

What You Will Learn

• Understand why a checklist outperforms attention that varies through the week

• Apply six checks covering relevance, detail accuracy, sources, completeness, reader fit and sign-off

• Run the checklist against a realistic draft and identify each failure

• Adapt the checklist to your own function, such as finance, support, marketing or HR

• Scale the checklist down for low-stakes work without abandoning it

• Keep the checklist short enough that it is actually used

Topics Covered

• Decision fatigue and inconsistent judgement

• The professional checklist analogy

• The six questions in full

• A worked example: unsourced statistics and a missing dependency

• Role-specific additions for finance, support, marketing and HR

• Scaling effort to stakes

• Why an unused checklist is worse than none

• Using policy documents in a Project to ground and cross-check claims

Practical Takeaways

A checklist you skip is worse than no checklist at all, so keep it to something that fits on a card and takes seconds on low-stakes work. Phrases such as industry data suggests are a reliable trigger to demand a source. Role context changes the emphasis: finance ties every figure back to the source system, support checks that nothing was promised beyond policy, marketing substantiates claims, and HR considers how a named person would feel reading it.

Summary

This lecture leaves you with a concrete, personalised checklist rather than a general intention to be careful.

Editing and Adapting Output for Your Audience

Lecture Overview

One draft rarely fits every reader. A technically precise paragraph may be exactly right for an engineer while baffling a customer and irritating an executive. This lecture shows how to retarget the same underlying facts for different audiences, and makes clear that identifying the audience is your responsibility, not the model's.

What You Will Learn

• Recognise when a draft is pitched wrongly for its intended reader

• Rewrite the same information for executive, customer and technical audiences

• Use tone as a deliberate instruction rather than an afterthought

• Understand why the model cannot infer the audience unless you name it

• Adapt output without altering the underlying facts

Topics Covered

• Why one draft cannot serve every reader

• An over-technical paragraph and who it fails

• Rewriting for an executive: outcome and impact

• Rewriting for a customer: warm, plain and jargon-free

• Rewriting for the team: precise technical detail and references

• Audience identification as a human responsibility

Practical Takeaways

The same event can be reported three legitimate ways — brief and outcome-focused for leadership, warm and plain for customers, precise and technical for engineers. The model performs the rewrite, but naming the reader is your job, because nothing in the prompt tells it who will read the result unless you say so.

Summary

This lecture closes the evaluation section by turning verified content into something the intended reader can actually use.

Fitting Claude Into Real Work

Lecture Overview

People get AI wrong in two opposite directions: avoiding it entirely because they do not trust it, or expecting it to take over the job completely. The truth sits in the middle — a helper, not a replacement. This lecture maps where Claude genuinely adds value, where it cannot stand in, and what the correct working mindset looks like.

What You Will Learn

• Recognise the two common failure modes: avoidance and over-delegation

• Identify where Claude adds real value: drafting, summarising, analysis and research

• Identify what stays human: final judgement, relationships and accountability

• Adopt an augment-rather-than-replace mindset

• Apply the model to a concrete everyday task such as a client update email

Topics Covered

• Two ways people get AI wrong

• Where Claude speeds up the heavy lifting

• Where it cannot stand in: judgement, trust and accountability

• Augment, do not replace

• A worked example: the client update email before and after

Practical Takeaways

The largest immediate gain is often the elimination of the blank-page cost — a first draft in seconds rather than forty minutes of staring, after which you edit the tone and send. The author and the responsibility are unchanged. Claude drafts and digs; you decide and own the outcome.

Summary

This lecture sets the frame for the workflow section: a clear division between the work that speeds up and the work that stays yours.

Breaking Big Tasks Into Steps

Lecture Overview

A single prompt asking for research, an outline, a full report and a polish gives you no visibility and no control. If the outline is weak, everything downstream inherits that weakness. This lecture shows how to decompose a large task into ordered steps with checkpoints, so that errors are caught where they occur rather than at the end.

What You Will Learn

• Recognise why a single large prompt produces unreliable results

• Decompose a task into research, outline, draft and polish stages

• Place a checkpoint between stages so each output is inspected before it is built on

• Write a focused prompt for each individual stage

• Understand why decomposition matters most when stakes are high

Topics Covered

• The problem with one prompt for a whole deliverable

• Errors compounding through unchecked stages

• A four-step decomposition of a market report

• Research: gathering specific, sourced facts

• Outline: turning facts into section headings

• Draft: expanding each section from the agreed outline

• Polish: tone, flow and tightening

• Checkpoints between steps

Practical Takeaways

Each checkpoint is an opportunity to correct direction cheaply. When you approve the outline before drafting begins, a weak structure never propagates into a finished report. Small steps with inspection between them consistently outperform one ambitious request, particularly on complex or high-stakes work.

Summary

You will finish this lecture able to turn a daunting deliverable into a sequence of checkable stages.

Designing a Repeatable Workflow

Lecture Overview

If you write a prompt on Monday and rewrite it from memory the following Monday, you are repeating work and accepting inconsistent results. This lecture shows how to turn a recurring task into a saved template, standardise the steps so anyone can run them, and host the whole thing in a Project so a team shares one version.

What You Will Learn

• Identify tasks that recur and therefore deserve a template

• Save a prompt as a reusable template instead of rewriting it each time

• Standardise steps so a colleague can run the process unchanged

• Isolate the part that actually changes, such as the week's figures

• Store the template inside a Project so the whole team uses the same version

• Run a recurring report by supplying new data against a fixed template

Topics Covered

• Why one-off prompts waste effort and produce drift

• Saving and reusing a template

• Standardising steps for others to run

• Separating the fixed instructions from the changing inputs

• Hosting the template in a shared Project

• A worked weekly sales report template

• Running the template with new data each cycle

Practical Takeaways

Write it once, save it, and reuse it. In a well-designed template the only thing that changes between runs is the data you paste in, which is what makes the output comparable week over week. Keeping the template inside a shared Project means the team runs one agreed process rather than several personal variations.

Summary

This lecture converts a task you happen to do repeatedly into a defined workflow anyone on the team can execute.

Measuring If It's Actually Working

Lecture Overview

A tool can feel helpful without being helpful. This lecture insists on evidence: enthusiasm is not proof, and a good impression can conceal zero real gain. It sets out four practical metrics, explains why a baseline is essential, and gives a clear decision rule for whether to keep, expand or drop an AI-assisted process.

What You Will Learn

• Understand why perceived benefit is not evidence of benefit

• Measure time saved against a documented baseline

• Track error rates before and after introducing AI assistance

• Measure throughput as work completed in the same time

• Interpret adoption carefully as a softer, less reliable signal

• Establish a baseline by running the same task without AI

• Apply a decision rule based on whether the numbers actually move

Topics Covered

• Why it feels helpful is not a measurement

• Metric one: time saved per task or per week

• Metric two: error rate

• Metric three: throughput

• Metric four: adoption, and why it is ambiguous

• Building a baseline for comparison

• Weighing gains against added complexity and cost

• A worked example comparing response times

Practical Takeaways

Without a baseline there is no proof — measure the same task with and without assistance and compare. If the numbers move meaningfully, continue and expand; if they barely move, remember that introducing AI also introduces complexity and cost, which a marginal gain does not justify. Let the metrics, not the enthusiasm, decide.

Summary

This lecture gives you the evidence base to defend, adjust or abandon an AI-assisted workflow on the numbers.

Measuring If It's Actually Working

Lecture Overview

A tool can feel helpful without being helpful. This lecture insists on evidence: enthusiasm is not proof, and a good impression can conceal zero real gain. It sets out four practical metrics, explains why a baseline is essential, and gives a clear decision rule for whether to keep, expand or drop an AI-assisted process.

What You Will Learn

• Understand why perceived benefit is not evidence of benefit

• Measure time saved against a documented baseline

• Track error rates before and after introducing AI assistance

• Measure throughput as work completed in the same time

• Interpret adoption carefully as a softer, less reliable signal

• Establish a baseline by running the same task without AI

• Apply a decision rule based on whether the numbers actually move

Topics Covered

• Why it feels helpful is not a measurement

• Metric one: time saved per task or per week

• Metric two: error rate

• Metric three: throughput

• Metric four: adoption, and why it is ambiguous

• Building a baseline for comparison

• Weighing gains against added complexity and cost

• A worked example comparing response times

Practical Takeaways

Without a baseline there is no proof — measure the same task with and without assistance and compare. If the numbers move meaningfully, continue and expand; if they barely move, remember that introducing AI also introduces complexity and cost, which a marginal gain does not justify. Let the metrics, not the enthusiasm, decide.

Summary

This lecture gives you the evidence base to defend, adjust or abandon an AI-assisted workflow on the numbers.

Communicating Value and Limitations to Stakeholders

Lecture Overview

Over-promising loses trust permanently, and a single wrong answer reaching a customer can break a sweeping promise all at once. This lecture teaches an honest communication pattern: state the value in concrete numbers, name the boundaries and human checkpoints, and flag the residual risk together with how it will be measured and handled.

What You Will Learn

• Recognise why absolute claims about AI performance are dangerous

• State value in concrete, measurable terms rather than sweeping language

• Describe quality improvements such as grounding replies in a policy document

• Name explicit boundaries where the system will not be used

• Specify human checkpoints in the process

• Set expectations before launch rather than after an incident

• Combine value, boundaries and risk into one honest paragraph

Topics Covered

• Over-promising and the cost of a broken promise

• Stating time savings in plain numbers

• Quality gains from grounded, consistent answers

• Naming excluded categories such as refunds and legal questions

• Human approval as a stated checkpoint

• Pre-launch expectation setting

• Tracking accuracy and having a remediation plan

• A worked example of an honest stakeholder pitch

Practical Takeaways

A flagged risk is a plan; a hidden one is a broken promise waiting to happen. The strongest pitch says what improved, in numbers, then names what the system will not do, who approves output before it goes out, and how accuracy will be tracked and corrected if it slips. Honesty here is not caution — it is what keeps the initiative credible after the first mistake.

Summary

This lecture equips you to present AI-assisted work to stakeholders in a way that survives contact with reality.

Projects, Knowledge and Instructions

Lecture Overview

Re-explaining the same background at the start of every conversation is wasted effort. A Project is a persistent workspace that holds files, custom instructions and conversation history, so every chat inside it begins already informed. This lecture explains the three components of a Project, introduces grounding as the key concept, and covers what should and should not be uploaded.

What You Will Learn

• Understand a Project as a persistent workspace with files, instructions and history

• Explain grounding and how it differs from an answer drawn from general training

• Test whether a Project is genuinely grounded by asking something only your files can answer

• Compare grounded and ungrounded answers to the same question

• Recognise signals that an answer is grounded, and warning signs that it is not

• Apply judgement about which files are appropriate to upload

• Write custom instructions covering role, audience, tone, and dos and don'ts

Topics Covered

• Why repeated context-setting is inefficient

• The three parts of a Project: files, instructions and conversation history

• Grounding: specific, checkable answers traceable to a source

• A worked comparison of a grounded and ungrounded refund-policy answer

• Good signs: named sections, quoted wording, unusual figures found in one file

• Warning signs: generic answers and citations to sections that do not exist

• File limits and extracting only the parts that matter

• Personal data, confidential material and organisational permission

• Custom instructions: role, audience, tone, dos and don'ts

• A worked example of a complete instruction set

Practical Takeaways

Grounding reduces invention but does not abolish it, so test a new Project with a question only your documents could answer and check that cited sections actually exist. An answer that would fit any company in your industry is training data talking, not your knowledge base. Upload only what matters, keep personal and confidential material out unless your organisation permits it, and if you are unsure, get a second opinion before uploading.

Summary

This lecture explains why a Project produces better answers and how to set one up so that its answers can be trusted.

Maintaining a Project and Connecting Your Tools

Lecture Overview

A Project quietly degrades if nobody maintains it: stale files, bloated context and outdated policies produce confidently wrong answers. This lecture covers keeping a knowledge base healthy, establishing a maintenance rhythm, and connecting external tools — along with the least-privilege principle that should govern every connection you authorise.

What You Will Learn

• Recognise how stale files and cluttered context degrade output quality

• Combine complementary sources such as a handbook, project specs and a tone guide

• Update files on the day the underlying information changes

• Prune outdated, duplicated and retired material

• Establish a regular review rhythm for project knowledge

• Understand what connectors do and when they are needed

• Apply least privilege when granting access, and review permissions regularly

• Scope a connector to specific folders rather than an entire account

Topics Covered

• Symptoms of an unmaintained Project

• Multiple complementary sources producing sharper answers

• Keeping files current as policies change

• Pruning outdated and duplicate content

• A monthly refresh, update and delete routine

• Working blind when Claude cannot see the document

• Connectors for external tools such as drive, mail and messaging

• Least privilege: minimum access, reviewed often

• Scoping connector access to specific folders

• Sensitivity considerations when connecting live data

Practical Takeaways

Old knowledge in, outdated answers out — the model has no way to know a policy changed unless the file changes. Three complementary sources usually outperform any one of them alone, but only if each is current. Grant the least access that does the job, remove connections you no longer use, and scope connectors to specific folders rather than handing over an entire account.

Summary

This lecture keeps a Project useful over time and connects it to live tools without over-exposing your data.

Responsible Use and Transparency

Lecture Overview

Governance carries significant weight in the exam and even more in real work, because careless use can affect real people through leaked data, poor decisions or false claims. This lecture sets out three guiding principles — helpful, honest and harmless — and translates them into everyday practice, including when disclosure of AI assistance is required.

What You Will Learn

• Apply the three principles of helpful, honest and harmless to daily work

• Distinguish appropriate uses from uses that put people at risk

• Understand that accountability sits with the person, never with the tool

• Recognise when AI assistance should be disclosed

• Write a brief, honest disclosure rather than a legal-style disclaimer

• Comply with organisational rules, law and regulation rather than assuming permission

Topics Covered

• Why responsible use matters beyond the exam

• Helpful, honest, harmless as working rules

• Green-light uses: drafting, summarising and brainstorming with human review

• Red-light uses involving customer or personal data

• Accountability and the person who sends the work

• The problem with silently passing AI output off as your own

• When disclosure matters: policy requirements and reader expectations

• Organisational rules, laws and regulations

Practical Takeaways

The same tool can respect people or put them at risk depending on what you feed it — rewriting a public draft is fine, pasting a customer list to generate personal notes is not. Presenting unverified AI output as your own checked work breaks trust the moment it is discovered. One honest line noting that a draft was AI-assisted and reviewed by you is usually enough. And the rules are not yours to guess: follow your organisation's policy on which tools may be used and how.

Summary

This lecture gives you a defensible standard for using AI in a professional setting without compromising trust.

Data Privacy and What Not To Share

Lecture Overview

A prompt can leak real data. The moment sensitive information is sent, it has left your control — and the obvious deserves saying plainly. This short lecture names the categories that must never appear in a prompt, explains anonymisation as a partial mitigation, and points to your organisation's data policy as the governing rule.

What You Will Learn

• Understand that sending sensitive data is itself the disclosure event

• Identify the four categories that must never appear in a prompt

• Apply stripping and anonymisation when data must be used at all

• Follow your organisation's data policy as the authoritative rule

• Know where to check when you are unsure whether sharing is permitted

Topics Covered

• How a routine prompt becomes a privacy leak

• Personal data

• Payment information

• Credentials

• Confidential business information

• Stripping and anonymising data before use

• Organisational data policy as the thumb rule

• Checking policy documents or asking a manager when in doubt

Practical Takeaways

Anonymise only when the task genuinely requires the data; the safest choice is not to include it at all. Your organisation's data policy — not your own judgement of what seems harmless — determines what may be shared, and if there is any doubt, confirm before sending rather than after.

Summary

A short but essential lecture: know the four categories that never go in a prompt, and follow policy when in doubt.

Troubleshooting and Optimization

Lecture Overview

When output disappoints, the failure is usually silent — nothing announces what went wrong. This lecture provides a diagnostic method: identify which of four common causes is responsible, then fix one thing at a time. It then turns to optimisation, covering front-loaded prompts, right-sized models, saved templates and measuring the results.

What You Will Learn

• Diagnose the cause of poor output before attempting to fix it

• Recognise four common causes: missing constraints, missing context, wrong model and too much at once

• Front-load the first prompt with the details you already have

• Right-size the model to the difficulty of the task

• Save prompts that work as reusable templates

• Track rounds, time and cost to compare configurations

• Test several models to find the best balance for a recurring task

Topics Covered

• Silent failure and unclear symptoms

• Cause one: no audience, length or goal specified

• Cause two: missing context

• Cause three: an unsuitable model for the task

• Cause four: too many operations in a single request

• Diagnosing before fixing, and changing one variable at a time

• Slow results from an oversized model or an overcomplicated prompt

• Writing a complete opening prompt

• Matching model size to task difficulty

• Saving proven prompts

• Measuring rounds, time and cost to optimise

Practical Takeaways

Front-loading detail in the first prompt removes rounds of correction later — state audience, length, tone and the call to action from the start. Do not send a race car to fetch groceries: simple tagging, sorting and grammar work belongs on a smaller, faster model, while reasoning and analysis justify a stronger one. Once a prompt works, save it, then compare a few configurations on rounds, time and cost rather than assuming the biggest option is best.

Summary

This lecture gives you a systematic way to diagnose bad output and then tune the setup that produced it.

Exam Strategy — Pacing, Reading the Question, Readiness

Lecture Overview

This lecture builds a simple exam strategy around three things: pacing, reading the question, and knowing when you are ready. It starts from the three numbers that define the paper, then teaches a method for reading scenario questions that you already use in everyday life — spot the question, pull out the facts, and test each option against them.

What You Will Learn

• Plan your pacing from the question count, time limit and passing score

• Flag difficult questions and return to them rather than losing time

• Check your progress against the clock at fixed intervals

• Never leave an answer blank, since a blank scores nothing and a guess might score

• Spot the actual question before reading the answer options

• Extract the three key facts from a scenario: who, what they want, and the catch

• Eliminate options by testing each one against those facts

• Handle multiple-response questions without adding extra selections for safety

• Use timed practice results to decide when you are ready to book

Topics Covered

• The exam in three numbers

• Two minutes per question and why not every question is equal

• Flagging and returning

• Progress checkpoints through the exam

• Guessing versus leaving blanks

• The everyday analogy: reading a text message for the real question

• A worked exam question with the same structure

• Step one: pull out three facts

• Step two: find the line with the question mark

• Step three: eliminate options that break a fact

• Multiple-response questions and the cost of a wrong tick

• Readiness benchmark from timed practice

Practical Takeaways

Spend less than two minutes on the questions you know so the hard ones have room; one difficult question can consume the time of five easy ones. In scenario questions the details pick the answer — hold each option against who the person is, what they need and what the constraint is, and only one option survives all three. On multiple-response items, an incorrect tick costs the same as a missed one, so select only what you are confident about.

Summary

This lecture converts preparation into a concrete plan for the exam itself: pace it, read it, then book it.