Document that *.system.name enums are not exhaustive and should not be added without conventions (#2764)

Co-authored-by: Joao Grassi <[email protected]>

Author: lmolkova

docs/how-to-write-conventions/README.md

@@ -12,6 +12,7 @@ linkTitle: How to define new semantic conventions
   - [Best practices](#best-practices)
     - [Prototyping](#prototyping)
     - [Defining attributes](#defining-attributes)
+    - [Defining enum attribute members](#defining-enum-attribute-members)
     - [Defining spans](#defining-spans)
     - [Defining metrics](#defining-metrics)
     - [Defining entities](#defining-entities)
@@ -150,6 +151,38 @@ Consider the scope of the attribute and how it may evolve in the future:
 > - If the attribute represents something useful in a narrow set of scenarios or
 >   is specific to certain system metrics, spans, or events, it likely does not need to be generic.
 
+#### Defining enum attribute members
+
+Enum attributes generally fall into three main categories:
+
+**Complete enums** document all possible values. For example, `cpu.mode` covers
+all known CPU modes. Metrics like `system.cpu.time` depend on having all modes
+defined. Authors should document all known values upfront, though new values
+may be added later to support new operating systems or CPU architectures.
+
+**Open enums** like `error.type` allow conventions and instrumentations to define
+their own applicable values.
+
+**System identifier enums** specify a system, project, provider, product, or protocol.
+For example, `db.system.name` contains database names like `mongodb` or `mysql`.
+
+System identifier enums help differentiate telemetry signals. MongoDB and MySQL
+both follow general database conventions, but populate attributes like `db.collection.name` differently and have system-specific attributes. Each system has its own span
+definitions and documentation.
+See [MongoDB](/docs/database/mongodb.md) and [MySQL](/docs/database/mysql.md) as examples
+and check out [system-specific naming](../general/naming.md#system-specific-attributes)
+for naming guidance.
+
+> [!IMPORTANT]
+> System identifier enums don't need to list every possible system, component, or technology.
+>
+> OpenTelemetry instrumentations that use enum attributes SHOULD document their values before releasing **stable** artifacts and MAY support undocumented values in unstable artifacts or behind a feature flag.
+
+Only define new system identifiers when you also document how conventions apply
+to that system. For example, when adding a new `db.system.name` value, create
+documentation and span definitions that show how generic attributes work for that
+database.
+
 #### Defining spans
 
 TBD