Master data management: one record for a person, place, or asset

Reference article · 5 min read

Most agencies hold the same resident, parcel, business, or piece of equipment in several systems at once. Permitting knows a property by its situs address, utility billing by an account, code enforcement by a case number, the assessor by a parcel number. Each record is correct inside the system that created it, and none of them agree on spelling, formatting, or which version is current. A count of properties or active businesses gives a different answer depending on where it started.

Master data management is the practice of deciding what one authoritative record looks like for each shared concept, and how the scattered copies relate to it. Part of that is technology. Most of it is governance: who owns each field, which system wins when two disagree, and what happens when software decides that two records are the same person and is wrong.

What counts as master data

Master data is the set of entities the agency refers to repeatedly: residents, businesses, employees, addresses and parcels, vehicles and equipment, facilities, accounts. It is distinct from the transactions attached to them and from reference data such as shared code lists.

Scope is the usual failure point. An effort that masters every entity at once produces a long design phase and no working record. Pick one entity and one reporting question that gets two answers today.

Golden records, matching, and survivorship

• Golden record. The assembled best-known version of an entity, built from the source records rather than replacing them. It carries the identifiers of the records behind it, so any value can be traced back.
• Matching. Deterministic matching compares normalized keys such as a parcel number, license number, or standardized address. Probabilistic matching scores a weighted comparison of attributes such as name, date of birth, and address. Most agency work uses both.
• Thresholds and stewardship. Scores above a high threshold merge automatically, scores below a low one stay separate, and the rest go to a review queue a person works. That queue is ongoing staff effort, and a program that does not fund it will drift.
• Survivorship. The rules deciding which value wins, applied field by field rather than record by record. Mailing address might survive from billing, legal business name from licensing, the most recently verified value in a tie.
• Reversal. Some merges will be wrong. A merge must be undoable, with enough lineage retained to restore the originals. Two residents combined in error is a service failure and can be a privacy problem.

Source of truth is a field-level decision

Agencies often try to name one system as the source of truth for an entity and find that none qualifies. Assign the designation attribute by attribute instead. GIS or the assessor may be authoritative for parcel geometry and situs address, the clerk's system for business legal name, the customer information system for mailing address and phone.

Record the assignments in a data dictionary that names an owner for each field, and make that owner a program manager rather than only an IT staff member. The owner decides what a correct value is, and IT implements it. Note which systems may write each attribute and which must accept it.

The shared identifier

The most durable and least expensive first step is usually issuing a persistent identifier for each entity and requiring systems to store and return it. Useful identifiers are meaningless: no department code, no year, no initials, never reused, never reassigned. A cross-reference table maps each system's own key to that identifier, and reports join on it rather than on names and addresses. Start with the systems the agency controls, then require the identifier through an API in every replacement and renewal.

Linking records about people across programs can carry legal limits. Health, tax, criminal justice, student, and some benefits data each carry rules on use and disclosure, and those rules change. Confirm what applies with counsel and the program office before designing the link.

Platform or pattern

Commercial master data management platforms provide matching engines, configurable survivorship, stewardship interfaces, version history, and APIs. They earn their cost when several domains are in scope, volumes are high, probabilistic matching with human review is unavoidable, and stewardship will be staffed.

The disciplined pattern is a cross-reference table, a normalization routine, documented match rules, a golden record view, and a small review application, built with tools the agency already runs. It fits when one or two domains matter, reliable keys exist, and volumes are moderate. Neither choice settles the governance questions, and a platform bought in the hope that it will tends to sit unconfigured.

How to start, and what to ask vendors

1. Choose one entity and one report that disagrees today.
2. Pull extracts from every system that holds it and count the records.
3. Run a matching test, then review a sample of matches and near misses by hand. That error rate is the baseline.
4. Assign field-level ownership and write it down.
5. Stand up the identifier and the cross-reference table, and fund the review queue before expanding scope.

Ask vendors how staff view and change matching rules, whether the product can be tested against agency data before award, whether merges are reversible with lineage retained, and how licensing cost grows as records and sources are added.

In the contract, require export of golden records, match decisions, and cross-reference mappings in a documented open format on demand and at termination. Tie acceptance to measured match quality against a hand-reviewed sample rather than to installation.

HQT works with agencies on data platforms, integration, and the governance behind them, including identifier and matching design that agency staff can operate.

Frequently asked questions