Extending the System

The file types are a skeleton, not a cage. The moment your world needs a shape the skeleton doesn't have — a faction with its own agenda, a relic, a species with mechanical traits, a corruption table, a vehicle — you have two options, and only one of them is right: create a new file type.

Jamming a faction into a character's notes, or a mission into a location's description, works until the moment you want to search, link, or compute. Then it fails. A structured type gives you a folder, consistent fields, search, and reference links — the same superpowers the starter types enjoy.

The pattern for a new type

1. Name the thing as a singular noun. The type is what one of them is called: Faction, Relic, Species, Mission. The folder that holds them is the plural.

2. Define the fields the rules actually reference. Ask what the table needs to run this thing. A Faction needs a side, goals, assets, and relations. A Mission needs an objective, a location, an opposition, and a reward. Define those fields — not a kitchen sink. Every field you add is something every future entry must fill.

3. Use reference fields to connect, not copy. If a mission takes place at a location, point at the location file. If a talent belongs to an archetype, point at the archetype. If a relic is also wargear, make it a Weapon or Armor entry, or reference one from the relic. The workspace resolves references automatically; your job is to keep slugs stable.

4. Keep computed fields for derived math only. If a new type has a value the table can compute — a modifier, a total, a threshold — define it as a computed expression over the entry's own fields and its references. If it's just a number you type in, it will drift.

5. Create the folder and the first entries. A new type is only real once it has files. Seed it with two or three strong examples that model the convention, then build out.

Adapting to another setting

The schemas are deliberately generic — attributes, wargear categories, location types — while the rules live in the handbooks. That split is what makes the whole project portable. To run a different system or setting:

• Swap the flavor content. Replace example characters, wargear, and locations with your own; the types don't care.
• Rewrite the handbook chapters. The Basic Rules Reference chapters are the system's rules; the Player's Handbook chapter titles stay, but the content follows your system. Keep chapter ids stable so links don't break.
• Keep the shape. The conventions in this manual — references over duplication, honest weights, secrets in GM Instructions, atmosphere vs. description — survive any setting. They are habits, not flavor.

What not to do

• Don't create a type for one entry. A "Ship" type for a single voidship is overhead; make it a Location with a note. Create the type when you can see a folder growing.
• Don't duplicate an existing type. A faction leader is still a Character. A faction's flagship is still a Location. A relic that is a gun is a Weapon with a rarity of Extremely Rare. Extend with prose and references before you invent a parallel shape.
• Don't store derivable values. If the system can compute it, let it. Hand-typed totals are the number one source of stale sheets.

Two platform facts worth knowing before you extend

Creation wizards only exist for designation: "character" types. A creationFlow on any other type — a Faction, a Species, a Relic — validates locally, pushes without complaint, and then silently never appears. This was confirmed the hard way: a full wizard built on the Framework type never played, while the same shape on the NPC type worked immediately. Do not give a content type the character designation to unlock a wizard; that also makes it playable and assignable to a player, which is not what a Faction is.

So the way people extend content types is by copying a record: duplicate an existing file, delete the copy's $craft block so the server mints a fresh identity, rename it, and edit. Every shipped record is a working template — the twelve Faction files each carry complete Background and Objective tables, and the twenty-seven Archetypes cover all four Tiers. Copy the closest one.

Designation, name, category and contentType are app-managed. They cannot be changed from the workspace at all — editing them in a local type file is not even detected as drift. Set them in the Craft app, then craft pull.