Plan lifecycle
The Studio pipeline describes how a plan is built. Its lifecycle is the separate question of how a plan moves from being written to being shipped. Four states, one direction.
The four states
Section titled “The four states”A plan begins as Draft. In this state the author can freely rewrite the task, override the classification, re-plan, re-generate, and watch downstream artifacts refresh to match. The draft is the plan at its most malleable; the evidence trail is already forming, but the plan is not yet held to any external standard.
A plan becomes Reviewed when at least one non-author has read the plan and the evidence and recorded an approval on the plan’s evidence node. Atlas adopts a Git-style review model: the reviewer sees the plan, the generated files, every gate result, and can leave comments that stay attached to the plan forever. Once a plan is Reviewed, Atlas stops regenerating downstream artifacts automatically — a change that would invalidate the review moves the plan back to Draft.
A plan is Transport-ready when every gate has either passed or been overridden with a documented reason. Atlas has assembled a transportable bundle and pushed it to the customer’s dev system, where SAP’s Change and Transport System (CTS) has attached it to a transport request. Nothing has been released yet; the bundle sits in the dev system so a release manager’s own pre-release checks can run against it.
A plan is Transported when the customer’s release manager has moved the TR through their landscape and Atlas has received the activation event — either via a webhook from the landscape or via a manual confirmation on the case’s governance timeline. The plan is now locked; you cannot edit a transported plan. If the plan turns out to have been wrong, the correct move is to build a new forward plan that happens to undo the earlier one, not to reach backward.
Atlas deliberately does not release the TR itself. Release authority belongs to the customer — the release manager sequences a change alongside every other change in the landscape, time-windows it, pauses for audits, and rolls it back if something breaks. Atlas packages, the customer transports, Atlas records.
The timeline above is what the same four states look like plotted against real wall-clock time. Each tick is an event the evidence node records; you can reconstruct any of them later by opening the case’s evidence timeline in the Studio.
Why only forward
Section titled “Why only forward”A lifecycle with backward transitions sends a poor signal to future readers: when they look at the plan, they do not know whether it is currently in the state they see or whether it was walked back from a higher state. Atlas’s answer is that a rollback is a new plan with an explicit ancestor pointer to what it is undoing. The old plan stays at Transported, carrying its full history; the new plan starts at Draft and goes through the gates the same way anything else does.
This costs a little extra command-line ceremony. What it buys is that every plan in the system has a single, unambiguous, forward-only history, and the evidence trail an auditor or a future teammate will read makes sense on first reading.
Where this matters for you
Section titled “Where this matters for you”If you find a plan stuck between states — validated but not transported, reviewed but not transport-ready — the pipeline is almost always telling you something specific about a pending gate or a missing override reason. The how-to guides under Resolving gates walk through the common ones.