Guide

Versioning & Migrations

Advance durable instances between exact chart identities through explicit restoration and disposition laws.

A changed chart is a new version of meaning. Versioning & Migrations moves durable instances between exact chart identities without relabeling old state, obligations, or evidence.

Version identity precedes migration policy

Canonical chart structure determines chartHash. When that structure changes, an existing checkpoint remains evidence under its source chart; it is not automatically a valid Snapshot of the destination. The migration edge must name both identities and prove how destination state is restored.

Migration.make declares the exact source-to-destination edge. Destination .restore constructs valid destination data and configuration. Every retained Timer, Activity, child, Resource, and History obligation receives an explicit disposition before one exact-head migration commit may advance the instance.

Follow one exact version edge

Preserve the old explanation

A migration appends new operational history. It does not rewrite old chart hashes, incidents, causation, timelines, or child ancestry as if the destination chart had produced them. Ownership trees migrate leaves-up so a parent never points at a child whose version boundary remains unresolved.

The authoring surface is public today. The storage-owned execution function remains internal, so this category teaches the exact contract and laws without presenting an internal function as a public operator API.

Next, Migrations works through the full retained-obligation and exact-head race.