How AI Reads Your Session Notes (and What It Does With Them)

An AI campaign assistant works by giving the model two things at once: a structured record of what’s true in your campaign, and the session notes to compare against it. That pairing is the whole trick. It turns an open-ended request like “read my notes and tell me what’s wrong,” which language models are unreliable at, into a bounded one: “here are the facts as of session 5, here are tonight’s notes, show me where they disagree.” Models are good at that. Here’s what’s happening under the hood, using StoryGuard as the example, since it’s the one we build.

The naive version, and why it underdelivers

Paste six months of session notes into a general chatbot and ask what you’ve contradicted. You’ll get a confident list that’s part real and part invented. The chatbot has no source of truth. It compares your notes to its own blurry memory of your notes. It forgets details across a long log, it can’t tell which session came first, and it flags an NPC’s lie as your mistake, because it doesn’t know the NPC was lying.

A purpose-built tool removes the guessing by giving the model the facts explicitly. That takes a few pieces.

Piece 1: a codex, not just a pile of notes

The foundation is a structured record of your campaign. Instead of a paragraph about the ferrywoman, there’s an entry:

Type: NPC, PC, faction, location, item, quest, event, lore, or house rule. The type tells the model what to expect. An item has an owner. A quest has a status. A house rule is something nobody gets to break.
Facts: short pairs like status: alive, location: Saltmere harbor, owner: Kestrel.
Links: Hollis Brand hired the party. The Drowned Choir wants the Sunken Crown.

A fact buried in a paragraph is invisible to a checker. A fact stored as a value is something it can test. This is the same codex idea behind the manual tracking system, made explicit enough for software to read.

Piece 2: state by session number

Campaigns change constantly, so a codex that only stores current values isn’t enough. StoryGuard records each change against the session it happened in: Old Wren’s status became dead in session 2.

That lets the checker reason the way you do. Wren speaking in session 1 is fine. Wren greeting the party at the dock in session 3 is a contradiction. A flat fact sheet can’t make that distinction. A record with session numbers can.

Piece 3: secrets, and when they came out

Each entry can be marked secret, either the whole thing or a single fact, like the mayor’s real allegiance. When the party learns a secret, you note the session.

This matters because you, the GM, write about secrets in your notes all the time, and that’s not a mistake. The checker is told so explicitly. It only flags a secret when the notes show the party or a player character knowing or acting on it before they found it out. The same record is what keeps secrets out of player recaps.

Job 1: “What changed?”

After a session, you click What changed? The model gets your codex and the session’s notes, and its only job is to list the changes: who died, who moved, which item changed hands, which secret came out, which new NPC deserves an entry.

Every change comes back as a proposal, never an edit. You approve the right ones, reject the wrong ones, and your codex is current. Nothing in your campaign changes without you clicking yes.

Job 2: the continuity check

Before your next session, the checker sends the codex (as of that session), the relevant session notes, and a clear instruction: find where the notes contradict the established facts. A few details make this work:

It’s a comparison task, not a memory task. The model is told the facts, not asked to recall them.
Your @mentions narrow the search. When you link an NPC in your notes, the checker knows that entry is really in the scene and checks it first. A name that only appears in passing gets lower confidence.
Ordinary table uncertainty isn’t flagged. A rumor the party heard, an NPC lying, a player character’s wrong guess: these are normal in a game. The model is told to leave them alone unless your notes present them as established fact.
Each flag points at the exact sentence and the fact it contradicts, with a suggested fix. You can check it in seconds instead of trusting it.

Job 3: the recap

Finally, the recap. The model gets the session’s notes plus a list of everything still secret as of that session, and writes a short, readable summary for your group chat. Secrets are left out. If something slips through anyway, you get a warning naming the secret before you post. (We wrote a separate guide on writing recaps players actually read, with or without a tool.)

What it still can’t do

Being honest about the ceiling:

It only knows what’s written down. A detail you improvised and never noted isn’t checkable. What changed? helps, but only if it’s in the session notes somewhere.
It doesn’t know your system’s rules. It doesn’t track hit points, spell slots, or whether a grapple was legal. It tracks people, places, items, quests, and what happened.
It makes mistakes. False positives happen. Treat every flag as a question, not a verdict, and mark intentional contradictions as intentional so they stop coming back.
It can’t judge fun. Whether a twist lands, whether a villain feels earned, whether the pacing works: that’s still yours. More on the boundary in can AI help you run a campaign?

Seeing it in practice

Every new StoryGuard account opens with an example campaign, Tides of Saltmere, with a contradiction already planted: Old Wren dies in session 2 and greets the party in session 3. You can run the check, try What changed?, and draft a recap in a couple of minutes, so you’re judging the actual output instead of this explanation. Your campaign isn’t used to train AI models, and if you have your own Anthropic API key, you can connect it and run everything on your key.