Workflow and agent lifecycle

Every workflow and agent in Culvii is in exactly one of four states at any time:

Draft  →  Published  →  Live  →  (Disposed)

The transitions are explicit. No state changes silently.

The four states

State	Created by	Mutable	Triggers fire	Visible in Console
Draft	culvii dev (live session)	Yes — every save updates it	No	Drafts tab (only your own)
Published	culvii deploy	No — immutable snapshot	No	Workspace, all team members with access
Live	Activated in Console	No	Yes	Workspace, prominent
Disposed	Session end / explicit delete	n/a	n/a	No

Draft

A Draft is what culvii dev creates. It exists in the dev environment only. It's keyed by (your-user, workflow-id) — only you see your own drafts; your teammates don't see them.

Drafts are ephemeral by design:

• A new draft is created or updated every time you save a file.
• Drafts have no version number, no workspace assignment, no audit record.
• Drafts cannot fire triggers. You can run them manually from the Console's Drafts tab to test.
• When the culvii dev session ends, the draft is disposed. It leaves no permanent trace.

To restart a draft, restart culvii dev. The CLI re-creates it from your current local file state.

Published

A Published version is what culvii deploy creates. It is permanent and immutable.

culvii deploy quote-review.ts --env sandbox --workspace procurement

This validates the file, checks workspace and access, then creates a new immutable version in the target environment. First deploy is v1, second is v2, and so on.

Multiple Published versions of the same workflow can coexist in the same workspace + environment. Only one of them can be Live at a time.

Published versions can be:

• Run manually (from the Console or via culvii run).
• Inspected in the Console.
• Activated to become Live.
• Deactivated back to Published if they were Live.

They cannot be edited. To change a Published version, deploy a new one.

Live

A Live version is the one that has been activated for that workflow in that workspace + environment. Activation is explicit — you click "Activate" in the Console (or use the API).

When a workflow is Live:

• Triggers are armed. Cron jobs fire. Webhooks listen. Event subscriptions are active.
• The Console marks it prominently as the active version.
• Existing runs that started under a previous Live version continue with that version. New runs use the new Live version.

There is exactly one Live version per workflow per workspace per environment. Activating v3 automatically deactivates v2 — v2 reverts to Published, not Disposed. You can re-activate any Published version later.

Disposed

A Disposed workflow no longer exists in the platform. There are two ways to dispose:

• A draft session ending — the Draft is disposed automatically.
• An explicit delete from the Console (Published versions, with appropriate permission).

Disposed records are not recoverable. The audit log retains the history of the workflow's lifecycle, but the artifact itself is gone.

State transitions

stateDiagram-v2
    [*] --> Draft: culvii dev
    Draft --> Disposed: session ends
    Draft --> Published: culvii deploy
    [*] --> Published: culvii deploy
    Published --> Live: Activate (Console)
    Live --> Published: Deactivate (Console)
    Published --> Disposed: Delete (Console)
    Live --> Disposed: Delete (rare)

Practical implications

A few patterns that fall out of this model:

• Iterating fast doesn't pollute history. A developer can save a workflow file 200 times during a culvii dev session and the platform ends up with one ephemeral draft, not 200 versioned records.
• Deploys are deliberate. Every culvii deploy creates a permanent record. Teams typically wire this to CI on merge to main (or a release branch) so deploys are tied to code reviews.
• Activation is separate from deployment. Deploying v5 doesn't make it Live. An operator (or the deploy automation, if you've set it up that way) decides when to activate.
• Rollback is fast. If v5 misbehaves, an operator activates v4 from the Console. No re-deploy, no rebuild.

Two version-control systems

Git tracks your code. Culvii tracks deployed snapshots. They're separate, and trying to make one mirror the other usually backfires. See Two version-control systems for the full model.