The lifecycle is the contract that lets Xema treat references deterministically. A draft version is mutable and never resolves. A published version is immutable — the only state the resolver returns. An archived version is kept so lockfiles and historical references stay valid, but the resolver refuses to return it for new lookups. The lifecycle enum is shared by every versioned object kind (skill, composition, workflow, biome, agent) so the publish / resolve contract is uniform.

Biomes extend this triad with their own seven-state machine — BiomeLifecycle — which adds the install / promote / review / store stages on top of the universal triad: draft → sandbox-installed → review-required → org-installed → store-submitted → store-approved → archived. Every transition is a capability call (biome:install@1, biome:promote@1, biome:submit-to-store@1, biome:approve-in-store@1, biome:archive@1) gated by the capability gateway and audited as one decision. The full state machine lives in the Biomes overview. See @xemahq/contracts/object for the universal triad and the biomeLifecycle model in the generated biome-host-api client for the biome-specific enum.