# Versions, activation and runs

A loop's editable plan, stored revision, approved package and executions answer different questions. Identify which object you have before interpreting its state.

## Objects and relationships

| Object | What it establishes | What it does not establish |
| --- | --- | --- |
| Draft | Current editable instructions and inputs | Persistence or execution |
| Saved-work revision | A stored version of a plan | An approved hosted artifact |
| Hosted candidate | An immutable generated package to inspect | Permission to invoke it |
| Approved hosted version | The exact package is available for invocation | An accepted or completed run |
| Hosted run | One invocation of a version with explicit inputs | That its output satisfies your task |
| Step result | Output from a particular executed step | Success of other steps or the whole workflow |
| Revoked version | Future invocations are blocked | Cancellation or rollback of running work |

## Hosted lifecycle

Generation creates a candidate. Review examines its actual files, expected input and recovery contract. **Activate in Bar** approves that exact version, but starts no run. A later explicit invocation supplies inputs and its own cloud-processing consent. HTTP 202 acknowledges acceptance, not completion.

Changing instructions does not rewrite an existing immutable version. Generate and review a replacement rather than assuming activation points to the current canvas.

## Keep execution tracks separate

A governed workflow built from function steps has a prepared graph, individual function runs and explicit continuation. It is not the hosted artifact schema. Approval of a governed action can execute that action; hosted version activation does not. Neither approval is a success receipt. A completed step still needs its result checked, and subsequent steps remain distinct work.

For the governed path, [create a canvas loop](/docs/loop-builder/quickstart), [review its result](/docs/loop-builder/review-agent-performance) and [enable a schedule deliberately](/docs/loop-builder/schedule-a-loop). Runtime policies and durable instruction documents have separate owners in [Policy Hub](/docs/shared/policy-hub).

Use [version review](/docs/loop-builder/review-a-version) for the hosted action path and [run identity](/docs/loop-builder/run-reference) to follow one invocation without duplicating it.

## Related reading

[MDN: HTTP 202 Accepted](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/202) explains why request acceptance is not completion. Use the owning Loop run record to establish the actual execution state.