Skip to main content
Blog

ai writing · writing

Canon vs. Sandbox: How to Try a Wild Idea Without Poisoning Your Story Bible

JP LeBlanc · September 27, 2026 · 6 min read

A file browser panel split into Canon and Sandbox columns, with a sandbox chapter card mid-drag crossing into Canon under the label 'promote'.

Kill a character in chapter 9. Two weeks later, curious how the book would read if she'd lived, draft an alternate chapter 14 where she survives the accident and shows up at the funeral instead of causing it. Read it, decide the original was right, and delete the alternate. Move on. Then ask Ash to draft chapter 22, and she's alive again, walking into a scene she has no business being in. Not because you forgot to kill her. Because the model reading your manuscript for continuity never forgot the version where you didn't.

That's the specific failure canon and sandbox chapters exist to stop, and it's a structural problem, not a prompting mistake. Every chapter AIStoryHub generates pulls in what came before it: title, beats, a rolling summary of prior chapters, the story's world bible. That's the entire mechanism that keeps chapter 22 consistent with chapter 9. The same mechanism has no way to tell the difference between "this happened" and "I was trying this out" unless you tell it, which is exactly what canon and sandbox chapters are for.

One column in one table

Chapters and scenes live in a single database table, story_nodes, alongside characters, locations, and every other world-bible entry, distinguished by a node_type field. Chapters and scenes carry one more field the others don't: is_canon, a boolean. A chapter with is_canon true or unset (new chapters default to true) is canon. A chapter with is_canon set to false is sandbox. That's the whole schema. There's no separate table, no permissions system, no publish state attached to it beyond that one flag.

What actually gets excluded

The flag gets checked in more places than you'd guess from how simple it is:

  • Generation context: the aggregator that builds continuity for a new chapter queries only canon chapters, plus the one currently being written (so a sandbox draft can still see the real story leading up to it, more on that below).
  • Voice fingerprint: the sample prose used to anchor your voice is pulled from canon chapters only, so an experimental scene in a style you're testing and rejecting can't quietly bend your voiceprint.
  • Continuity checker: when it scans your manuscript for contradictions between chapters, the client sends it the on-screen text of canon chapters only. Sandbox chapters are excluded before the request is even built.
  • Reader page, share links, and the public API's chapter list: canon by default. Export defaults to canon-only too, with a checkbox to include sandbox chapters in a personal download, since sometimes you want your own discarded drafts on your own hard drive even if nothing else should see them.
  • Manuscript word count: sandbox chapters don't add to the total, however long they run, so an abandoned experiment never inflates the number you show anyone.

None of this is a content filter reading your prose for spoilers. It's one boolean, checked at the query level, everywhere the app decides what "the manuscript" means.

How you actually mark one

In the file browser, chapters sit in two groups: Canon and Sandbox. You drag a chapter row across the line between them, and the flag flips. There's also a dedicated button to add a chapter straight into Sandbox, for when you know going in that you're writing an experiment rather than the next real scene. Sandbox rows even look different at a glance: no chapter number, an outlined instead of filled marker, italic title text, and an untitled one reads as "Experiment 1" instead of "Chapter 1." You're not supposed to mistake one for the other while scrolling past it.

The one subtlety worth knowing: sandbox chapters still see canon. When you're generating inside a sandbox draft of chapter 12, it still gets the real chapter 11's continuity, your characters, your world bible, all of it. What it doesn't get is a say in chapter 13. A sandbox chapter can build on everything true so far and still never become true itself.

World entries don't get this option

Here's the boundary worth being honest about. Characters, locations, factions, species, items, and lore all live in that same story_nodes table, but the canon-context builder that assembles them for generation doesn't check is_canon on them at all, it only checks whether they've been deleted. Your world bible has no sandbox. A character record or a piece of lore is always in context the moment it exists, whichever chapter it's attached to. If you want to try out a location or a faction without it counting yet, there's no flag for that today. Delete it, or don't create it until you mean it. Canon and sandbox is a manuscript-chapter concept, not a story-bible one, and it's worth knowing exactly where that line sits before you assume it covers more than it does.

Draft three, promote one

This is the actual workflow the split is built for. Pick your pivotal scene, say the one where your protagonist either forgives her sister or doesn't, and instead of agonizing over which version to commit to the manuscript, write both. Create two or three sandbox chapters in that slot, one per version, and generate or revise each on its own, all of them drawing on the same real canon up to that point. Read them side by side. Drag the one that works into Canon. Leave the others in Sandbox, where they'll sit indefinitely without touching a single later chapter, or delete them once you're sure. Nothing downstream has to be rewritten because nothing downstream ever saw the versions you didn't pick.

There's a second-order case that only shows up once you publish. We could have left is_canon live at read time for a published checkpoint, which is the simpler thing to build. It's also wrong the moment a reader can open a book you've already shared: promote a sandbox chapter to canon after publishing, and a live check would slip new content into a version nobody clicked publish on again. Demote a chapter out of canon after publishing, and it would vanish from a copy that already had it. So canon status gets pinned into the snapshot at publish time, in both directions. A chapter you demote later stays visible in the checkpoint that already shipped with it. A chapter you promote later stays invisible in that same checkpoint until you publish again. The book a reader has open never quietly changes underneath them just because you kept sandboxing behind it.

What this isn't, yet

The continuity checker reads up to 100,000 characters of your canon chapters in one pass and reports contradictions between them. It reports. It doesn't rewrite anything on its own, and moving a canon fact doesn't ripple changes into every chapter that referenced the old version. If chapter 3 establishes a character's eye color and chapter 40 contradicts it, the checker flags it as a conflict for you to fix by hand or hand to Ash as a specific instruction. Canon and sandbox solve the problem of a discarded draft leaking backward into your continuity. They don't solve the separate problem of a canon change propagating forward. That's a different, harder feature, still ahead of us, not behind us.

Reading is nice. Writing is better.

Try the thing we keep writing about.