Actual Play Podcast Continuity Tracking: Never Lose a Thread on Air

The Continuity Stakes Are Higher on a Podcast

When you run a home game and make a continuity error, four friends notice and you correct it over pizza. When you run an actual play podcast and make a continuity error, thousands of listeners notice and Reddit threads multiply.

Actual play podcasts face a continuity challenge that private games do not: every word is recorded. Your audience can (and will) relisten to Episode 12 to verify whether the NPC's backstory matches what you said in Episode 47. They will build wikis documenting your world. They will catch contradictions you forgot you made.

This is not a burden — it is a sign of an engaged audience. But it means your continuity tracking system needs to be significantly more rigorous than a home game's.

What Makes Actual Play Continuity Different

Permanence. In a home game, a misspoken detail can be quietly corrected next session. In a podcast, the misspoken detail is recorded forever. Your canonical record is not your notes — it is the published audio.

Audience memory. Your listeners collectively remember more than any individual at the table. One listener remembers the blacksmith's name from Episode 3. Another remembers the exact wording of the prophecy from Episode 19. Together, they form a distributed continuity-checking engine.

Temporal distance. A podcast that runs for three years generates hundreds of hours of content. Details established in Year 1 must remain consistent in Year 3, even though you — the GM — have forgotten half of what you said.

Narrative expectations. Podcast audiences expect narrative craft. They expect setups to have payoffs. They expect foreshadowing to be intentional. They expect the world to be internally consistent. These expectations exceed what a casual home game demands.

Building Your Continuity System

The Episode Log

After every recording session, create an episode log entry:

• Episode number and title
• In-game date range (if you track in-game time)
• Locations visited
• NPCs who appeared (with brief notes on what they said and did)
• Key facts established (any world-building detail, rule, or piece of lore stated on air)
• Promises made (commitments by NPCs, foreshadowing by the GM, player declarations)
• Player theories (what the players theorized on air — your audience heard these and will track whether they were correct)
• Unresolved threads (anything that was introduced but not yet resolved)

This log is your primary continuity reference. It takes fifteen to twenty minutes per episode to create and saves hours of re-listening later.

The Fact Registry

Separate from the episode log, maintain a fact registry — a searchable database of every canonical fact established on air:

• World facts — Geography, history, magical rules, political structure, cultural details
• NPC facts — Names, descriptions, personalities, relationships, knowledge states
• Player character facts — Abilities, backstory details, relationships, established behaviors
• Timeline facts — Dates, durations, sequences of events

Each fact should be tagged with the episode where it was established. When you need to reference a detail during prep or recording, you can find it in seconds rather than re-listening to old episodes.

The Promise Tracker

A promise is anything established on air that creates an expectation:

• "I'll have the information for you when you return" — The NPC must have the information when the players return
• "The ritual takes place on the full moon" — The ritual must happen on the full moon
• "There's something wrong with this wine" — The wine must have a payoff
• Player: "I'm going to find my sister if it's the last thing I do" — The sister storyline must be addressed

Track every promise with:

• What was promised
• Who made the promise (GM narration, NPC dialogue, player declaration)
• Which episode it appeared in
• Whether it has been fulfilled, is pending, or was intentionally broken (with narrative justification)

Recording Session Continuity Practices

Pre-session review. Before every recording session, spend fifteen minutes reviewing:

• The last episode's log entry (what just happened)
• Any promises that are approaching their fulfillment timeline
• NPC states for characters who might appear
• Active storyline statuses

On-air hedging. When you are unsure about a fact, hedge rather than commit: "The scholar mentioned something about that — you'd need to check the library records" instead of stating a specific detail you might contradict later.

Post-session fact capture. Immediately after recording, while everything is fresh, update your fact registry with any new canonical details. This is the most important continuity habit you can build.

Edit-phase continuity check. If you edit your podcast, use the editing phase as a continuity check. Listen for details that contradict established facts. If you catch one, decide whether to edit it out, correct it in post, or leave it and address it narratively later.

Handling Continuity Errors on a Published Podcast

Despite your best systems, errors will happen. Options:

The in-narrative fix. Address the contradiction in a future episode as an intentional element: "The NPC lied about the date" or "the records were inaccurate — the real date is..." This only works if the fix is plausible.

The meta acknowledgment. Address it directly with your audience: "Hey listeners, we made an error in Episode 34 — the correct date is X. We're going with that going forward." Most audiences appreciate honesty.

The silent correction. In future episodes, consistently use the correct version and hope the error fades. This works for minor details but not for significant plot points.

The show notes correction. Add a correction to the episode's show notes. Listeners who care will find it.

Never pretend the error does not exist if your audience has noticed it. Acknowledging errors builds trust. Ignoring them erodes it.

Scaling Continuity for Long-Running Shows

Shows that run for 100+ episodes need enhanced continuity infrastructure:

• A dedicated continuity editor — A team member (or dedicated listener) who reviews episodes for consistency before publication
• A public wiki — A fan-maintained wiki that serves as a crowd-sourced continuity resource (verify its accuracy against your internal records)
• Arc-level continuity reviews — At the conclusion of each major story arc, review all continuity-relevant facts from the arc and verify consistency
• Canonical authority — Establish what counts as canon. Is it only what was said on air? Do show notes count? Do social media posts count? Clear canonical authority prevents disputes.

Running an actual play podcast and worried about continuity? Join the TransitMap waitlist — track every fact, promise, and storyline across your show's entire run with a visual system designed for the permanence of published audio.