Skip to content
Atlas docs

The Studio pipeline

If you think of Atlas as an assembly line, the Studio pipeline is its floor plan. A task description enters at one end; a transported CDS view leaves at the other. In between, six stations, arranged in the order that lets each one review the station before it.

The Studio pipeline Task one-sentence description Classify analytics · RAP extension · migration Plan dependency graph + gates Generate CDS · ABAP metadata Validate gate passes tests Transport TR + deploy Six stages. Every transition is a gate. No gate is bypassable.
Studio pipeline — Atlas turns a task description into a transported CDS view through six gated stages.

The line has exactly six stations because each of the five transitions between them is a place where meaning changes, and a place where a reviewer can sensibly ask did we do the last step correctly?

Why each station exists

Section titled “Why each station exists”

Task is where intent is captured. The station’s job is to hold one sentence — short enough to fit in a transport description, specific enough that a reviewer can tell whether the downstream plan matches what was asked. Atlas caps the sentence at 200 characters and records who wrote it.

Classify is where Atlas commits to a shape. The classifier decides whether the task is analytical or transactional, whether it belongs inside the S/4HANA core or on BTP, whether it is a new build or a conversion. This is a decision, not a computation — you can disagree with it and override, and Atlas will carry the override forward. But something has to be committed, or the planner has no ground to stand on.

What the classifier decides AXIS 1 · DOMAIN Analytical or Transactional read-only rollups vs business actions with side-effects AXIS 2 · TARGET Clean core or BTP extension artifact lives inside S/4HANA or on the extension platform AXIS 3 · INTENT New build or Conversion green-field artifact vs change to an existing one The classifier's output is one choice per axis. You can override any of them; the rest of the plan adapts.
The classifier picks one side on each axis — that tuple is the ground the plan stands on.

The three axes are independent. You can override any one of them without touching the other two; Atlas replans around the new choice.

Plan is where the classifier’s one-line decision becomes a dependency graph. Which views have to exist, in what order, resting on which base entities, carrying which evidence tiers. The plan is the first artifact a human will want to review before any code is written.

Generate turns the plan into text. CDS DDL, ABAP, metadata — each file with every field annotated according to the evidence Atlas found. Generation is deterministic: the same plan produces the same files, so a diff across generate runs tells you exactly what upstream change caused the code change.

Validate is where the gates run. Every gate is a precise, testable condition the plan has to satisfy before Atlas is willing to ship it. A failing gate is not a bug in Atlas; it is Atlas telling you something about your plan that needs to be addressed or declared.

Transport is the hand-off. This stage is where Atlas stops acting and the customer’s own transport infrastructure takes over. Atlas assembles the validated artifacts, their evidence, and any overrides into a transportable bundle; the bundle goes to the dev system via abapGit or a direct upload. From there, SAP’s Change and Transport System (CTS) carries the bundle through the customer’s landscape, and a release manager, not Atlas, moves the TR through dev → test → prod. Atlas records the TR number and the activation event, and only then advances the plan’s lifecycle state to Transported and locks it.

The reason Atlas does not release transports itself is that release authority belongs to the customer by design. SAP’s transport model exists so that a release manager can sequence a change alongside hundreds of other changes, time-window it, pause it for an audit, and roll it back — none of which Atlas knows enough to do. Atlas packages, the customer transports, Atlas records.

What each transition costs

Section titled “What each transition costs”

Going forward between stations is cheap: one command. Going backward is not, and that asymmetry is on purpose. An override to classification throws away the plan. A re-plan throws away the generation. A re-generate throws away the validate results. Atlas rebuilds what it needs to, but the old state is kept as ancestry on the evidence node so a reviewer can reconstruct the history later.

How this connects to the plan lifecycle

Section titled “How this connects to the plan lifecycle”

The six stages describe how a plan is built. The plan itself has a separate, smaller state machine for how it is reviewed and shipped: Draft, Reviewed, Transport-ready, Transported. That machine is the subject of Plan lifecycle. The pipeline and the lifecycle are two different maps of the same territory — read both and the territory stops being surprising.