Skip to main content

Overview

When a workflow reaches a block with config.review and the predicate fires, the run pauses and creates a review. Address the review by its opaque id, such as rev_...; workflow context like run_id, block_id, step_id, and iteration_key is metadata for filtering and grounding. Reviews hold gate metadata and the terminal decision. Review versions hold immutable output snapshots and are managed separately through reviews.versions.*.

Review Shape

Review queue items return the same Review shape. Fetch the version history for a given review with reviews.versions.list(review_id=...) — the runtime-created seed is the version whose parent_id is null.

Version Shape

Versions are peers. There is no head pointer. Use created_at for display ordering, and approve or reject the exact version_id you inspected.

The Review Loop

1. Find the work

2. Inspect the output

Use run_id and step_id to inspect the source step and document before deciding.

3. Correct if needed

Create a new version (a complete replacement snapshot) with the reviewed version as parent_id, then approve the returned id. Public clients must provide parent_id when creating correction versions. Versions are a flat CRUD resource at POST /v1/workflows/reviews/versions; the parent id lives in the body, not the URL.
Snapshot validation is block-specific: For split and for-each snapshots, pages must be positive integers, sorted, and unique within each item. The API does not support partial patches.

4. Decide

resume_status="resumed" means the workflow accepted the signal. resume_status="pending" means the decision is durable and a backend reconciler will retry the resume.

API Reference