This project is a canon-grounded Star Wars sandbox at the opening of the Clone Wars. When you add to it, preserve two things at once: the recognizable 22 BBY setting and the player's freedom to change what happens. Canon characters, planets, institutions, technology, and baseline events should remain faithful to the era. Players may create original characters; plausible ordinary people may fill gaps where canon provides no named person. Do not present invented details as established canon or use an original character as a replacement for a major canon figure.
Keep the source of truth clear
Use each kind of content for the job it does. Lore explains the setting; a character record describes a person; a scene seed offers a situation; a storyline tracks a situation over time; and a state file records what is true now. Do not use a scene seed to quietly make a future canon event happen early, or treat a rumor as confirmed fact. Keep the distinction between world truth, public knowledge, a character's knowledge, and speculation visible whenever it matters.
The campaign opens in 22 BBY, Month 4, Week 3 after Geonosis. The Timeline is the unaltered chronological baseline; Canon Event records indicate whether particular events are upcoming, happened, altered, or prevented. The World State is authoritative for the campaign's current reality, and Scene State describes the immediate situation. When player actions change conditions, update current state and record the divergence rather than trying to restore canon. Later canon events are possibilities with conditions—not mandatory plot beats.
Build situations, not scripts
A good scene seed gives the GM a concrete situation, a reason it matters now, and several plausible ways it could develop. Keep its hook open: it should not dictate the player's role, allegiance, feelings, or solution. Complications are possible developments, not a checklist the GM must force into play. Named canon characters may appear when their location, date, and interests support it; avoid making a scene unusable if a named character is absent. Original minor characters are appropriate when a scene needs an ordinary witness, clerk, worker, or local voice.
Storylines can connect situations across time, but they are opportunities, not rails. Define a clear trigger, what changes if nobody intervenes, and what evidence or consequences can surface. A player may refuse, leave, or abandon a thread; let it expire or continue in the world without forcing it back into their story.
Keep the no-dice resolution fair
The player chooses their character's actions, not guaranteed outcomes. When an outcome is uncertain, ground it in the character's demonstrated capabilities, chosen method, preparation, resources, position, opposition, environment, and recorded state. A feasible action may succeed at a plausible cost; a difficult one may yield partial progress, a setback, or failure because of a real obstacle. Make serious or irreversible stakes understandable before the player commits. Do not use hidden rolls, arbitrary penalties, character fame, or plot convenience to decide the result. Non-player characters retain their own motives and choices.
Model money without a universal wallet
Credits are useful because jobs, travel, supplies, repairs, and debts create meaningful choices. They are not a character score and not every person begins with the same purse. The Player's Handbook contains the original-character starting profiles; use the matching role only when the player has chosen that origin and has no established financial history. For canon characters, use their established assets at the campaign date rather than assigning an original-character preset. Military issue, Jedi Order support, official expense accounts, personal wealth, ships, and debts are distinct resources.
The Ledger should begin only after a player character and financial situation are established. Its opening balance is the sum of actual cash and bank funds; do not invent a bank-transfer row to manufacture that sum, and record no income, rent, or loan before it occurs. Set weekly income and expenses from the character's real work and residence. Price entries are generally play estimates, not universal canon tariffs: calibrate them to the War Economy guide, the relevant item or business, local conditions, quality, legality, and wartime scarcity. Keep ordinary food and lodging far below droid, speeder, starship, or government-scale equipment costs. Explain unusually high prices through a concrete factor such as a blockade, rarity, restricted military supply, luxury venue, or damaged condition.
Keep connected files consistent
Before adding or revising a connected entry, check its file type, required fields, reference targets, location, date, and relevant existing records. Use the existing file type and reference slug where one fits; do not create a parallel type merely to avoid a small schema or content decision. Keep repeated systems and decisions in their owning files, and update only the state that actually changed.
For a change that affects multiple layers, follow the chain: establish the event or action, update the authoritative world state, update the affected people, factions, relationships, resources, and knowledge, then carry forward only the consequences that are justified. Keep the Day Log and Session Record tied to actual in-world play; do not fill them with events that have not happened. When a front or canon event is in the future, keep it dormant until its conditions are met or play changes them.
Review before release
A useful final pass asks: Does this fit the campaign date? Are its references real and correctly typed? Does it contradict current state or duplicate an existing hook? Can the player choose more than one reasonable response? Are consequences clear without being predetermined? Does the entry distinguish canon fact from original material? Does its price fit the scale of the object, local market, and the project's economy guidance? If any answer is uncertain, state the uncertainty or leave the detail open instead of inventing certainty.
After a build batch, record what changed and what still needs attention in the project's Build Change Management handoff. That log is a planning aid, not a source of in-world canon. Keep it current so the next builder can pick up the work without relying on memory.
