Extending the System

Sooner or later you will want something the four file types do not cover — a faction, a spell, a specific creature with no sheet, a new category of gear. This chapter is the decision framework for when to reach for a schema edit and when to resist it.

First: can the existing types hold it?

Most things you want to add are already speak-able in the four types, and you should prefer that. Ask the question "is this a Character, Equipment, Location, or Game-Start?" honestly, and most answers are yes:

• A faction is not a fifth type — it is a Location (the space it controls) plus a GM Instruction (how it acts) plus maybe a Character for its leader. Three existing files model it completely.
• A named NPC monster is a Character with its stats, even if the players never "play" it.
• A spell or ability a character uses is a row inside that Character's abilities array, not a new type.
• A distinctive object is Equipment.

Four types deliberately cover a lot. When you feel the itch for a new type, spend effort first on seeing the thing as a combination of the existing four. This keeps the system's one core strength — a small, searchable, cross-referenced web — intact.

When you genuinely need a new type

Sometimes the existing types genuinely cannot hold it cleanly. The signal is repetition: you find yourself typing the same bundle of fields into the notes of file after file, or re-stating the same concept across many unrelated entries. That repetition is the system telling you the concept wants a file of its own.

Before you build a new file type, step through the design checklist:

1. Name it as the single anchored concept. The type is one thing, folded in one folder, one schema.
2. Give it a small, enumerated core. Model the fields that the machine reasons over as choices and ranges, not free prose. If you cannot name its categories, you are not ready to type it.
3. Decide the references. Which existing files will point at it, and what will it point at? Follow the reference direction rule: the user of a thing carries the reference, not the thing itself.
4. Decide the computed layer early. Any derived value belongs as a formula on the schema, never hand-typed into files.
5. Keep it original. A new type must be native to SPAECIMH's idiom, not a familiar mechanic from another system wearing a new folder.

This is also the point to read the Creating File Types and Updating File Types guides — they carry the mechanical how-to for registering a type, and this manual carries the judgment about whether you should.

Editing an existing schema — the restraint rule

More often than adding a type, you will be tempted to add a field to one. Resist until the field earns it. The test:

• One character, many values (a skill list, a connection, an ability) → an array field, or a row inside an existing array. Not a new top-level field per item.
• A value the system must enforce (a category that gates combat) → an enumerated field.
• A value the story needs but the machine does not → it is prose; it belongs in description/notes, not a new field.

The classic mistake is a schema that grows one field per idea until the file type is a sprawling Wiki. A good schema is small, enumerated and cross-referenced — the way Character already is. When you edit, edit the expression, the enum, or the reference target. Do not bolt on a new scalar every session.

Genre adaptation without breaking the wheel

SPAECIMH claims to be universal, and the way to prove it is to adapt it to a new genre without touching a formula. The currency is text — call gold credits. The setting is text — flavour the four roads. The monsters are Character files — rebuild them with the same six attributes. The system's mechanics (4d6, derived attributes, ORIGIN tiers) are genre-agnostic by design, and that is the point of originality: a system that never copied anybody can be dropped anywhere without owing anyone anything.

Adapt by adding entries, not by editing mechanics. The moment you change the check formula for a genre, you have broken the build. Keep the math native and let the fiction change around it.

The final audit

Before you call a build done, run it through the system's own rules:

• Are derived values left to the sheet, never hand-typed?
• Is every reference pointing at a real, existing file?
• Are the enumerated fields inside their enums?
• Does any requested edit change a formula that should stay untouched?
• Would the world you built still work as a dynamic system — something that runs on its own once seeded — rather than a script you have to narrate line by line?

Answer those honestly and the system will carry whatever you build. Answer them casually and you will quietly trade SPAECIMH — a small, coherent, machine-run universal system — for a pile of files that no longer agree with each other. Build like it's load-bearing, because it is.