Preparing a release
¶ Reusing continuity between releases
Good continuity reuse is not copying everything forward. It is deciding what belongs to the whole project, what should seed the new release, and what should be retired because the previous book already paid it off. Dizire Engine gives you a specific handoff path for that work.
The release planner is the clearest view of continuity handoff because it shows the before-and-after state of each release inside the same project sequence.
On this page
- What continuity should be reused
- What the app carries automatically
- What belongs at project, series, and release level
- How to clean inherited continuity
- How to verify the handoff
Overview
¶ Continuity reuse starts with state, not with copying old notes blindly
Dizire Engine treats release continuity as a handoff problem. The key question is not, “How do I duplicate the previous release?” It is, “What from the previous release should still be true, unresolved, or important at the start of the next one?”
That is why the core release continuity fields are Opening state, Carryover threads, and Ending state. They describe transition, not just storage.
Automatic handoff
¶ The next-release shortcut already reuses the most obvious continuity bridge
When you create the next release from the project detail page, Dizire Engine automatically seeds the new release from the latest one. The previous release's Ending state becomes the new release's Opening state, and the previous release's Carryover threads are copied forward. The new release premise is also seeded from those continuity signals before it falls back to older context.
- If the prior release ended with a new status quo, that becomes the starting condition for the next book.
- If unresolved threads still matter, they remain visible in the new release scaffold.
- If the prior carryover notes are vague or too broad, the new release is your chance to tighten them rather than preserve the vagueness.
Storage layers
¶ Use each continuity layer for a different kind of memory
Continuity only stays usable when the right information lives at the right level.
- Project continuity notes hold world rules, recurring promises, and long-range arc logic that outlive any single release.
- Series continuity notes hold the recurring rules of one sub-line inside the project.
- Release continuity fields hold the opening condition, unresolved threads, and required ending condition for one book.
- Chapter revision notes are for local repair work and should not be the only place a real continuity rule exists.
If a rule should still matter two books from now, move it upward. If it only matters to fixing chapter six, keep it local.
Cleanup
¶ Edit the inherited continuity before you generate a new blueprint
Automatic continuity reuse is a starting point, not a finished answer. As soon as the new release exists, open it and review the inherited fields before running any chapter planning or drafting tools.
- Rewrite Opening state so it describes the real new-book opening, not just the previous ending verbatim.
- Delete paid-off threads from Carryover threads so the new release is not tracking ghosts.
- Move any truly evergreen rule into project or series continuity instead of repeating it inside every release.
- Use Notes & Planning for temporary author reminders that should not become structural continuity fields.
Continuity cleanup is easier when the project summary, continuity notes, and new release fields can be compared together instead of being spread across disconnected notes.
Verification
¶ Use the analyst tools when the continuity is too complex to trust by memory
The workspace Story Analyst and Codex Builder are useful once the manuscript starts growing again. They can flag continuity warnings, unresolved arcs, conflicting details, forgotten characters, and codex findings that suggest a recurring rule should become permanent project guidance.
That makes them especially useful when the release line has grown beyond what you can comfortably hold in memory. Reuse is strongest when the continuity is both inherited and checked.
Next step
¶ Where to go next
Once the new release's continuity is stable, the next release-prep question is how the front and back matter pages should be configured for that book's package. Continue to Configuring title page, copyright, acknowledgments, and about-the-author pages.