Event payload lives in the LogRecord body

.chloggen/event_payload_in_body.yaml

@@ -0,0 +1,21 @@
+# Use this changelog template to create an entry for release notes.
+#
+# If your change doesn't affect end users you should instead start
+# your pull request title with [chore] or use the "Skip Changelog" label.
+
+# One of 'breaking', 'deprecation', 'new_component', 'enhancement', 'bug_fix'
+change_type: enhancement
+
+# The name of the area of concern in the attributes-registry, (e.g. http, cloud, db)
+component: events
+
+# A brief description of the change. Surround your text with quotes ("") if it needs to start with a backtick (`).
+note: Add clarification that the body of an Event will live in the LogRecord body field.
+
+# Mandatory: One or more tracking issues related to the change. You can use the PR number here if no issue exists.
+issues: [ 566]
+
+# (Optional) One or more lines of additional information to render under the primary note.
+# These lines will be padded with 2 spaces and then inserted directly into the document.
+# Use pipe (|) for multiline entries.
+subtext:

docs/general/events.md

@@ -3,13 +3,35 @@ linkTitle: Events
 aliases: [docs/specs/semconv/general/events-general]
 --->
 
-# Semantic Conventions for Event Attributes
+# Semantic Conventions for Events
 
 **Status**: [Experimental][DocumentStatus]
 
-This document describes the attributes of standalone Events that are represented
+This document describes the characteristics of standalone Events that are represented
 in the data model by `LogRecord`s.
 
+Semantically, an Event is a named occurrence at an instant in time. It signals that
+"this thing happened at this time" and provides additional specifics about the occurrence.
+Examples of Events might include things like uncaught exceptions, button clicks, user logout,
+network connection severed, etc.
+
+In OpenTelemetry, Events are implemented as a specific type of `LogRecord` that conforms to
+the conventions included here, and Events
+[have their own API](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/logs/event-api.md).
+The API abstracts away knowledge of `LogRecord` so that users only deal with Event
+semantics.
+
+In addition to a required name, an Event may contain a _payload_ of any type permitted by the
+[LogRecord body](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/logs/data-model.md#field-body).
+In its implementation, the Event _payload_ will constitute the `Body` of the `LogRecord`.
+Like all other OpenTelemetry signals, an Event has optional attribute metadata that helps describe
+the event context.
+
+Over time, some Events will be specified by OpenTelemetry and will have documented payload structure,
+field semantics, and stability and requirement levels. Other events may be user-defined and carry
+bespoke user semantics. When an Event name exists in the semantic conventions, its _payload_
+structure and semantics will also be defined.
+
 The following semantic conventions for events are defined:
 
 * **[General](#general-event-attributes): General semantic attributes that may be used in describing Events.**
@@ -18,8 +40,8 @@ The following semantic conventions for events are defined:
 ## General event attributes
 
 Events are recorded as LogRecords that are shaped in a special way: Event
-LogRecords have the attribute `event.name` that uniquely identifies the event.
-Events with same `event.name` are structurally similar to one another. Events
+LogRecords MUST have the attribute `event.name` that uniquely identifies the event.
+Events with the same `event.name` are structurally similar to one another. Events
 may also have other LogRecord attributes.
 
 When recording events from an existing system as OpenTelemetry Events, it is