One agreed list, and every past version still answerable
Currency codes, cost centres, country codes, and product codes get copied into each consuming system and then maintained there separately, until the copies disagree. A change in one place never reaches the others, and a query about last March returns today's values. TopQuadrant governs those lists centrally, with owners, effective dates, and successor pointers, and publishes one feed every system reads.
Trusted to govern the data behind the world's most regulated decisions.
Small, slow-changing, referenced by everything - which is why a stale value travels so far
The usual state is several copies: one in the warehouse, one in the ERP, and one in a spreadsheet Finance keeps because neither of the others was trusted. None of them is wrong on the day it is created. They diverge quietly, and the divergence is only discovered in a report that has already gone out. Governing the list once and publishing it outward is a short project with a long tail of benefit.
One published list per domain, replacing the parallel copies that accumulate when every consuming system maintains its own.
Of retired codes stay resolvable, with a pointer to their successor, so historical records and reports never break.
Prebuilt connectors, so a governed list reaches the warehouse, catalog, and operational systems that consume it.
Effective dating
How do you query a code list as it stood six months ago?
Every value carries a validity period. A cost centre live from 1 April is invisible to a query dated 15 March. A currency code retired at year end still resolves for the historical transactions that referenced it. The timeline is part of the model rather than something the application layer has to reconstruct.
- Start and end dates on every value, as first-class fields rather than a convention the team maintains by hand.
- Point-in-time queries. Ask for the list as of any past date and get the state that was live then.
- History without snapshots. The timeline is derived from the model, not from storing a fresh copy of the list on every change.
Deprecation with successors
What happens to old codes when a list is restructured?
Retiring a code is not deleting it. Historical transactions, reports, and integrations still reference it, so it has to keep resolving. The model records a retirement date and a pointer to whatever replaced it, and a system meeting an old code can follow the chain forward instead of failing. The transition is part of the governed asset, not a note in someone's spreadsheet.
- Retire, never delete. Deprecated codes stay in the graph with their retirement date and a successor relationship.
- Successor chains. One code can be succeeded by a single value or split into several, and the chain is traversable both ways.
- Audit-ready transitions. Every retirement carries who authorised it, when it took effect, and what replaced it.
Crosswalks to external standards
How do you stay aligned to ISO or NAICS when the standard changes underneath you?
Crosswalks between your internal codes and an external standard are versioned assets, not a lookup table someone keeps in a spreadsheet. Each correspondence records which release of each side it was asserted against and on what basis. When the standard publishes a new version, every mapping now pointing at a retired or restructured concept is listed, before anything downstream breaks.
- Version-anchored correspondences. Each mapping records the release of the source and the target it was validated against.
- Mapping provenance. Who asserted it, when, and whether the match is exact, broader, narrower, or approximate.
- Drift detection. A new standard release produces a list of what needs review rather than a silent failure months later.
Publish once, consume everywhere
How does one governed list reach every system without a separate integration each time?
A governed list is only worth something where it is used. Each published domain is available as an API, a SPARQL endpoint, a scheduled file drop, and a push into the warehouse and catalog. Consuming systems read the canonical list instead of caching a copy, so a steward's change does not need a deployment in every downstream system to take effect.
- API and endpoint access. Systems query the governed list directly, with no intermediate copy and no cache to invalidate.
- Warehouse push. Governed dimensions land in Snowflake, Databricks, or BigQuery on a schedule, as certified reference tables.
- Catalog sync. Collibra, Informatica, and Alation reflect the same values and effective dates the stewards maintain.