AEM Collision Rules

Use this page when an incoming addon, update, or repair package claims something that may already exist. AEM owns the decision because it has persisted addon identity and lifecycle truth.

Rule

AEM owns addon-level collision decisions.

For orientation only, see Installer/Package Install and Update Flow.

Installer may surface package data and execute approved movement, but it must not decide collision meaning.

Checked Claims

Before accepting an install, update, repair, or replacement, AEM must compare the incoming contract against persisted AEM truth for:

• product UUID
• addon key
• addon slug
• admin routes
• public routes
• route keys
• declared capabilities
• permission declarations

Allowed Collision

A collision is allowed only when it belongs to the same governed addon lineage and the lifecycle action is an approved update, repair, or replacement.

Unsafe Collision

If lineage does not match, AEM must reject the package or resolve the conflict with a documented safe value such as a platform-generated `uuidfrag`.

The accepted resolved contract becomes runtime truth.

See Addon Development/Route and Slug Collision Handling, Installer/Package Install and Update Flow, and Permissions/Permission Manifest Declarations.