Snapshots and Runtime History
These notes explain how systems read a stable view of a changing game world and how selected runtime history can be retained for debugging or review.
A snapshot provides one consistent moment without freezing the whole server. Historical capture remains bounded and purpose-specific, so observation does not become an unlimited recording of players or server activity.
Runtime History Capture
This service collects limited records of system operation. It assembles history segments from approved Brain outcomes and host receipts. These segments can be reviewed or replayed. They do not change the main system state.
Stable Read View For Plugins
Plugins need a stable read view during tick execution. This view does not show uncommitted changes from other plugins. The Brain controls this system. It keeps mutation decisions clear and the same for all plugins. It only supports safe query reuse and validation. It does not replay or snapshot the database. This prevents wrong assumptions about data. The system does not change how plugins work. It only helps them read safely.
Example: Two plugins can read the same stable view without treating another plugin's uncommitted proposal as current reality.