Skip to main content
Jira progress: loading…

SSSR-LIST

List Registry

(Addendum to SSSR – Smart Searchable Signal Registry)

1. Introduction

The SSSR List Registry extends the Signal & Asset registries with a third pillar: lists.

It provides a unified way to store, manage, and reference lists of values across the ZAYAZ ecosystem.

Lists can be simple (e.g. file formats, currencies, DeepL language codes) or complex and hierarchical (e.g. NACE classifications, country/region groupings). Instead of scattering these definitions across multiple tables, the List Registry serves as a central authority that other data models can reference via [SSSR_REF: …].

2. Key Principles

  1. Single Source of Truth
  • All lists are catalogued in one place.
  • Prevents duplication and ensures consistency across services.
  1. Mother vs. Child Role
  • Some lists are owned by the List Registry (e.g. file formats, currencies).
  • Other lists are external or authoritative (e.g. ISO countries, NACE codes).
  • In those cases, the List Registry acts as a “Child” that references or syncs from the external dataset.
  1. Nested / Hierarchical Support
  • Lists can have parent-child relationships (e.g. NACE Level 1 → Level 2 → Level 3).
  • This supports structured navigation and hierarchical queries.
  1. Uniform Referencing
  • Just like sssr_assets_registry and sssr_signal_registry, the List Registry integrates with SSSR links.
  • Any consumer can use a consistent [SSSR_REF: …] syntax to resolve list entries, regardless of whether the list is internal (Mother) or external (Child).
  1. Future-proof Design
  • New standards (ISO codes, UNSPSC, etc.) can be plugged in easily.
  • Users don’t need to know where the list originates; the registry abstracts that away.

3. SSSR List Registry

Tables sssr_list_registry (catalog of lists)

GitHub RepoRequest for Change (RFC)