Web novel worldbuilding management without conflicts

As a serial grows longer, one problem appears more often than simply forgetting a setting.

Mistaking an unwritten idea for a setting that has already been shown.

Your notes may say the protagonist's power has a cost, while the manuscript has never mentioned it. The opposite can also happen: one casual line in an early episode blocks a later development.

Worldbuilding management is not about explaining the whole world perfectly. It is about separating facts already shown to readers from ideas that can still change, and finding the evidence episode quickly when needed.

Separate settings by status before content

If every setting goes into one list, confirmed facts and ideas mix together. At minimum, separate these three states.

• Confirmed: facts that already appeared in the manuscript and can be known by readers
• Idea: thoughts that may be used later but have not been revealed
• Reserved: areas with a direction but no final decision until a later point

For example:

• Confirmed: Episode 3 shows that using fire leaves a burn scar on the protagonist's right hand.
• Idea: The scar may be a royal mark.
• Reserved: The exact meaning of the mark will not be fixed before episode 20.

This lets you change ideas freely while keeping the promises already shown to readers.

The important point is that what the author knows and what the reader knows are not the same. Do not mix them in the setting document. Mark the disclosure state clearly.

Attach the evidence episode to each setting

When a conflict appears, the slowest task is finding where the setting first appeared.

Write at least two things beside the setting.

• The episode where it first appeared
• The episode where it was last added to or changed

Teleportation can be used only once per day. First use in episode 7. Episode 18 reveals that repeated use costs memories.

With this note, you can distinguish the rule readers knew before episode 18 from the expanded rule after episode 18. Character ages, distances between places, item ownership, and foreshadowing status can be managed the same way.

A setting without an evidence episode may be a memo rather than a fact. If you are not sure whether it appeared in the manuscript, check the episode first.

When changing a setting, record the reason before the new value

Changing a setting during serialization is not automatically a problem. It often happens because a better development appears.

The problem is deleting the old value and losing the reason for the change.

A change record does not need to be long. One line with four items is enough.

• old value
• new value
• reason for the change
• episode from which the change applies

Travel time from the capital to the harbor: three days -> five days. Changed to match the number of nights in the chase scene in episode 12. Check the map explanation in episode 1 during the next revision.

When the reason remains, it is easier to decide whether earlier episodes must be revised or whether the new setting can apply from the next episode. If you later want to return to three days, you can avoid repeating the same problem.

Keep only one final reference document

When settings are scattered across notes, chat rooms, and documents, the same item remains in different versions. Confirming the latest one takes longer than writing.

It is fine to collect ideas in many places. But there should be one final reference document you check before writing.

Only author-approved content should enter that document. Even if AI summarizes material, it should be compared with the manuscript, edited, and approved before it becomes official.

Baroro's Official Wiki feature stores work settings as Markdown documents that the author can edit directly. AI may help draft updates, but the Wiki remains the author-managed reference, and the relationship graph is a visual reading of that document.

When the source is clear, fixing a setting means fixing one place.

Update for three minutes after finishing an episode

If setting management becomes a separate large task, it will be delayed. It lasts longer when you check only what changed today immediately after saving the episode.

1. Did a new character, place, or item appear?
2. Did a state change, such as an ability, relationship, or ownership?
3. Did you plant new foreshadowing or resolve old foreshadowing?

Add only the matching items and write the episode number. If nothing changed, you do not need to enlarge the document.

What matters is not the thickness of the setting document. It is how quickly you can find the fact you need.

When you find a conflict, choose one of three treatments

If a setting no longer fits, you do not always need to rewrite the older episode. There are usually three choices.

• Revise the earlier episode.
• Explain it as newly added information.
• Turn it into something a character misunderstood.

The right choice depends on what the reader already knows and whether revision would change the core of the scene. The important thing is not to cover the conflict silently, but to handle it in a way that makes sense inside the work.

If desires and secrets between characters have become complex, record the event that changed each relationship and the disclosure range as in how to make a character relationship map.

The purpose of setting management is not to build a perfect encyclopedia. It is to find the facts needed for the next scene and keep the promises already made to readers.

Create a new work in Baroro and record the settings that actually appeared in the first episode.