Skip to content
Atlas docs

SAP API stability tiers (C0 / C1 / C2)

Not all views SAP publishes are equally safe to depend on. Some are versioned public APIs SAP commits to maintaining. Some are internal building blocks that SAP may change between releases. Some are key-user extension targets that carry no stability guarantee at all. SAP expresses the difference as three named contracts — C0, C1, C2 — and publishes which contract each view is under.

Atlas’s planner reads the contract on every view it considers binding to, and folds it into the evidence for the plan. That way the stability story is visible before a single line of code is written.

SAP API stability tiers C2 contract Public, stable — Atlas-safe A_ remote-API views. Versioned, deprecation-tracked. Atlas builds depend freely here. C1 contract System-internal — document & pin I_ / C_ stable for SAP use; may change between releases. Atlas flags these as amber in the plan graph. C0 contract Key-user / private — do not take a dependency P_, certain extension views. Atlas refuses to emit statements that bind to C0 without an explicit override. Atlas encodes C0 / C1 / C2 as evidence-confidence modifiers per RFC-001 §4.
Stability tiers — traffic-light semantics Atlas inherits from SAP Datasphere.

What each contract means

Section titled “What each contract means”

C2 is SAP’s strongest contract. A C2 view is public, versioned, and deprecation-tracked: SAP commits to notice before any breaking change, and the notice period is long enough to plan a replacement. These are the A_ views and a selected set of I_ and C_ views that SAP has explicitly elevated. Atlas binds to C2 freely.

C1 is the system-internal contract. A C1 view is stable enough for SAP’s own code to depend on it, and by extension stable enough for customer code with low risk tolerance. But SAP reserves the right to change the view between releases, and the customer has to absorb the change. Most I_ and C_ views are C1. Atlas binds to C1 when it has to but flags every C1 dependency on the evidence trail so a reviewer can see the upgrade exposure.

C0 is the no-guarantee contract. A C0 view is either a key-user extensibility target or an SAP-private internal, and may change arbitrarily. These are P_ views and a few C_ views SAP has explicitly demoted. Atlas refuses to emit code that binds to a C0 view unless the author provides an explicit override with a stated reason, because the upgrade pain of a silent C0 dependency consistently exceeds any short-term development savings it offered.

How the tiers compound

Section titled “How the tiers compound”

A plan’s effective stability is the lowest stability of anything it depends on. A consumption view built on a C1 composite is at most C1 for its consumers. A consumption view that transitively reaches — via an association — to a C0 view is at most C0. Atlas walks the dependency tree during planning and annotates each node with its effective tier, so you can see the compounding instead of inheriting it as a surprise later.

Effective tier is min(all dependencies) C_TopCustomers declared C2 · effective C1 inherits the min of its dependencies I_SalesOrderItem C1 · system-internal this is the binding that drags the top down A_Customer C2 · public stable safe on its own; not enough to pull the top up I_SalesOrder · C1 reads VBAK I_CustomerBasic · C2 reads KNA1 via released view effective tier = min(C2, C1) = C1 The Studio canvas marks the top node amber so the upgrade exposure is visible before the transport runs.
Tier propagation — a C2 top inherits the C1 path underneath unless you change the binding.

The visual cue in Atlas Studio matches the traffic-light semantics above: green for C2, amber for C1, red for C0. If a plan turns red anywhere, the plan will not cross validate without a gate override, and the override will carry the view name and the reason forward onto the transport description.

What happens when SAP changes a contract

Section titled “What happens when SAP changes a contract”

SAP publishes contract changes through the Simplification Item Catalog. Atlas’s nightly catalog refresh picks up the change and re- scores every plan that depended on the affected view. If the change broke a plan — for example, SAP demoted a previously-C2 view to C1, or deprecated a view you had bound to — Atlas opens a follow-up evidence node against the plan with a link to the catalog entry. You see this the next time you open the plan; you are not surprised by it at transport time.

The practical discipline

Section titled “The practical discipline”

When you write a task that has choices, Atlas will usually prefer the higher-tier option. If both A_Customer (C2) and I_Customer (C1) can answer the task, Atlas picks A_Customer. You can override the choice with a reason, and Atlas will carry the reason on the evidence, but the default is to spend stability tier when you have it to spend. That default is why clean-core S/4HANA Cloud plans tend to come out greener than plans against older on-premise installations: the A_ views are more thoroughly published in Cloud targets, so the planner has more greens to choose from.