I would appreciate clarification of a native FIT field emitted by the Connect IQ SDK 9.2.0 simulator with the fēnix 7X target. These are synthetic simulator observations, not a claim about physical-watch behavior.
In preserved completed exports, global message 18 (`session`), native field 0 (`event`), contains enum 9 (`lap`); field 1 (`event_type`) contains 1 (`stop`). The garmin-fit-sdk 21.214.0 decoder/Profile 21.214.0Release annotates this Session field as `session` (enum 8). The value 9 is actually present, not absent or the enum invalid sentinel. This is not confusion with a separate global message 19 Lap or a global message 21 timer Event.
The same Session annotation appeared in three separately run synthetic conditions: direct ActivityRecording with no explicit addLap or project developer fields; direct ActivityRecording with one explicit addLap; and our recorder's normal cue/save route. Integrity checks and native summary decoding succeeded. These observations do not identify the internal cause or establish a formal invalid-FIT rule. The decoder version is not claimed to identify the simulator's internal FIT writer.
1. Is `event=lap` on a Session message permitted for this producer, or should it be `event=session`? Is the Profile annotation normative here?
2. If permitted, what version/device/producer conditions and official specification or erratum explain it?
3. If it is a known simulator issue, which versions are affected, and is physical-device behavior separately specified?
4. How should a validator distinguish required Session structure/summary fields from a supplied annotation discrepancy without rewriting the FIT or miscounting a lap/cue?
The [FIT Activity File documentation](developer.garmin.com/.../activity.html) is our reference for required activity/session structure. We are seeking the applicable field semantics, not requesting permission to normalize this value or assuming decoder success resolves it. No personal FITs or identifiers are included.