Elizon Docs
Features & Specs

Install lifecycle

The states an installation moves through, and what happens at each one.

Every install, from Studio or the CLI, is recorded as an installation of one version of a Package in one Organization (and optionally one project). The record is the source of truth for what was created, what's outstanding, and what can happen next.

States

StatusMeaningTriggers fire?
installingObjects are being created, or the install was interrupted (a closed browser, a killed process).No
installedEverything is created and nothing is outstanding.Yes, once activated
installed_incompleteCreated, with deferred items still outstanding (a Slot, an empty Knowledge Base). The entry point works.Yes, once activated
failedCreation stopped partway. What was created is recorded.No
rolled_backA failed install was undone; what it created was removed.No
uninstalledRemoved by an operator.No
supersededReplaced by a newer version through an update; its objects carry on under the new installation.—

installing and failed are treated alike: both offer resume and roll back.

Before anything is created

Studio's Review step and the CLI both check, without writing anything:

  • the signature (see Signing and verification),
  • compatibility: platform version and required capabilities,
  • duplicates: objects with the same name or the same Tool already in the Organization,
  • the full inventory, the compliance block and the triggers, shown to the operator.

Leaving at this point leaves no trace.

Creation

Objects are created in dependency order, each one recorded against the installation as it lands. Each Slot is bound to what the operator chose: an LLM Configuration, a Secret reference, a trunk, and so on. Credentials are bound as references to the Organization's vault, never as values.

Names can be changed at install, per object, e.g. when the Organization already has an intake-agent. When a duplicate is found, the operator chooses between using the existing one and installing a fresh copy under a new name. It's never decided automatically. Every created resource records the installation it came from.

Evaluation and activation

In the wizard, once everything exists, the Package's evaluation suite runs against the operator's bindings, and the operator acknowledges the results. Activate then writes the audit record, publishes the entry point Workflow when a trigger needs it, and arms the triggers: schedules, webhook addresses, API access, phone routing, mailbox (email) and app (app) polling, and Knowledge Base document (knowledge-document) triggers. Until then, the Package is fully created and completely inert.

From the CLI the same happens with install --activate, or later with install --activate=<id>. A Package installed but never activated shows Activate on its Studio page. An installation is activated once: a second activation, from any client, is refused, so no trigger is armed twice. An update arms the new version itself.

When an install fails

A failure stores a structured reason (a code, a message and a hint), never raw driver text. The operator then chooses:

  • Resume: carry on from the object that failed, reusing everything already created.
  • Roll back: remove everything this install created. If something outside the Package now uses one of those objects, that object is kept and reported (INSTALL_ROLLBACK_BLOCKED), never force-deleted.

Either works from either client. An install started in the wizard can be resumed from the CLI, and the other way round, because the state lives in the Organization, not on anyone's machine.

The audit trail

Every install, activation, rollback, update and uninstall is recorded in Settings → Audit Log: who did it, which Package version, every object created and its resulting id, what each Slot was bound to (credential references only), whether objects were created or reused, the signature result and signer, and the compliance block as declared at install time, so a later version can't rewrite history.

After install

The installation's page in Studio → Packages shows its objects, outstanding items, compliance changes and lifecycle actions. See Installed Packages and Update and uninstall.