Overview
When a workflow reaches a block withconfig.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
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 asparent_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.
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.