[RFC 0056] Propose host.group as a free-form keyword field

[adrianchen-es]

1. What does this PR do?

Adds a new Proposal RFC (0056) for host.group, a free-form keyword field for grouping hosts under a user-configurable label, used for search, alerting, and access control.

Addresses #2340.

2. Which ECS fields are affected/introduced?

• host.group (new): user-configurable label for grouping a set of hosts. Level: extended. Target maturity: alpha.

The originating issue also proposed agent.group. This proposal drops it. The RFC found no case where an agent needs its own grouping separate from the host it reports on, and existing ECS precedent (the reusable risk and entity field sets) scopes asset-level classification to host/user/cloud/service/orchestrator, never to agent. Details in the RFC's Concerns section.

3. Why is this change necessary?

Teams have no standardized field today for grouping hosts by application, environment, or business unit, and fall back to ad hoc custom fields with inconsistent naming across integrations. host.group gives Security and Observability a single, consistent field to filter, alert, and grant access on by group, the same role data_stream.namespace plays for data streams.

4. Have you added/updated documentation?

N/A. Documentation is within the RFC itself and the schema YAML (rfcs/text/0056/host.yml).

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

NO. This PR adds only an RFC and proposed schema YAML, no changes to schemas/ or generated/.

6. Have you run the ECS validation tests locally?

NO. RFC-only change, no schema or code modifications.

7. Anything else for the reviewers?

• Target maturity is alpha. Nothing currently populates the field, and Fleet would need a new policy-level setting to assign a group label at enrollment.
• Elastic Defend does not inherit generic Fleet Agent Policy field injection the way Beats-based integrations do, so populating host.group for Defend-originated data needs separate confirmation with the Endpoint team. Flagged in Scope of impact.
• Feedback welcome on the field name itself. host.group could read as overlapping with the existing reusable group field set (user.group.*, process.group.*), even though the paths never actually collide.

---

Commit Message

[RFC 0056] Propose host.group as a free-form keyword field

Add a new Proposal RFC for host.group, letting users assign an
arbitrary label to a set of hosts for search, alerting, and access
control. Drops the agent.group field proposed in the originating
issue since agent and host would always carry the same value in the
common case, and ECS already scopes asset-level classification fields
to host/user rather than agent.

[github-actions]

🤖 GitHub comments

Just comment with:

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

[github-actions]

ECS PR Triage (automated)

PR Triage Report

PR: #2670 — [RFC 0056] Propose host.group as a free-form keyword field
Classification: Direct PR
Change type: Schema Change
Scope: Moderate

Summary

This PR adds a new RFC (Proposal stage) for a single new field, host.group, a free-form keyword field for grouping hosts under a user-configurable label. The PR contains only RFC artifacts (rfcs/text/0056-host-group.md and rfcs/text/0056/host.yml) — no schemas/ source changes, no generated artifacts, and no tooling changes. The contributor has correctly followed the RFC process for proposing a new field that addresses an unaddressed use case (host-level grouping), and has assigned the next available RFC number (0056, following 0055). The RFC itself is thorough and well-structured.

Files changed

• Schemas: none
• Generated: none (not expected — this is an RFC-only PR; schema implementation would land in the same or a follow-up PR per process)
• Tooling/scripts/tests: none
• Docs (hand-authored): none
• CI / GitHub: none
• RFCs: rfcs/text/0056-host-group.md (added), rfcs/text/0056/host.yml (added)

Routing decision

Direct PR is appropriate. This is an RFC Proposal PR, which is itself the correct contribution path for proposing new fields. The contributor is not bypassing the RFC process — they are following it. The key routing question is whether the underlying change (a new host.group field) warrants an RFC, and it does:

• The field addresses a currently unaddressed use case (host-level grouping for search, alerting, and ABAC) — RFC trigger per classification-rules §1 ("novel / unaddressed use case").
• The naming overlaps conceptually with the existing reusable group field set, which warrants design discussion — classification-rules §3 concern.

However, since the PR is the RFC itself, the correct routing for this PR is Direct PR (an RFC PR is the expected vehicle). The RFC content is complete and ready for maintainer review.

Risk notes

• Breaking / deprecation: No. Purely additive — one new extended-level field at alpha maturity. No existing fields are modified, removed, or renamed.
• OTel / semconv: N/A. There is no known OTel semantic convention counterpart for a user-assigned host grouping label. No otel: metadata is needed.
• Scope / reuse: The field is added to the existing host field set, not a new top-level field set. The host field set is already reused at host.target.*, and the new field will propagate there as expected. The contributor explicitly addresses the naming overlap with the reusable group field set (user.group.*, process.group.*) in the Concerns section — the paths never collide but the conceptual overlap is worth maintainer discussion.

