Released DDIC artefacts — read CDS, not tables

The most common single violation in custom code is reading a SAP table directly because 'it has always been there.' In Clean Core the interface CDS views — the `i_*` family — are released, but the underlying database tables almost never are. So `select from mara` in a cloud package is a Clean Core violation, while `select from i_material` is the sanctioned read. The same holds across the model: read `i_*` (and the `c_*` consumption views) rather than the physical tables behind them.

The principle is that the interface view is the contract; the table is not. SAP guarantees the shape and semantics of `i_material` across upgrades, and reserves the right to restructure `mara` underneath it — split it, add fields, change buffering. Code bound to the view rides through those changes untouched; code bound to the table is exactly the kind of dependency that turns an upgrade into a regression project.

Practically this also buys you cleaner data: interface views apply the modern field names, associations to related entities, and any compatibility mapping SAP has layered on (for example bridging an old field to a restructured model). You select fewer surprises and more meaning. When you catch a direct table read in review, the fix is almost always a one-line swap to the corresponding interface view — and if no released view exposes what you need, that is a signal to reconsider the requirement, not to reach back to the table.

ABAPselect from mara
  fields matnr, mtart
  where mtart = 'FERT'
  into table @data(lt_mara).

ABAPselect from i_material
  fields material, materialtype
  where materialtype = 'FERT'
  into table @data(lt_material).

Source notes: clean-core-curriculum §5.4