Skip to content
Merulan

Lifecycle, provenance, and drift

Lifecycle, provenance, and drift connect an installation's accepted release to its saved settings, change history, and recovery state.

Lifecycle, provenance, and drift track what a Workspace installed through Installable Products. The release says which content was published. The installation keeps what was accepted and what happened. Current reads reveal where those facts no longer agree.

Ownership

An install owns its lifecycle state and release proof. Provenance includes the exact release, manifest digest, accepted plan, and reference edges. Saved settings add an install snapshot, change history, and Source pins. These records let you compare accepted inputs with current facts. The original decision stays in place.

An installed read keeps this proof even when discovery access to the release is lost. Detached references remain visible as history.

States

Lifecycle state distinguishes installing, partial, installed, requires_resolution, failed, and retired. Each attempt reports its state, completed work, and failed unit when present. Read the attempt and install together. A returned result alone does not mean every unit succeeded.

Upgrade preview compares the current install with an exact target. Upgrade apply accepts that plan. A resume uses the persisted plan and delta. It does not choose a newer release.

Boundaries

Drift is reported, never silently reconciled. Reads can find a stale profile, changed contract, Source mismatch, blocked slot, or unclear choice. An installed release and healthy inputs are separate facts. A successful install may later need an input repair.

Adoption import reads and attests existing state. A transfer changes the design owner. Management authority explains the checks for that change.

Uninstall retires the selected root's owned work and its outgoing reference edges. Referenced Products remain installed. A supplier pinned by a live adopt_exact consumer cannot retire while that pin remains.

Failures

Lifecycle failures retain state to guide recovery. Resume or resolve an open upgrade before accepting another. A failure before the final upgrade commit leaves the installed release unchanged. Check completed work and receipts as well. Retirement can return requires_resolution without retiring the root.

A missing reference target or changed identity appears as a read conflict. The read performs no repair write.

Recovery

Rollback starts with current lifecycle and provenance, not an assumed undo. A failed upgrade keeps the prior release until its final commit. That does not prove all attempted work was reversed. Resolve the saved attempt first. Returning to an earlier release needs a fresh target preview and an accepted change. No separate rollback call is promised.

For interrupted retirement, read the root before retrying. A successful repeat of an already retired root returns its saved history. For drift, repair the named settings or input through its owner, then read it again.