Why One Post Per Day Demands Better Plot Documentation

What One Post Per Day Actually Means at Scale

At one post per day, a contested combat with four participants takes a minimum of four days to resolve one exchange. A multi-threaded scene with IC posts across three different subforums can accumulate forty posts before the scene concludes. A campaign that runs for six months has produced approximately 180 IC posts — spread across an unknown number of threads, each with its own pagination, each accumulating in a forum archive that your host may or may not preserve indefinitely.

Guide to PBP/PBEM – Roleplaying Tips puts a specific number on this: at one post per day, a single combat round can take a month. Without plot documentation, the continuity of that combat — who said what, what the tactical situation was, which NPCs were present — lives entirely in your memory and in the archive. At the pace of daily posting, memory decay is measured in days, not weeks.

Replication and Analysis of Ebbinghaus' Forgetting Curve – PMC shows only 25% of plot information is retained after one week without reinforcement. In a one-post-per-day pbp campaign, "one week" is seven posts. The context you had for day one of a scene is largely gone by day eight.

The documentation problem isn't that forum GMs are disorganized. It's that one post per day pbp is a specific format with specific documentation requirements, and most GMs approach it with systems designed for a very different format. The daily post GM's challenge is that plot documentation needs to be current as of the last post, not as of last week's session notes — play-by-post post scheduling means the campaign is always mid-session, and the documentation system needs to reflect that.

Why Daily Posting Breaks Standard Note-Taking

Context Switching – Atlassian identifies context switching as a significant cost: each mental context switch costs approximately 23 minutes of refocus time. Reading back through forum pages to reconstruct plot context is a direct equivalent. A forum GM who needs to check what an NPC said three weeks ago in an archived thread isn't just retrieving information — they're paying the context-switch cost every time they do it.

At a weekly table session, you can hold the prior session in memory reasonably well. At one post per day, you're technically "in a session" continuously, which means every IC post requires you to be current on a campaign that has advanced continuously since the last time you wrote. The documentation system you use needs to make that retrieval instant, not a ten-minute re-read.

