When organizing chapters and setting records for a long novel, do not begin by storing everything in one place. Begin by assigning one owner to each type of value. A chapter index can own chapter order, a display record can own editor layout, and an export record can own publishing conditions. Once you also define where each change propagates and which owner wins a conflict, you can reduce contradictory updates across the project.
This article does not test whether the application returns to the same chapter, layout, and export settings the next day. It audits ownership, update source, propagation, and conflict priority for chapter, display, and export values.
Do not put three kinds of value in one “settings” field
A long-novel project commonly calls all of these “settings”:
- structural values such as chapter ID, title, order, and manuscript file;
- editing-display values such as writing and reading pane arrangements; and
- output values such as title metadata, included content, and publishing conditions.
They change for different reasons and serve different consumers. Renaming a chapter does not necessarily rename a display preset. Changing a split-pane arrangement does not change the novel’s reading order or export conditions.
When the values share one broad note, a stale chapter title in a layout can become ambiguous. Is it a harmless screen label or a value that will reach the published output? Organization begins by separating value types, not by moving more files.
Record owner, update source, consumers, and priority
Create one row per setting value with at least these fields:
- value name;
- authoritative owner;
- location where the value may be changed;
- screens or records that consume it;
- propagation condition; and
- conflict priority.
If the chapter index owns reading order, do not infer order from a file list or reading layout. Change the index, then update its consumers.
A display record can own the writing arrangement. It should agree with the chapters available in the project, but left, center, and right screen positions do not define the novel’s authoritative reading order. An export record owns output conditions; do not reconstruct those values from the display preset’s name.
Trace one C05 chapter-title change in one direction
Suppose chapter C05 changes from “Station in the Rain” to “Station Before Dawn.”
Update C05 in the chapter index first because the index owns the authoritative chapter title. Then inspect the tab label or working label that displays C05. If it still shows the old title, update it as a consumer of the index. If an output checklist receives its contents from the chapter index, pass the same change to that output check.
The goal is not to type plausible new text independently in three places. Fix the origin at the chapter index and treat display and output records as consumers. When a stale title appears later, the editor knows where to verify the current value.
A shorter screen label is a different value, not a new official chapter title. Give the display record ownership of that abbreviation and retain its relationship to the full title. Reusing one string for several jobs is what creates propagation confusion.
Resolve conflicts by value ownership, not modification time
Imagine that the chapter index says “Station Before Dawn,” the display label says “Station in the Rain,” and the output check says “Before Dawn.” Selecting the newest file is unsafe. The display may have been adjusted recently without any intention to rename the chapter.
Identify the value type first. For the official chapter title, consult the chapter index. For the abbreviated screen label, consult the display record. For publishing conditions, consult the export record. Priority belongs to the owner of that value type, not whichever file changed last.
Correct the stale consumer rather than rewriting the owner’s value to match it. If the owner’s row also lacks authority, pause the decision and ask the editor responsible for the project. This is an ownership and propagation question, not a recovery test.
Draw propagation arrows to find missed updates
Draw arrows from one owner to its consumers. For the C05 title, the map might contain chapter index → tab display and chapter index → output check.
After the change, inspect both consumers. Any old value is a missed propagation. Do not add reverse arrows: a display-label edit should not overwrite the chapter index, and an output abbreviation should not become the official title.
This map does not promise automatic synchronization. It remains useful in a manual process because it identifies the required checks. Mark an empty consumer as unverified, a mismatch as a conflict, and a value without an owner as requiring an editorial decision.
Use Rune Studio to view separate records, not to decide their authority
Rune Studio’s feature materials document multiple tabs, split panes, and named layout saving. This is documentation evidence, not evidence of the current screen or a completed operation. That documented scope is relevant when considering a view of a chapter index, a target chapter, and an export record together.
They do not establish automatic ownership detection, automatic propagation from the chapter index, or automatic conflict resolution. The project defines those owners and arrows.
A named layout is also not manuscript version history or an automatic backup of publishing settings. Keep the screen arrangement separate from the records that own project values.
Keep ownership auditing separate from next-day recovery
STUDIO-198 tests whether chapter, writing-layout, and EPUB-setting records can reconstruct the correct work state the next day. Its central result is recovery.
This article reaches a different result. Without closing the application, the editor should be able to explain who owns C05’s official title and which display and output checks receive that change. Restarting, reopening the same panes, and next-day recovery are not the acceptance center here.
Start with one value and one propagation map
Do not reorganize the whole novel at once. Select one value, such as the official title of C05, and write its owner, update source, consumers, propagation condition, and conflict priority.
Then draw arrows from that owner to two consumers. Inspect where the old value remains and whether any reverse update occurred. The useful result of organizing chapters, display settings, and export settings is not simply returning tomorrow. It is being able to explain where a change begins and where it must go.
If you want to view the separate records together, check the current tab, split-pane, and layout scope on the Rune Studio product page and begin with one C05 propagation map.
