The Hub Toolkit
Maintenance prompts and replication guide for an AI-powered residency operations workspace built on retrieval-augmented generation.
This is the system we built to maintain our residency program’s operational knowledge hub on a retrieval-augmented generation (RAG) platform. It runs on Google NotebookLM and is adaptable to any RAG platform that accepts structured source documents.
We designed it so anyone, whether program coordinator, PD/APD, chief resident, or any team member comfortable with a word processor and an AI chatbot, can keep the system current. No code. No API. No IT ticket.
A single, queryable knowledge base that answers operational questions for your residents in plain English, grounded entirely in your program’s own documents. It bridges the five to seven scattered repositories our residents were searching: email threads, shared drives, group chats, Apple Notes from graduated residents, texts to the coordinator, and whatever the senior told them last July.
This is your program’s documented knowledge made searchable, not an independent clinical advisor. The Hub retrieves and cites what your team has written: service guides, attending preferences, institutional pathways, coverage policies, operational logistics. It does not generate clinical recommendations on its own. Residents are expected to verify source citations and defer to supervising faculty and patient-specific clinical judgment.
Standing It Up
We found that uploading raw documents to a RAG platform is not enough, particularly when multiple sources overlap on the same item. Date-sensitive operational queries produce confidently blended answers when sources disagree.
The fix: a contextualization layer applied to every source before upload, including per-source metadata, anticipated user questions, an interpretation guide, and a cross-source priority hierarchy that names which source wins when two of them conflict.
Create the notebook
Create a notebook at notebooklm.google.com. Name it something your residents will recognize (e.g., [Program] Hub). Share with your residents and coordinator. View access for everyone; edit access for anyone who maintains sources.
Start with five sources, not fifty
Apply the Tuesday Morning Test: what does a resident covering an unfamiliar service at 6:40 AM on a Tuesday need to know? That is your starting source list.
How to surface candidates:
- Listen for the questions residents text each other. The recurring ones (coverage swaps, attending preferences, code and extension lookups) tend to be the highest-yield sources.
- Ask your coordinator and chief residents what they get asked most. Anything they answer more than once a week is a source candidate.
- Engage your power users early. Residents already maintaining shared notes know which information is missing and which channels need to retire. Build with them; do not replace them.
Where we started: the weekly coverage schedule, our busiest service’s cookbook, the on-call escalation policy, a contacts and codes directory, and the faculty away calendar. Five sources at launch; we grew from there as gaps surfaced.
Plan a live-sync layer for high-churn content
Static-file maintenance (download, edit, re-upload) works for most sources. But the highest-churn categories (door codes, faculty preferences, weekly schedule deltas, contact directories) generate enough small edits that a static workflow creates noticeable friction.
Pair the static playbook with a live-sync editing layer (e.g., Google Docs that sync into NotebookLM) for your two or three highest-churn categories at launch. Retrofitting it later is harder than building it in.
The Five Maintenance Prompts
These are the five prompts we use to maintain the hub. Run each in the LLM of your choice (ChatGPT, Claude, Gemini) by pasting the prompt block at the top, then your inputs below it. The output is the new or updated Markdown source file, ready to upload to NotebookLM.
The structural rules inside Prompt 1 (Header, Metadata, Anticipated User Questions, Contextual Interpretation Guide, Main Content, Source End Marker) are the contextualization layer. Every source in the hub follows that template; the prompts below build and preserve it.
These five prompts reflect our program’s operational cadence: a weekly coverage schedule that arrives by email, a faculty away calendar that updates ad hoc, and a source library that grows as gaps surface. Your program’s set will map to your own workflows. The pattern (reusable prompts that preserve the contextualization layer) is what transfers; the specific count and scope are yours to adapt.
Creating a New Source File Use when adding a document that does not yet exist in the hub.
- Paste the full text of the new document below the prompt.
Making a Specific Edit to an Existing Source Use for small, targeted changes to an existing source file.
- OLD SOURCE TEXT: Paste the entire raw Markdown text of the source you want to edit.
- UPDATE INSTRUCTION: Describe the change clearly (e.g., “Change the on-call contact from Dr. Smith to Dr. Davis”).
Faculty Away Calendar Maintenance Use whenever new faculty leave dates come in.
- THE PREVIOUS VERSION: Paste the full text of the current Faculty Away Calendar source.
- THE NEW ENTRIES: Paste or describe the new faculty away dates.
Weekly Schedule Maintenance Use every week when the new schedule email arrives.
- NEW WEEKLY EMAIL TEXT: Paste the coordinator’s weekly email.
- NEW WEEKLY SCHEDULE TABLE: Paste from the schedule PDF or spreadsheet.
Consolidating Multiple Old Sources Use for periodic cleanup and consolidation.
- Paste the full text of all related sources below, one after another.
Keeping It Running
The hub decays if nobody maintains it. We learned that early. Below is what our maintenance workflow looks like.
When the new coverage schedule email arrives (usually Friday), run Prompt 4 to generate the new week’s block and append it to the master schedule file. If new faculty away dates came in that week, run Prompt 3 to merge them into the calendar.
Small edits throughout the month: a contact name changes, a policy gets revised, a door code rotates. Those are Prompt 2. As they arise.
Run Prompt 5 to consolidate accumulated monthly schedule files and review the source list for anything stale or superseded.
Our coordinator owns routine maintenance, with PD and APD content oversight. All residents are encouraged to flag inaccuracies when identified from the user side and submit update requests to the coordinator or resident power users.
We started with this model at launch and have been broadening edit access to resident leaders for high-churn live-sync sources (service guides via Google Docs) as trust has built, so that residents have the ability to keep things maintainable in real time.
Your program’s model will depend on your coordinator’s capacity and your residents’ engagement. The constraint we would flag: locking maintenance permanently to one role creates a single point of failure when that person is on leave. Opening contribution too early creates conflicting edits and inconsistent metadata. We moved gradually, which for our program, has worked well.
This document is not a recipe. It is how we set ours up, the prompts we use, and the ownership model that works for us. Adapt what fits your program.
SAU @ AUA 2026 (Washington, DC): “Where AI Can Realistically Improve Resident Education”
Free to use, adapt, and share.