Standard note-taking approaches fail this requirement in predictable ways. Session summaries are too infrequent (you can't wait a week between documentation updates in a daily format). NPC wikis are too detail-heavy (you need current status, not full histories). Flat OOC threads are unsearchable without forum-native search, which most platforms handle poorly. The pbp pacing fundamentals post covers the three pacing variables — post cadence, thread rhythm, arc tempo — that your documentation system needs to support. Without documentation that makes current state retrievable in under two minutes, managing those variables requires either constant re-reading of the archive or guesswork.

What daily posting actually requires is a plot documentation system built around current-state snapshots, not historical records.

The Station Log as Daily Documentation

The transit-model station log is specifically suited to one-post-per-day documentation because it captures current state in real time rather than summarizing history after the fact.

Each IC post that advances a plot thread gets a one-line station entry: transit line, station number, thread reference (name plus page number), IC post date, and a single sentence describing the story beat. That's the whole entry. At one post per day for a campaign with four active transit lines, you're logging approximately four lines of documentation per day — a negligible overhead that compounds into an invaluable reference.

The compound value appears at six weeks: instead of reconstructing thirty forum posts to find out where the guild succession arc stands, you open your station log and read five entries covering the last month of that line. The thread reference in each entry gives you the exact page number for the IC post if you need the full text. You're never excavating the archive — you're reading a map.

Cognitive Structures in Comprehension and Memory of Narrative – ScienceDirect shows that recall of story facts depends on structural centrality — undocumented subplots are recalled least reliably. The station log makes every subplot structurally central by giving it a named entry in your documentation system.

StoryTransit automates this logging specifically for play-by-post forum GMs. When you log an IC post in the tool, it creates the station entry, timestamps it, and connects it to the existing transit line. Your documentation is current as of your last IC post, not as of last week when you had time to update your notes.

The Minimum Viable Documentation Set

Not every forum GM needs a comprehensive campaign wiki. At one post per day, you need four things — and only four things:

Active line status. For each active transit line: the line name, the most recent station, the IC thread and page where that station lives, and the date. This is your current-state map. It takes sixty seconds to update after each IC post that advances a line.

Dormant stop registry. Every subplot that's been introduced but isn't currently advancing. Name, last station, date dormant, revival trigger. Participant Dropout as a Function of Survey Length – PMC shows that longer, less structured engagement dramatically increases dropout at each step — the dormant stop registry prevents the compounding dropout risk of forgotten subplots.

NPC current-state list. Not a biography — a one-line current status for each NPC who has been active in the last month. "Merchant Aldren: missing since IC Post 47; last seen in Merchant Quarter Thread #2, Page 3." That's sufficient for daily posting purposes.

Thread index. A numbered list of all active forum threads with their current page numbers and last IC post dates. Updated weekly. This prevents the context-switch cost of searching for threads you know exist but can't immediately locate.

Never Unprepared: The Complete GM's Guide to Session Prep – Engine Publishing recommends systematic prep documentation covering NPCs, clues, and plot criteria as the foundation of consistent game management. At one post per day, the prep cycle is continuous — you're never "prepping for a session" because the session never ends. Your documentation system needs to support continuous prep, not session-batch prep.

A well-documented campaign can maintain any sustainable cadence because the GM isn't burning prep time on archive retrieval. The forum combat rounds problem — where a single combat turn takes weeks — is specifically where daily documentation pays off, since combat continuity breaks faster than any other pbp context at daily posting frequency.

For actual play producers tracking narrative across long episode runs, the thread tracker setup used in podcast production addresses the same documentation architecture — current state plus history, structured for retrieval rather than chronological reading.

The Documentation Review Cycle

Maintaining documentation at daily cadence doesn't require a daily documentation session — it requires integrating documentation updates into the IC posting workflow itself. The practice: before you write an IC post, scan your active line status. After you write an IC post that advances a plot thread, add one station entry. Total additional time per post: ninety seconds.

Once per week, run a five-minute review: scan the dormant stop registry for any stops that have exceeded their intended dormancy period, check the thread index for any threads that have changed page count without a corresponding index update, and verify that the NPC current-state list reflects any developments from the week's IC posts. This weekly review catches the drift that accumulates when individual post updates are incomplete.

Once per month, run a fifteen-minute campaign map review: check whether any transit line's last station is older than three weeks (candidate for revival or closure), verify that all dormant stops still have valid revival triggers given current campaign state, and close any lines that have genuinely resolved rather than simply gone dormant. The monthly review keeps the map legible — an underpruned map fills with resolved subplots that create noise when you're scanning for active threads.

The documentation threshold. Not every IC post needs a station entry. The rule is: log when the post advances a named transit line. An IC post that describes atmosphere, character interaction without plot advancement, or NPC dialogue that doesn't move any arc forward doesn't require a station entry. Posts that introduce new information, resolve ambiguity, or set up a future development get logged. Over a typical campaign week, this means logging approximately three to five IC posts out of seven, not all seven.

At that pace, the documentation overhead at one-post-per-day is under ten minutes per week. That's the price of plot continuity across a forum campaign that accumulates hundreds of posts over its lifetime.

Documentation as Plot Continuity Insurance

The documentation system isn't separate from running the campaign — it's what makes running the campaign at daily cadence sustainable. The station log, dormant stop registry, and thread index collectively function as plot continuity insurance: when something goes wrong (a player ghosts, a thread gets buried, your memory of an NPC's motivation is fuzzy), you retrieve from the documentation rather than from memory or from a forum search.

StoryTransit is purpose-built for play-by-post forum GMs who need documentation that keeps pace with daily IC posting. The logging overhead is under two minutes per post — low enough to maintain consistently, high enough to produce a reference system that genuinely works. Join the Waitlist for Play-by-Post GMs to access daily-cadence documentation tools designed for the one-post-per-day forum GM workflow.