Extending and Maintaining the System
Extend the campaign by solving a real continuity problem, not by adding structure for its own sake. Before creating a new type, identify the durable question it must answer, the record that owns each fact, who will update it, and which other records need a reference to it. If an existing type already owns the information, add content there rather than creating a parallel registry. A focused, consistently maintained ledger is more useful than a comprehensive schema nobody updates.
Separate rules, records, and presentation
A file type defines the shape and meaning of a category of records. A data file is one instance of that category. GM Instructions contain private operating procedures and secrets; handbooks explain player-facing rules or builder-facing design intent; individual records hold campaign facts. Keep those responsibilities distinct. Do not put secret twists or adjudication instructions in a public handbook, and do not reproduce a complete schema as prose in the Builder's Manual.
A useful field stores a fact that changes, a choice that matters, or a stable definition owned by that record. Avoid storing a second copy of a value already owned elsewhere. Prefer collections for repeating entries rather than numbered fields. Use references for relationships between files. Derived values belong in calculations only when their source data are reliable and the derivation is stable; otherwise store a clear, deliberately maintained state. Presentation labels and formatted summaries should not become competing canon.
Add systems in deliberate layers
The project has working foundations for the clock, scheduled events, session history, relationships, quests, people, factions, locations, routes, and equipment. Other possible systems—seasonal climate probabilities, regional supply and demand, detailed NPC routines, rumor truth and spread, local law and reputation, and character-development milestones—need additional design before they become authoritative. Do not imply that a full subsystem exists just because a field can hold a note about it.
For each proposed system, start with a small loop: what triggers an update, what choices can change the result, what must be recorded, and how a later session reads the current state. For seasonal weather, for example, establish a region's climate and plausible transitions before assigning probabilities. For markets, tie stock and prices to supply, demand, events, and trade routes. For rumors, track who knows a claim and whether it is confirmed, false, or unresolved. Add detail only when play demonstrates that the loop needs it.
Preserve consistency as the project grows
After changing a type's structure, review its representative records and any records that reference it. Additive optional fields are generally less disruptive than required fields, renamed keys, or changed meanings. Never silently migrate an established fact into a new interpretation. Preserve chronology when correcting records, and leave a clear explanation in the appropriate log when a change affects canon.
Use stable, understandable names and keep each record's purpose visible. Avoid creating a file for every incidental character, shop, rumor, or object; promote it when it gains ongoing goals, relationships, resources, or consequences. Review whether linked records agree after travel, time advances, purchases, event resolutions, and scene saves. The system is successful when it makes the next session easier to run and the world more consistent—not when it has the largest number of fields.