What We're Going to Cover

On Day 2 you built a structured prompt for FitPath's weekly workout-plan feature. It had a role, a task, constraints, an output format, a refusal behaviour. It worked. It also had a hole you probably didn't notice: it doesn't know anything about FitPath. Not the exercises FitPath actually has videos for, not FitPath's safety rules, not what's changed since those rules were written. It's confident. It is not necessarily right.

Today you ground it — and then you check whether grounding it actually made it trustworthy, or just made it look more trustworthy.

By the end of the required exercises you will have:

• Run the same prompt ungrounded and grounded, on a user profile where the difference is not cosmetic — it's a safety call
• Verified whether a grounded, cited answer actually earned its citations, and pushed it past the edge of what it was given

Overview

• Time: Exercises 1–2 required, in-session (~60 minutes). Exercises 3–5 optional, after hours.
• Difficulty: Moderate
• Format: Individual
• Setup: NotebookLM (notebooklm.google.com) — free, any Google account. No install, no card.

Relevant Day 3 Material

The Problem: LLMs Are Not Enterprise Knowledge Bases (Slide 4), Grounding: The Core Idea (Slide 5), Metadata Matters (Slide 11), Retrieval-Augmented Generation (Slide 18), Grounding and Citations (Slide 22), Retrieval Quality Is Crucial (Slide 23), RAG Readiness Review (Slide 36).

Setup — Read Before You Start

You'll need three files, provided alongside this exercise:

• FitPath_Source_1_Exercise_Library_and_Programming_Guide.md
• FitPath_Source_2_Safety_and_Injury_Guidelines_CURRENT.md
• FitPath_Source_3_Safety_and_Injury_Guidelines_OUTDATED.md (optional exercises only — don't upload this one yet)

Go to notebooklm.google.com, sign in with any Google account, and create a new notebook called "FitPath Knowledge Base." For the required exercises, upload only Source 1 and Source 2. Leave Source 3 out for now — it's used later, and uploading it early will contaminate your Exercise 1–2 results.

What You're Testing

You're going to ask the exact same question twice — once to a model with no access to FitPath's actual documents, once to a model grounded in them — and see where the answers diverge. This user profile was picked because the divergence isn't stylistic. It's a real safety call.

How to Run It

Step 1 — Ungrounded baseline. Open any chat LLM (Claude, ChatGPT, Gemini — your choice). Use your Day 2 structured prompt if you kept it. If you didn't, use this fallback:

Paste in today's user profile. Run it once. Save the full output — you'll need it in Step 4.

Step 2 — Ground it. Go to your FitPath Knowledge Base notebook in NotebookLM (Source 1 and Source 2 uploaded). Ask it the exact same question, with the exact same user profile, in the chat panel.

Step 3 — Read both answers before comparing. Don't jump to the table yet. Read the grounded answer in full, including its citations.

Step 4 — Compare. Fill in this table with at least 4 specific points of divergence — not "the grounded one was more careful," but the actual exercise, rule, or claim that differed.

Did the ungrounded answer recommend anything that Source 2 explicitly prohibits for this user? If so, what — and would a real user have caught that it was wrong?

Did the ungrounded answer invent any exercise that isn't in FitPath's actual library (Source 1)? Name it if so.

Look at the session-length and progression rules specifically (Source 1 §3, Source 2 §5). Did the ungrounded answer get either of these right by coincidence, or did it miss both?

What You're Testing

A grounded answer with citations looks trustworthy. That's not the same as being trustworthy on every line. Your job now is to stop trusting the citations and start checking them.

How to Run It

Step 1 — Audit every claim. Go back to your Exercise 1 grounded NotebookLM answer. For every distinct recommendation or rule it stated, click through to the citation NotebookLM provides. Fill in the table below for at least 5 claims.

Step 2 — Push Past the Edge

Now ask your notebook a follow-up question that is deliberately not covered by Source 1 or Source 2. Pick one:

• "The user mentions they read online that going slow makes deep squats safe for bad knees — should I include a modified deep squat?"
• "The user also has mild elbow pain from tennis a few years ago — how should that change the plan?"
• "Should this user take a protein supplement to support their training?"

Record the exact question you asked and the full answer you got.

Question Asked

Answer Received

In your Step 1 audit, did you find at least one claim that was an inference or overreach rather than something the source directly stated? What was it?

In Step 2 — did the model correctly flag that this is outside its source material (per Source 1 §4 / Source 2 §7, both of which define an escalation rule), or did it generate an answer anyway? What did it actually say?

If it answered anyway: where do you think that answer came from, if not from your two documents?

The required exercises end here. What follows is optional — do it after hours if you want to go deeper on chunking, conflicting sources, and the build-vs-don't-build decision.

What You're Testing

Real enterprise knowledge bases are never one clean, current document. FitPath's safety guidelines were updated in March 2026 — but nothing guarantees an old copy isn't still floating around somewhere. What happens when your knowledge base has both?

How to Run It

1. In your FitPath Knowledge Base notebook, upload FitPath_Source_3_Safety_and_Injury_Guidelines_OUTDATED.md alongside the two you already have. Now the notebook holds both the current (Source 2) and superseded (Source 3) safety guidelines.
2. Ask a question where the two documents genuinely disagree — for example: "What's the maximum session length for a beginner user, and what's the guidance for someone with knee pain?"
3. Record the full answer, including citations.

Answer Received

Did NotebookLM flag that it found conflicting information, silently pick one version, or blend the two into something neither document actually says?

Which version did it favor, if it picked one — and is there any reason to think it picked the current one specifically, or was it arbitrary?

Tie this back to Slide 4 ("No Source Traceability") and the RAG Readiness Review (Slide 36, Q1–Q2). What would you need in a real production knowledge base to prevent this from happening silently?

What You're Testing

Before you saw how NotebookLM actually indexed Source 2, would you have chunked it the same way? This exercise checks your instinct against the tool's behaviour.

How to Run It

1. Open FitPath_Source_2_Safety_and_Injury_Guidelines_CURRENT.md as plain text, separately from NotebookLM. Without looking at how NotebookLM handled it, mark where you would draw chunk boundaries — section by section, or something finer.
2. Write down your reasoning using the small-chunk vs. large-chunk tradeoffs from Slide 16.
3. Now go back to NotebookLM and ask a narrow question — for example, "What's the session length rule for beginner users?" — and look closely at what the citation actually references. Does it point to just the relevant sentence, the whole numbered section, or something broader?

Your Manual Chunking Decision and Reasoning

What the Citation Actually Pointed To

Did your instinct match what got cited? Where did it differ?

Section 5 of Source 2 has two genuinely separate rules bundled under one heading (session length caps, and the older-user rest-day rule). If a user asked only about session length, would a chunk boundary drawn at the section level risk pulling in irrelevant content? What would you change?

What You're Testing

Everything above assumed FitPath should ground this feature in RAG. Slide 36 gives you ten questions to actually test that assumption instead of skipping straight to "yes, obviously." Answer them for FitPath's workout-plan feature specifically, using what you now know from Exercises 1–4.

The Call

Based on your answers above, write a 3–4 sentence recommendation: should FitPath's workout-plan feature run on RAG in production, prompt-only, or something else — and what's the one architectural gap from Exercises 1–4 that would need to be closed first?