Runtime model
Grid Toolkit separates what a board is, what it currently contains, how it changes, how other systems observe it, and how it is displayed.
flowchart TB
accTitle: Grid Toolkit runtime flow
accDescr: A definition creates live state, actions commit changes, event batches notify observers, and views update renderers.
D["Board definition"] --> S["Live board data"]
A["Action request"] --> T["Checked, all-or-nothing change"]
T --> S
S -->|"Mutations or committed events"| E["Committed event batch"]
E --> V["Board view"]
V --> R["Renderer"]
Board definition
A GridBoardDefinition describes the cells, topology, and immutable board data. Policies make runtime decisions; they are not fixed rules stored by the definition. The definition is the recipe, not the live game.
Read Definitions and state for the ownership boundary.
Live board state
A GridBoardState holds the current revision, structures, occupancy, extensions, and runtime services. It owns that internal runtime data, while exactly one component or project system owns the state object's lifetime and disposes it. Unity authoring and code-owned workflows create the same kind of state.
Actions and all-or-nothing changes
A GridActionRunner previews or applies an action. Preview checks the request without changing state. Apply either commits the complete change or leaves the board unchanged. The technical term is an atomic transaction.
Read Actions, transactions, and events for revisions, rollback, and policy evaluation.
Events after a successful commit
A commit publishes a GridBoardEventBatch only for a board that has mutations or committed events. Subscribers receive the complete batch after the board is consistent.
Actions, transactions, and events explains no-change and event-only results. If work is rejected, use Diagnose Grid Toolkit workflows to find the responsible result or report.
Snapshots are a separate persistence boundary. See Snapshots and restoration.
Views and renderers
A GridBoardView watches committed state and tells its renderer which visuals need refreshing. The renderer keeps those visual objects and updates them instead of rebuilding the entire presentation every frame. This is retained visualization.
Read Retained visualization for layouts, hit testing, visual intents, and renderer capabilities.