common flags section backlog

Signed-off-by: Bryan Bednarski <bbednarski@nvidia.com>

Author: bbednarski9

packages/nvidia_nat_atif/atof-event-format.md

@@ -471,6 +471,7 @@ The following structural gaps are acknowledged but deferred to keep the current
 
 1. **Emitter / resource identity.** No analog to OpenTelemetry's Resource — useful when multiple services feed into one event store. Consider a `resource` block or a dedicated stream-header event carrying `service.name`, runtime version, host identity, etc.
 2. **Streaming chunk event type (conditional).** A dedicated `Chunk` event for incremental streaming output is deferred pending a concrete use case. The primary streaming concern — partial output on termination — is already handled: when a `"streaming"`-flagged scope terminates with `status == "error"` or `status == "cancelled"`, the `output` field MAY carry the chunks accumulated before the terminal event, representing a partial response (§3.2, §4.1). A `Chunk` event would only be warranted if a consumer required real-time visibility into in-flight chunks before `ScopeEnd` — e.g., a UI that renders tokens as they arrive rather than at scope close. Absent such a use case, the `"streaming"` flag plus `status`-gated partial output in `ScopeEnd` are sufficient.
+3. **Common Flags section placement.** §4.1 "Common Flags" is currently nested inside §4 "Scope Profiles", but flags are not a profile — they are a cross-cutting field on `ScopeStartEvent`/`ScopeEndEvent` that applies across all scope types regardless of profile. The current placement reflects that profile subsections reference flags inline, not that flags semantically belong to profiles. A subsequent revision should either (a) promote Common Flags to its own top-level section or (b) move it under §2 "Common Event Fields" alongside other shared fields. This is a documentation-only restructure; field semantics, wire format, and the `flags` enum vocabulary are unchanged. Downstream consumers that cite "spec §4.1" (including the `nvidia_nat_atif` reference implementation's `flags.py` docstring) will need to track the new section number.
 
 ---