GM Instructions and Context Strategy
Craft does not provide a universal hidden combat engine, memory system, quest tracker, or relationship tracker. A mechanic is reliable only when its rules, state, live files, and context strategy work together. Treat that as a four-part contract for every subsystem you add.
1. Rule
Write the procedure that tells the GM when and how the mechanic operates. Long-lived System principles can live in the always-on Palladium Core GM Instructions. Detailed reference rules can live in searchable Rule files. Short event-specific behaviors can use triggered GM instructions in a finished World.
2. State model
The schema must provide writable fields for anything that changes. If a quest can be Active, Failed, or Complete, the quest type needs a status field. If combat spends actions, some state record needs attacks remaining. If armor takes damage, the particular armor instance needs current durability somewhere writable.
3. Current state
A schema alone does not create state. The World needs actual files carrying the current values: Character records, encounter trackers, quest files, campaign clocks, relationship records, inventories, or whatever the mechanic uses.
4. Context strategy
Decide how the GM sees the rule and state. Craft supports pinned, partial, searchable, and hidden context visibility. Keep the pinned set small. One concise core GM instruction plus a few live trackers is usually better than pinning an encyclopedia.
The generic Palladium Core GM Instructions should be pinned in a World if that World relies on them as standing behavior. Bulk rule catalogs, skills, equipment, and other reference libraries should normally remain searchable. A mutable tracker that must stay fresh every turn may deserve pinned or partial visibility.
Triggered instructions
Use triggers for narrow moments: after a Character update, after a player message, after a GM reply, or after a relevant tool event. Triggered instruction bodies should be short and imperative. Do not turn every rule into a trigger; excessive triggers waste context and make behavior harder to reason about.
World instructions override generic guidance
The System's GM instructions are deliberately conservative. They tell the GM to use active profiles and not invent missing rules. A World can add more specific instructions for its title, setting, campaign state, encounter system, magic, powers, or other mechanics. When the World intentionally defines a behavior, the World instruction wins.
Missing configuration is visible
The GM should name a missing profile, field, or rule rather than concealing the problem with improvisation. This matters especially in a multi-game System. A guessed number may look plausible while silently turning one Palladium game into another.
Before calling a subsystem complete, test all four parts: can the GM find the rule, can it read the state, can it update the state, and will the relevant information actually be in context when needed? If any answer is no, the subsystem is documentation rather than dependable play machinery.