Identity architecture within FAO geospatial platform work
GeoID is the feature-identity design within DynaStore’s geospatial work. It separates the identity of a feature from the catalog, collection and backend identifiers used to locate or serve it.
Catalog names, storage names and URLs can change as data moves or systems evolve. If these locations are treated as feature identity, a move can look like a new entity to clients and downstream representations.
The design problem is keeping domain identity stable while allowing catalogs, collections and storage drivers to retain their own responsibilities.
The inspected DynaStore source distinguishes canonical feature IDs from external catalog/collection identifiers and backend document/index names. Write boundaries resolve external references to immutable internal IDs before persistence.
New writable feature identities use UUIDv7. File-backed features derive deterministic UUIDv5 identities scoped by catalog, collection and source feature ID. These are different identity policies for different source capabilities.
External catalog/collection references and source feature IDs enter a resolution boundary. Canonical feature identity is kept separate from PostgreSQL keys and search document/index names. Writable and file-backed identity policies are deliberately distinguished.
The writable identifier helper describes process-local monotonic behavior and random bits. A UUIDv7 identity is not proof of global transaction ordering, cross-process sequencing or authorization.
Deterministic file identity needs a clear source scope: catalog, collection and source feature ID. A retrospective alternative is deriving identity only from a raw source ID; it is simpler but loses that scoping and can collide across independently named sources.
The inspected repository contains identity helpers and item service boundaries supporting this distinction. A published technical article explains the GeoID design.
This case describes source mechanisms and architectural intent. It does not claim all public references are resolvable forever, every data migration is transparent, or identity generation itself enforces access control.
A persistent identifier is useful when the surrounding system can explain resolution, changes and access. Its format alone cannot guarantee those policies.
For further validation I would test source moves, catalog renaming, external-ID reuse and deterministic identity across file reloads, then inspect each authorization boundary independently.
Writable features need new domain identities. File-backed features can derive identities from a stable scoped source reference. Their guarantees are different and should be tested separately.
Read the relevant sectionNo. The inspected helper’s local monotonic behavior is narrower than a distributed transaction ordering guarantee.
Read the relevant sectionNo. Identification and authorization are separate responsibilities. Every route that resolves or serves an entity needs its own access enforcement.
Read the relevant sectionInspected snapshot 4da3f58bf704b26dec8191794fe98d364dc16eaa; FAO programme with colleagues; identifier and item service contracts in supplied inspected research
Published September 2026; Author’s technical explanation
Complete nine-slide revised July 2026 presentation: stable UUIDv7 feature identity, operation routing, storage capabilities and deployment choices. Demonstration descriptions make no benchmark latency claim.
Carlo Cancellieri. Revised source edition, July 2026. Public repository cited in the slides: github.com/un-fao/GeoID.
