# A podcast season — guest research, episode briefs and show notes

Recipe No. 7, Books and writing. From The know.sh Cookbook: https://know.sh/cookbook/podcast-season

- For: an independent podcaster planning a ten-episode narrative season with a guest in most episodes
- You bring: a premise, ten working episode titles, a list of guests who have said yes, a few archives you mean to visit, and the AI assistant you already use
- You get: a season shelf with a document for the arc, a background document of sourced research, and a document per episode holding its research, the guest’s public record, your questions, the facts still to check and the show notes
- Time: an evening for your assistant to build the season, then two or three evenings per episode before you record
- Keep it: private while you work; share one document by a read-only link

A narrative season is ten small research projects wearing one coat. Episode four needs the 1919 newspaper reports, the accident inquiry and everything your guest has published; episode seven needs a different archive and a different guest; and by the time you record episode nine you have forgotten which date you gave for the line's opening in episode one.

This recipe gives the season one shelf. A season document holds the arc, one finding per episode. A background document holds the subject research, one point per finding with its sources. Each episode is a document with the same findings in the same order: what the episode is for, the research, the guest's public record, the facts to verify, your questions, the show notes and the credits. Whichever assistant you use, Claude, ChatGPT or a local model, does the deep research and builds all of it. You cut it down in the editor, check every fact, and write the script and the questions in your own voice.

The audio stays in your recording and editing software, and the episode goes out through your podcast host. know.sh holds what you know about the story, where you learned it, and what you told listeners.

## What you will use

- **Shelf**: One shelf per season, *Branch Line — Season 3*, with the season’s premise as its line.
- **Research document**: A season document for the arc, a background document for the subject, and one document per episode, *Ep. 4 — The Pickett Hill collision*.
- **Your AI assistant**: Researches the subject and each guest on the web, files an episode brief with the same findings every time, and cross-checks dates and names across the season.
- **The editor**: Where you cut what the story does not need, reorder the research into the order you will tell it, and rewrite the questions in your voice.
- **Proposed notes**: Your assistant leaves a proposed note where one episode contradicts another, with **Accept** and **Dismiss**, and never changes your text.
- **Look up**: Search the whole season for a name, a date or a phrase before you say it into a microphone.
- **Star and Focus**: Put the episode you are recording this week in **Focus**; star the episodes that are ready.
- **Public link**: A password link to an episode for your producer before recording, then a public link to the show notes once it is out.

## Method

### 1. Have your assistant lay out the season

Connect your assistant to know.sh once, following the support page for Claude, ChatGPT or a local model. Then give it the season in a paragraph: the premise, the ten working titles, and who is on which episode. Ask it to make the shelf, a document called *Season 3 — the arc* with one finding per episode (a logline, the guest, and what the listener should know by the end), and ten episode documents.

Give every episode document the same findings in the same order: **What this episode is for**, the research points, **Guest: public record**, **Facts to verify before recording**, **Questions**, **Show notes (draft)** and **Sources and credits**. A fixed shape means you always know where to look, and it makes the public link simple later.

### 2. Send it to research the subject

Ask your assistant to research the season's subject on the web and file what it finds as a new document on the shelf, *Background — the Harlan Valley line, 1905–1939*, one finding per point, each with its source links. Tell it to prefer primary sources: digitised newspapers such as Chronicling America at the Library of Congress, government reports, and the catalogues of historical societies. This needs an assistant with web search; Claude and ChatGPT have it, and many local set-ups do not.

Then ask it to move the points each episode needs into that episode's document, as *Evidence* findings. A claim it found in only one secondary source should be filed as a *Question*, not as fact.

### 3. Research each guest from the public record

For each guest, ask for a **Guest: public record** finding built only from what they have made public: their books and articles, talks, earlier podcast appearances, and the page of the museum, university or company they work for. Say plainly in the prompt that it should not look for a home address, family members, private social accounts or old personal posts, and should link every line to where it came from.

The point of guest research is better questions, not a dossier on a person. Read it, delete anything you would not say to the guest's face, and add what you learned from the pre-interview call.

### 4. Cut it down and make it yours in the editor

Press **Edit** on the episode. Drag the research findings into the order you will tell the story, delete the ones that do not serve this episode (move them to the background document if they may serve another), and mark the two or three facts the episode stands on as **Key**.

Your assistant can draft a list of questions from the research; treat it as a list of topics. Rewrite every question in the way you actually talk, cut the ones any guest has already answered on another show, and put your follow-ups under each. The script and the narration are yours, written outside the assistant. A listener can hear the difference.

