Does Gedcom 7 require unique IDs on individuals, families, and other core data?

[dapug]

One of the issues with Gedcom 5.5 is unstable, unreliable ID's. Gedcom 7 defines UID. But I want to clarify what to expect from that field.

I have an app that requires UID from an imported GEDCOM (ideally GUID). If the 3rd party app generating the GEDCOM 7 does an output multiple times after changes to the data, the UID's must remain unique each export so that my app can recognize what it already saw in previous imports (from said 3rd party), and make any required changes to its own copy of the data.

I'm wondering if this is enforced, or optional. How reliable are unique IDs on records as a core, required standard?

[dthaler]

Discussion in GEDCOM Steering Committee 20 MAY 2025:

• The specification says "A globally-unique identifier of the superstructure, to be preserved across edits." and "Because the UID identifies a structure, it can facilitate inter-tool collaboration by distinguishing between a structure being edited and a new structure being created. If an application allows structures to be edited in a way that completely changes their meaning (e.g., changing all the contents of an INDI record to have it describe a completely different person) then any UIDs should also be changed."
• The UID is optional in a GEDCOM 7 file, and there is no guarantee that an app reading it will preserve it.
• EXID (e.g., a FamilySearch ID) is another mechanism that might be usable for this purpose.

[dapug]

This is what I thought, thank you for clarification.

I believe I could achieve the use case I described if the vender decides to use and maintain unique IDs (UID or EXID) in their exports. That would mean that if my application has this requirement of unique IDs, it would not support just any GEDCOM, but can support a select set of vendors known to use unique IDs (and specifically, must support knowing what they exported last time, and maintaining those same ID's in the next export for that tree). Does that sound correct?