Forge concepts

Four ideas. Get these and the rest of Forge falls out for free.

1. DataItem

A DataItem is the unit of game data in Forge. One character. One weapon. One quest. One location.

Every DataItem has:

• An id — stable, used by exporters and references
• A type — points at the schema that defines its fields
• Fields — the values you authored
• Metadata — status, tags, last-modified, author

DataItems are stored as JSON on disk and indexed by Forge's local database. Both formats are inspectable; nothing is hidden.

2. Schema

A schema describes the shape of a DataItem type. Fields, types, validators, defaults, references.

Forge schemas are versioned — when you change a schema, existing DataItems are migrated lazily on next edit. You can hold migrations open as long as you like; nothing breaks.

type: Character
fields:
  name: { type: text, required: true }
  level: { type: int, default: 1, min: 1, max: 100 }
  faction: { type: ref, target: Faction }
  abilities: { type: ref[], target: Ability }

3. Domain

A domain is a collection of related schemas that ship as a unit — Characters, Items, Abilities, Narrative, World, Systems.

Each domain is a starter pack. Use the defaults, override individual schemas, or replace whole domains with your own — your choice.

4. References

Cross-DataItem links use the ref field type. References are checked at validation time:

• A ref to a deleted DataItem is flagged as a broken reference
• Renaming the target keeps the link alive (refs are by id, not name)
• Cycles are allowed (a Faction with a leader Character whose faction is …)

Refs are also what make Oracle ↔ Forge integration work: a wikilink in Oracle that matches a DataItem id will hot-resolve to the Forge entity, and vice versa.