### 5. Verify before you record

Work through **Facts to verify before recording** with the sources open. Every date, number and name you will say aloud should trace to a newspaper page, a report or the guest's own published work. A quotation goes in only if you have seen it in the original, with the paper, the date and the page; if an assistant offers a quotation you cannot find, delete it.

Then ask your assistant to read the whole shelf and look for contradictions: the line opens in 1907 in episode one and 1908 in episode six. It leaves each one as a proposed note, and **Look up** (⌘K) finds every other place you used that date.

### 6. Give your producer a password link

A day or two before recording, press **Share** on the episode, set a password and leave the seven-day expiry, and send the link and the password to your co-host or producer separately. They read the whole brief, research and questions included, without your highlights or notes. They cannot edit or comment; their notes reach you by message, and you make the changes.

Put the episode in **Focus** for recording week. When it is recorded, **Star** the episode document, so *Contents*, under *Starred*, shows how much of the season is done.

### 7. Publish the show notes

After the episode goes out, rewrite **Show notes (draft)** as the final notes: what the episode covers, the guest and where to find their work, and time codes if you make them. Put every source in **Sources and credits**: newspaper, date and page, archive and collection, and the credit line each archive asks for.

Then **replace** the link, which stops the producer's copy working and clears the old expiry and exclusions. Remove the password, choose *Never expire*, and leave out every finding except the show notes, the credits and a **Corrections** finding you keep for later. Paste the link into the episode description. If a listener writes in with a correction, check it and add it there.

## Prompts to try

Your assistant, connected to know.sh (Claude, ChatGPT or a local model):

> Using know.sh, make a shelf called “Branch Line — Season 3” with this line: “Ten episodes on the Harlan Valley interurban, 1905–1939.” Add a document “Season 3 — the arc” with one finding per episode below, and ten documents titled “Ep. 1 — …” to “Ep. 10 — …”. In each episode document, add these findings in this order: What this episode is for; Guest: public record; Facts to verify before recording; Questions; Show notes (draft); Sources and credits. Leave them short. Here are the episodes and guests: [paste your list].

Your assistant, connected to know.sh (Claude, ChatGPT or a local model):

> Research my guest for episode 7, [name], using only what they have published or said in public: books, articles, talks, interviews and their employer’s page. Do not look for their address, family, private social accounts or personal posts. Using know.sh, write it as the finding “Guest: public record” in the document “Ep. 7 — …” on my shelf “Branch Line — Season 3”, with a source link for every line, and end with five topics they have not already covered elsewhere.

Your assistant, connected to know.sh (Claude, ChatGPT or a local model):

> Using know.sh, read every document on my shelf “Branch Line — Season 3”. List every date, number, name and place that appears in more than one episode, and flag each one where two episodes disagree. Leave a proposed note on each disagreement, citing both findings. Do not edit my text.

## Variations

- For an interview-only show with no season arc, keep one document per guest on a standing shelf, and file each new episode’s questions and show notes there.
- If the season includes people who lived through the events, record and release their interviews the way an [oral history collection](/cookbook/oral-history) does, with signed releases and restricted passages kept apart.
- Before a live or unscripted recording, ask your assistant for a quiz on the episode document and take it in know.sh, so the dates and names are in your head rather than on a page.
- Pitching the season as a documentary series? The [television series bible](/cookbook/show-bible) shows the document a producer reads first.

## Where it falls short

- know.sh holds text only. Recordings, transcripts and edits stay in your audio software, and nothing here publishes to your podcast host or feed; you paste the link or the text into the episode description.
- A document has one link at a time. The producer’s password link and the public show notes cannot run side by side; replacing one ends the other.
- Web research needs an assistant with web search, and it reads only the open web. Subscription newspaper archives, and anything a historical society has not put online, are yours to visit.
- Smaller local models call tools less reliably. Check what they file; Revisions shows every change an assistant made.

## A note on guests, quotations and credit

Research guests from what they have chosen to make public, and nothing else. Tell them the topics before you record, and if a line of research would embarrass them on air, ask them about it first or leave it out.

Assistants make mistakes, and they can produce quotations and sources that look real. Verify every fact with a primary source before you record, never put words in anyone's mouth, living or dead, and treat a summary in your library as a lead, not a source. Credit every source in the show notes, and ask archives for permission before you use their recordings or images in an episode; being able to find something online does not mean you may broadcast it.

Indexed under: Podcasts, Guest research, Episode briefs, Show notes, Interview questions, Verification, Quotations.
