Glossary
The vocabulary this documentation uses, defined once. Where another master data management platform uses a different word for the same idea, that word is listed as a synonym so you can find the page you are looking for.
Terms are grouped by the part of the platform they belong to.
Core model
Entity
A single real-world thing the platform masters — a person, an organization, a place, a product. An entity has attributes, participates in relationships, and is the unit that matching operates on.
An entity is distinct from its 360 view, which is the entity plus everything connected to it.
You may know it as: record, member, object.
360 view
An entity together with its relationships, interactions, consent records, crosswalks, and merge history — the complete picture of one real-world thing.
You may know it as: profile, single view, customer 360.
Golden record
The governed, canonical version of an entity: for each attribute, the value or values chosen from every contributing source by survivorship rules. Most strategies settle on a single value; aggregation deliberately keeps every distinct one, which is how an entity holds several addresses or phone numbers at once. This is what the platform serves to applications, agents, and people.
Some platforms call the per-source input a "master record". This documentation never does. Here, the survivor is the golden record, and its inputs are source records.
You may know it as: best version of the truth, operational value, survivor, consolidated record.
Source record
One system's version of an entity, before consolidation. Several source records contribute to a single golden record.
You may know it as: contributing record, master record (elsewhere).
Source system
A system of origin that supplies data — a CRM, a core banking platform, a patient administration system. Every crosswalk names the source system it came from.
You may know it as: system of record, publisher, data provider.
Crosswalk
The link between a golden record and one source system's identifier for it. A crosswalk answers "which record in that system is this same real-world thing?", and it is what makes a merge reversible and lineage traceable.
Elsewhere in this market the word "crosswalk" is used for mapping code values between systems. That concept exists here too, but it is called transcoding. In this documentation a crosswalk always links a record to a source system, never one code value to another.
You may know it as: cross-reference, XREF, source key.
Attribute
A named piece of data on an entity. Attributes are defined per entity type, carry a data type, and may be single-value or multi-value.
Multi-value attribute
An attribute that legitimately holds several values at once — several email addresses, several addresses. Each value can carry a usage type (home, work, mobile) and one may be marked preferred.
Relationship
A governed link between two entities: an ownership, an employment, a household membership. Relationships have types and can carry an effective period.
Temporal history
Every business record keeps its full change history, with each version bounded by the period it was true for. History is gap-free and non-overlapping by construction, so you can ask what any record looked like at any past moment.
Matching and merging
Entity resolution
Deciding which records refer to the same real-world thing. This is the analyst and industry term for what this documentation calls matching and merging.
Industry term. Included because evaluators search for it.
Match profile
The complete, versioned configuration that governs how one entity type is matched: its blocking strategies, its comparison levels, its weights, and its thresholds. A tenant can hold several profiles per entity type, with one active at a time.
Blocking key
A short derived value used to gather candidate records worth comparing, so the engine does not compare every record against every other. Blocking is about recall and cost, not about deciding a match.
You may know it as: match token, bucketing, binning.
Comparison level
One rung on an attribute's ladder of agreement — exact, then phonetic, then prefix, then a catch-all mismatch. The engine walks the ladder and takes the first rung that fits.
Match weight
The evidence one attribute's agreement contributes, in log2 evidence units. Weights sum across attributes to a composite weight.
Weights and thresholds here are on a log2 evidence scale, not a 0–1 score and not a percentage. Most other platforms use a bounded score, so this is the single most common source of mis-tuned configuration. See how probabilistic scoring works.
Probabilistic matching
Deciding whether two records match by weighing how much evidence their agreements and disagreements provide, rather than by evaluating fixed rules. Contrast deterministic matching.
You may know it as: fuzzy matching, statistical matching. This documentation avoids both — "fuzzy" understates what the engine does.
Deterministic matching
Deciding a match from an exact agreement on an identifier strong enough to stand alone — a national identifier, a passport number. Fast and certain when the identifier is present and trustworthy.
Auto-link
The tier where the evidence is strong enough that the platform merges without asking a person.
You may know it as: auto-merge, automatic match.
Clerical review
The tier where the evidence is suggestive but not conclusive, so the pair is queued for a data steward to decide. The band between the auto-link threshold and the clerical review threshold is where human judgement is applied.
You may know it as: manual review, potential match review.
Potential match
A candidate pair awaiting a decision in the clerical review queue.
You may know it as: suspect match, similar entity, potential duplicate.
Survivorship
The rules that choose which value wins for each attribute of a golden record when sources disagree. Strategies include source priority, most recent, oldest value, maximum, minimum, frequency, and aggregation.
You may know it as: attribute composition, trust rules, consolidation rules.
Merge
Combining records that resolve to the same real-world thing into one golden record. Every merge is reversible: the contributing records and their crosswalks are preserved.
Unmerge
Reversing a merge, restoring the previously absorbed records.
Data quality
Standardization
Transforming a value into its canonical form before it is stored and compared — normalizing an email address, formatting a phone number, parsing an address. The standardized value is the value the platform keeps.
Validation rule
A constraint an attribute value must satisfy, evaluated on write. Violations carry a severity and are recorded against the record.
Data quality score
A composite score for a record, computed from weighted dimensions: completeness, accuracy, consistency, timeliness, and uniqueness.
Reference data
Reference data
Controlled lists of permitted values — countries, currencies, status codes, classification schemes — managed centrally and reused across entity types.
You may know it as: lists of values, code lists, lookups.
Lookup type
One controlled list. It holds lookup values.
Lookup value
One permitted entry in a lookup type: a stable code and a human-readable label. Attributes bound to a lookup type accept only its codes.
Transcoding
Mapping a source system's code to the platform's canonical code — turning one
system's US and another's USA into a single agreed value.
Crosswalk links a record to a source system. Transcoding maps a code value to a canonical one. Some platforms use the word "crosswalk" for this second idea; this documentation does not.
Hierarchy
An ordered, levelled classification — an industry taxonomy, a geographic rollup — that entities can be classified into and aggregated over.
Governance
Tenant
An isolated customer workspace. Every record belongs to exactly one tenant, and isolation is enforced in the database itself, not only in application code.
Permission code
The unit of authorization, in resource.action form. Every endpoint declares
the codes it requires.
Role
A named bundle of permission codes. Roles are composed per tenant.
Group
A collection of users that can be granted roles collectively, usually mirrored from your identity provider.
Attribute-based access control
Policy that decides access from attributes of the caller, the record, and the request context — not merely from the caller's role. Used to express rules like "only while a consent is active" or "only for records related to you".
Row-level security
Database-enforced isolation ensuring a query can only ever see rows belonging to the caller's tenant.
Field masking
Redacting or transforming a field's value in a response, based on who is asking. Applied when the response is generated, so it cannot be bypassed by calling a different endpoint.
Data steward
The person responsible for the quality and correctness of mastered data: resolving potential matches, fixing values, and managing relationships.
You may know it as: data custodian.
Operations
Bulk job
An asynchronous unit of work — a large ingest, a recompute, a rescore — that runs on a worker fleet rather than in a request, and reports progress as it goes.
Consent record
A record of a data subject's permission for a specified purpose, with its legal basis, captured so processing decisions can be justified.
Data subject request
A privacy request from an individual exercising their rights — access, correction, erasure — tracked from receipt to fulfilment.
Interaction
A recorded event involving one or more entities: a branch visit, a support call, a clinical encounter.
Webhook
An HTTP endpoint the platform calls when a subscribed event occurs, so external systems can react to changes.
Audit log
The append-only record of what happened, who did it, and when. It cannot be modified or deleted, and gaps in its sequence are detectable.
Last verified against commit 315eb047 (2026-08-03)