# The Steward — Simulation Definitions ## Purpose Stable IDs and immutable definitions now form the vocabulary shared by simulation state, systems, world adapters, scenes, tests, and future save migrations. `SimulationIds` is the canonical source for code-facing `StringName` IDs. `ActionDefinition` and `ProfessionDefinition` are editor-readable custom resources. `SimulationDefinitions` loads, resolves, and validates the complete prototype set. ## Current action contract Each executable action definition contains: - stable `action_id`; - display name; - default duration; - optional preferred profession ID; - target type: resource, activity, or free movement; - resource action ID when the action targets a ResourceNode; - optional completion-cost resource ID and amount. The current actions are gather food, gather wood, deposit food, deposit wood, withdraw food, patrol, study, eat, rest, sleep, and wander. Idle and dead are stable state sentinels, not executable action definitions. SimNPC reads default duration and preferred-profession metadata from these definitions. WorldViewManager reads target type and resource-action metadata instead of maintaining a separate gather-action map. ActionSelectionSystem and SimulationManager share the same completion-cost metadata, so patrol and study both require one stored wood without duplicating that rule. ## Current profession contract Each profession definition contains a stable `profession_id`, display name, body color, and prop color. The current professions are farmer, woodcutter, guard, scholar, and wanderer. NPC generation chooses from the registry's stable IDs. NPC state stores and restores those IDs as `StringName`, and rejects records that reference an unknown profession or executable action. ## Opportunity vocabulary `SimulationIds` also defines the first proven opportunity type, `restock_empty_pantry`, and its `open`/`resolved` statuses. These are stable serialized vocabulary, not editor-authored quest definitions. Dynamic trigger, interested NPC, pantry/food goal, progress, and exact resolution-event identity belong to `OpportunityStateRecord` and the focused opportunity system. Do not extract a generic quest-definition registry until another real unresolved-condition consumer proves which lifecycle fields and rules are actually shared. ## Validation The registry rejects: - missing or duplicate IDs; - empty display names; - non-positive action durations; - invalid target types; - resource actions without a resource-action ID; - incomplete, non-positive, or unknown completion-cost resources; - references to unknown professions or resource actions; - definition resources that fail to load. `tests/simulation_definitions_test.gd` verifies registry integrity, definition-backed behavior, unknown-ID rejection, and serialization round-tripping. ## Deliberate boundary Definitions currently own identity and the static metadata already proven by the prototype, including the patrol/study completion-cost contract. They do not yet own: - utility thresholds and consideration curves; - general preconditions beyond stored-resource completion costs; - completion effects; - interruption and failure policy; - reservation strategy; - detailed target-selection policy beyond current resource/activity/free metadata; - richer presentation hints beyond the current profession palette. Selection, execution, target resolution, and visual travel are now separate responsibilities. The remaining concerns should move into definitions only when the action-system implementations prove a stable, reusable contract.