Handoffs, routing, and fallbacks
Control how work moves between stages, where it returns on Request changes, and what happens when a stage fails.
Last updated September 27, 2026
Handoffs
The Blueprint is an ordered stage graph. Compile projects that graph onto GitHub. Each stage hands off only to the next allowed stage, a human gate, or a defined fallback.
Unresolved principals stop compile. Placeholders such as @code-owner are not a handoff target.
Routing at runtime
Command does not redraw the graph. Start Run dispatches the installed orchestration-pipeline.yml. Status on the Run:
| Status | Routing meaning |
|---|---|
running | The current stage is executing in GitHub Actions |
blocked | A Human Review Task or gate holds the handoff |
failed | The stage, hook, or dispatch stopped the graph |
completed | No further stage is scheduled |
Request changes
Request changes on a Human Review Task returns work to the prior stage. A new candidate SHA is required. Native APPROVED on the old SHA is not reusable.
Reject ends this candidate. It does not invent an alternate route unless the Blueprint already declared one.
Fallbacks
Declare failure and skip paths on the Blueprint before compile. Conditions and fallbacks that exist only in a hand-edited workflow file are not part of the Compiled Workflow. Change the Blueprint, compile, and re-export instead of patching YAML.
If a stage fails with Access denied by policy settings, that is GitHub Copilot CLI org policy, not a Blueprint fallback. An org owner must enable the policy for the workflow actor.