Element
Definitions
The platform-agnostic building block — semantic markup plus optional behavior, defined independently of any delivery platform
Where one exists, a platform's realizations are converted from it. It is an optional layer: a Component Contract can be realized as Components and Blocks directly, and the commercial design system deliberately authors no Elements (its ADR-0005).
In the APG, and in the DOM generally, a single tag in the document tree — the <button>, the <li>, the <div> that a widget is built out of
The ordinary web sense, and nearly the opposite of the design-system one above: this element is the most concrete thing there is, one node in one page, while that one is the most abstract — the platform-agnostic definition a Component and a Block are both converted from. Reading an APG pattern with the design-system sense in mind is a reliable way to be confused by it.
The word to reach for when you mean the thing itself, not one platform's copy of it. An AEM Component and an EDS Block that do the same job are two realizations; if there is a single source they were both converted from, that source is the Element.
Why it is optional
Two repositories use the same definition and disagree about whether the layer exists. UXLab's catalog treats the Element as the canonical source of truth. The commercial design system records Component Contracts — intent, anatomy, token contract — and declines to author markup at all, so its contracts are realized straight into Components and Blocks. Both are right about their own estate. The glossary says: where an Element exists, realizations come from it; nothing obliges one to exist.
Avoid: "component" or "block" when you mean the generic thing — those are the AEM and EDS realizations.