[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-entity.md

[susan-shu-c]

I've rebased off main and then generated the files, not sure why these changes are still showing up

[mjwolf]

There was bug unrelated to this in how the entity fields are generated. The fix for that isn't merged yet.

Don't worry about these changes in your PR for now, it'll go away once the other fix is merged.