Completeness checklist

• PR description (all sections) — All 7 template sections are filled with substantive answers. The contributor explicitly notes N/A or NO where appropriate (docs, build, tests) with clear justification that this is an RFC-only PR.
• CHANGELOG.next.md — Not required. This PR touches only rfcs/ files; no schemas/ or scripts/ changes. A changelog entry will be needed when the schema implementation lands.
• make + committed generated outputs — Not required for an RFC-only PR. The contributor correctly states no schemas/ or generated/ changes are included.
• OTel otel: on new/changed semconv-related fields — N/A. No OTel semconv counterpart exists for this field concept.
• Tests / make check — Not required for an RFC-only PR (no schema or tooling changes to validate).
• CLA (contributor) — Cannot be verified from the PR metadata; GitHub/Elastic CLA bot will enforce this automatically.

RFC quality assessment

The RFC document is well-crafted and covers all required template sections:

Section	Status	Notes
Summary	Complete	Clear 2-sentence summary with motivation
Usage	Complete	Three concrete use cases (Security, Observability, ABAC) with examples
Fields	Complete	Single field with name, type, level, description, example, alpha annotation, and standalone YAML in rfcs/text/0056/host.yml
Source data	Complete	Three real-world JSON examples (system metrics, nginx logs, auditbeat auth events) across different agents and use cases
Scope of impact	Complete	Covers ingestion (Fleet, Elastic Defend limitations), usage (Kibana, detection rules), and ECS project impact
Concerns	Complete	Thorough — addresses agent.group drop rationale, naming overlap with group field set, tags/labels alternatives, single vs. multi-value, ABAC trust model, and reuse propagation
People	Complete	Author listed
References	Complete	Links originating issue, RFC process, and Security field reference

Minor issues in the RFC:

1. The RFC Pull Requests section at the bottom references https://github.com/elastic/ecs/pull/NNN — the placeholder NNN should be updated to 2670.
2. The Date field is TBD — standard practice, but should be set when the RFC is finalized.

Recommended next actions

1. Contributor: Update the RFC Pull Requests link from #NNN to #2670.
2. Maintainers: Review the naming question raised in Concerns — whether host.group is sufficiently distinct from the reusable group field set (user.group.*, process.group.*), or whether an alternative like host.deployment_group is preferred.
3. Maintainers: Confirm whether the RFC should include the schemas/host.yml change and generated artifacts in this same PR (per rfcs/PROCESS.md: "proposal and implementation land together in a single PR"), or whether the team prefers a two-PR flow for this case.
4. Maintainers: Weigh in on the single-value (scalar keyword) vs. multi-value (array) design choice for the field.
5. Contributor: Once maintainer feedback is incorporated and the RFC is approved, add the schemas/host.yml change, run make, and commit generated artifacts (if not already included per action 3).

---

Posted by PR Triage workflow

[trisch-me]

this is something where we should come with another solution. Group is an existing namespace so it will be indistinguishable from the look and despite ES currently supports both scalar and object with the same name, we can’t mix them in the standard. If we would even accept it - we would never be able to reuse group as a namespace anymore.

Have you weighted if we can reuse existing group namespace? From the examples it looks likes it just a string, do we have options where it might be an object with id?

actually scratch that, I don’t think group namespace would be a good solution

[adrianchen-es]

What if we made it more specific - e.g. in the quoted section from my RFC?
Where the new field is host.deployment_group? host.group was shorter.

[trisch-me]

is it really a delpoyment_group? Based on description it feels like it could be some generic group, not specifically related to deployment

[Copilot]

Pull request overview

Adds RFC 0056 proposing a new ECS field host.group (alpha) as a free-form keyword for user-configurable host grouping, intended for consistent querying, alert scoping, and access control across Security and Observability use cases.

Changes:

• Introduces an RFC document describing motivation, usage examples, scope/impact, and rationale for choosing host.group over agent.group.
• Adds the proposed field definition YAML for host.group (keyword, extended, alpha).

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
rfcs/text/0056/host.yml	Defines proposed host.group field as a keyword with alpha maturity.
rfcs/text/0056-host-group.md	RFC narrative: motivation, examples, impact analysis, and concerns/rationale.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.