IntermediateValidated 1.0.0

Stability and versioning

API tiers

Every type in the API reference has one tier.

Tier	Intended use	Compatibility expectation
Stable	Production gameplay and extension contracts	Supported within the 1.x compatibility line.
Preview	Public workflows still being refined	Isolate behind project-owned code; a later release may change the contract.
Experimental	Exploratory integration and diagnostics	Avoid dependencies that affect gameplay compatibility or save data.

The tier shown on an API page is authoritative for that type.

Grid Toolkit 1.0 positioning

Stable contracts include the core runtime, authoring, square/hex/triangle authoring, retained visualization and its authoring assets, World 2D, World 3D, and Inspector runtime attributes.

The remaining Preview families have narrower reasons for retaining that tier:

Editor integration depends on Unity editor registration and preview lifecycles that may still be refined.
Cell Metadata and Inventory are optional gameplay modules whose integration surfaces may still evolve.
uGUI is an optional Canvas capability over the required uGUI package dependency; its interaction and rendering contracts remain Preview.
Inspector Editor is a public editor integration surface that remains Preview for 1.0.

The six diagnostics and observation types remain Experimental because they expose exploratory instrumentation rather than gameplay compatibility contracts.

Serialized assets

Authoring assets store topology, definition, layer, policy, resolver, placement, and extension identities. A project can break its own data by changing those identifiers or renaming a serialized project type, even when the Grid Toolkit API involved is Stable.

Keep project-owned identifiers and serialized type names stable. Treat any required rename as a project data migration.

Snapshots

Snapshots are independent data, not a version-independent wire format. Their meaning depends on the Grid Toolkit version, stable identifiers, resolver behavior, and project-owned payload schemas.

Store a game-owned save-schema version beside a snapshot. Validate before restore and keep migration code outside live board objects. Restoration creates a new committed state; it does not rewind the board's revision history.

Pre-1.0 projects

Version 1.0.0 does not promise compatibility with unpublished, prototype, or pre-1.0 API names, serialized assets, or snapshot payloads. Follow the pre-1.0 reset policy when moving from those builds.

Choosing a dependency

Prefer Stable APIs for game rules and persisted identities. Place Preview APIs behind a small project-owned boundary. Use Experimental APIs only where they can be replaced without changing gameplay or saves.

Table of Contents