[RFC 0052] Stage 2: Update additional GenAI fields

[susan-shu-c]

Looking for feedback

For most of the fields, they are lists of .json objects, or .json objects. For fields whose content could be very long (input.messages, output.messages), I have proposed that they are the flattened type due to costs.

via docs for nested type:

When ingesting key-value pairs with a large, arbitrary set of keys, you might consider modeling each key-value pair as its own nested document with key and value fields. Instead, consider using the flattened data type, which maps an entire object as a single field and allows for simple searches over its contents. Nested documents and queries are typically expensive, so using the flattened data type for this use case is a better option.

Though as I am not a subject matter expert on the field types and efficiency, looking for additional feedback or comments.

1. What does this PR do?

• Stage 0: [RFC] Stage 0: Add additional GenAI fields #2519
• Stage 1: [RFC 0052] Stage 1: Update GenAI fields #2525

2. Which ECS fields are affected/introduced?

Field	Type	Description /Usage
gen_ai.system_instructions	(Looking for feedback) flattened	The system message or instructions provided to the GenAI model separately from the chat history.
gen_ai.input.messages	(Looking for feedback) flattened	The chat history provided to the model as an input.
gen_ai.output.messages	(Looking for feedback) flattened	Messages returned by the model where each message represents a specific model response (choice, candidate).
gen_ai.tool.definitions	(Looking for feedback) nested	(Part of invoke_agent span) The list of source system tool definitions available to the GenAI agent or model.
gen_ai.tool.call.arguments	(Looking for feedback) nested	(Part of OTel execute_tool span) Parameters passed to the tool call.
gen_ai.tool.call.result	(Looking for feedback) flattened	(Part of OTel execute_tool span) The result returned by the tool call (if any and if execution was successful).

Changes based on OTel https://github.com/open-telemetry/semantic-conventions/pull/2179/files

3. Why is this change necessary?

4. Have you added/updated documentation?

YES / NO / N/A

5. Have you built ECS and committed any newly generated files?

YES / NO

6. Have you run the ECS validation tests locally?

YES / NO

7. Anything else for the reviewers?

---

Commit Message

[github-actions]

🤖 GitHub comments

Expand to view the GitHub comments

Just comment with:

• run docs-build : Re-trigger the docs validation. (use unformatted text in the comment!)

[github-actions]

Documentation changes preview: https://docs-v3-preview.elastic.dev/elastic/ecs/pull/2532/reference/

[github-actions]

🔍 Preview links for changed docs

• docs/reference/ecs-otel-alignment-details.md
• docs/reference/ecs-otel-alignment-overview.md
• docs/reference/ecs-process.md