> For the complete documentation index, see [llms.txt](https://docs.unitlab.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.unitlab.ai/documentation/workflows/change-a-live-workflow.md).

# Change a live workflow

Assess in-flight work and QA assignments before applying workflow changes, then verify the affected routes.

Changing a live workflow can affect routing, ownership, active annotations, Consensus votes, and review assignments. Inspect the work already in progress and define its treatment before applying a new graph.

## Assess the change

| Change                          | What to inspect                                                                        |
| ------------------------------- | -------------------------------------------------------------------------------------- |
| Add a stage or change a route   | Which items will encounter it and which existing items remain at their current stage.  |
| Change eligible members         | Future claims, existing assignments, and reviewer availability.                        |
| Change Consensus requirements   | Active attempts, submitted votes, review tickets, and any locked settings.             |
| Change a Quality Gate threshold | The calibrated acceptance policy, benchmark readiness, and future evaluations.         |
| Edit an answer key              | Approval of the intended new key and which reference version earlier evaluations used. |
| Replace the project workflow    | Impact information and the number of in-flight items proposed to reset to Project.     |

## Apply a controlled change

1. Record the current graph, relevant settings, and affected cohort.
2. Inspect queues and QA results to identify active annotation, voting, and review work.
3. Decide whether to finish, preserve, explicitly reassign, or restart the affected work using supported controls.
4. Make the smallest graph change needed and retain stage identity where active work depends on it.
5. Use **Save & Apply** and read the validation and impact information. Resolve blockers before applying.
6. Exercise the affected routes with representative items and roles.
7. Confirm current stages, ownership, and accessible vote or review assignments after the change.

## Protect active Consensus work

Consensus runtime settings can be locked while items are in the stage. Eligibility changes apply to new claims while existing assignments and submitted votes remain intact. Replacing an existing assignee is an explicit reassignment operation. Do not assume editing the member list resets votes or transfers active review tickets.

Moving an item into Consensus creates a new attempt; earlier votes remain evidence from their own attempt rather than automatically counting as new submissions. Inspect the current queue and attempt when investigating unexpected results.

## Recheck QA routes

Verify Consensus Pass and Fail, with Fail connected to Review. Verify Quality Gate Pass, Fail, and Not evaluated separately. Verify Review Approved and Rejected, including the return to correction and the next review. Confirm that unscored items cannot silently follow a policy intended only for evaluated passes.

Use the pilot cases in [QA Workflows](https://docs.unitlab.ai/documentation/qa/qa-workflows). When changing only one part of the graph, repeat the relevant scenarios and any connected exception path.

## Recover from unexpected behavior

Inspect item history, current stage, assignment, and the reported validation or processing problem before making another graph change. Restore or revise configuration through supported workflow controls and deliberately handle affected tasks. Recreating a visually similar stage does not necessarily preserve the old stage's active assignments.

Keep the operating record of the change, its reason, affected work, and verification results with the project's process documentation.