ATC topology: local, central, CI/CD

ATC runs in three places, and the difference is about where the checks execute and what data they can see. Local ATC is what a developer triggers in ADT on a single object or package — fast inner-loop feedback while writing code. It uses whatever check infrastructure is installed locally, which is fine for language and Clean Core checks but is not where you run a full Simplification analysis.

Central (remote) ATC is the production setup. A dedicated ATC system — usually the DevOps or QA stack — reaches into the source systems over RFC and runs the checks there, reporting back centrally. The reason this is the canonical topology is the Simplification Database: it is maintained centrally on the ATC master, so you keep one current, release-correct catalog instead of trying to install and update it on every system. Central ATC also owns the baselines and the exemption workflow, so governance is in one place.

ATC in CI/CD closes the loop for pipelines: a gCTS or abapGit pipeline invokes remote ATC programmatically through the Code Inspector API (for example `cl_ci_tests` / `cl_ci_check_objects`) rather than a human pressing a button. The pipeline runs the same union variant the central system uses, so a merge or transport can be blocked automatically before unclean code reaches the next system.

Source notes: clean-core-curriculum §8.2