Mastering, quality, exceptions and sensitive data — the working disciplines of the people who keep golden records trustworthy day after day. About 260 minutes of reading, seven checkpoint quizzes, and the certification exam at the end.
Stuck on a concept? Ask in your own words — answers come from the course material with links to the source lessons. Signed-in learners only; daily limit applies.
Recommended, not required — the exam is open to anyone. If you have not taken Foundations, module 0 covers what this course assumes in about ten minutes.
Haven't taken it? Module 0 — Before you start — the assumed ground covers what this course assumes, in about ten minutes, with a self-check at the end.
What this course takes for granted, condensed. Skip it if the Associate material is already familiar.
This module exists so that arriving without the Associate track is an inconvenience rather than a wall. It is a recap, not a substitute — if these five words are already comfortable, go straight to module 1.
Two of those carry the whole stewardship job. Matching decides which source records are the same real-world thing. Survivorship decides, attribute by attribute, which value wins when the matched records disagree. They are separate decisions with separate rules, and confusing them is the most common way a golden record ends up wrong in a way nobody can explain.
The studio's sidebar has nine destinations. Four of them are where a steward lives:
The rest — Modelling Studio, Integration Hub, Governance, Administration, Help — you will meet, but you will rarely own.
The habit worth bringing from Foundations is one sentence: unknown is not zero. A score that could not be computed reads NOT MEASURED, not 0%; a report value that could not be computed renders unavailable with its reason, not as a confident zero; a hierarchy with no records says so rather than showing an empty tree. Every screen in this course is built to tell you the difference between nothing there and nothing measured yet, and stewardship goes wrong fastest when someone reads the second as the first.
How duplicates become one trusted record: matching, survivorship, golden records and their evidence.
Matching clusters source records that represent the same real-world thing. A match ruleset scores record pairs on chosen attributes — exact on business keys like a customer number, fuzzy on names, emails and addresses — and thresholds split the outcomes into three named decisions: AUTO_MERGE, REVIEW, and NO_MATCH.
Each rule picks a comparator, a weight, a threshold and a blocking key. The comparators are real algorithms, and choosing the right one is most of the craft: EXACT and NORMALIZED for keys and codes, PREFIX for truncated values, FUZZY (Levenshtein) and Damerau-Levenshtein for typos and transpositions, Jaro-Winkler for short human names, Metaphone for names that sound alike but are spelled differently, and DATE_TOLERANCE for dates that disagree by a few days.
The steward's craft is in the thresholds. Too loose and different people merge into one record (the most damaging failure); too strict and duplicates survive. Start conservative, review what lands in the middle band, and tighten deliberately. The rule tester lets you score sample pairs before a ruleset ever runs.
Pairs that score between the thresholds queue for match review — a steward confirms or rejects each proposed match. Review is not an apology for imperfect rules; it is where judgement belongs: two "J Smith" records at the same address may be father and son, and only context decides.
Review decisions are recorded and feed the audit trail. When you find yourself accepting or rejecting the same pattern repeatedly, that is a signal to adjust the ruleset — encode the judgement once instead of repeating it forever. Sensitive values in the review screens respect your clearance: masked values stay masked.
Once a cluster is agreed, survivorship chooses the winning value for each attribute. Strategies are set per entity and per attribute: most trusted source (the source with the highest trust score wins), most recent, most complete, longest value, most frequent, or a custom expression when the rule is genuinely yours and none of the standard five fit.
Trust scores rank your sources per entity — billing may be the authority on addresses while CRM owns email. Setting them honestly is a stewardship act: survivorship is only as good as the trust model behind it. The survivorship plan preview shows what will happen — clusters, singletons, expected golden count — before you run it.
Where sources disagree, the run records a conflict you can inspect field by field, and unresolved conflicts arrive in My Work as their own task type. On large sets the runner refuses to proceed past its configured row cap rather than silently truncating the run — a loud stop is a feature, not a fault; raise the cap deliberately or run in chunks.
A Survivorship Advisor can propose strategies from what it observes in your data. Like the rest of the advisor family — match, DQ rule, standardization, crosswalk, trust, placeholder — it is a deterministic, explainable rule engine, not an AI model; a couple of surfaces may attach a labelled one-sentence comment from a language model beside the arithmetic, and that comment never changes the result. Advisors propose; you decide.
Running survivorship collapses each cluster into one survived record; publishing promotes those into the governed golden-record store with full cross-reference (xref) lineage. From the golden browser you can open any record and see, per field, which source won and by which strategy — and every contributing source row.
Stewards also operate on golden records directly: merge two goldens that are really one, split or unmerge one that shouldn't have merged, and restrict a record that needs protection — even before it is first published. Every record carries an evidence-based confidence score and a status: publishing never deletes, it marks disappeared records Superseded and revives them if the source returns. Each operation is audited and reversible through the same disciplines that created the record.
Right-clicking a row in the golden grid opens the record's own menu — view exceptions, open record, trace, lineage web, sample values, filter by this value, copy golden key. It is a shortcut, never a bypass: anything destructive still opens the page's normal confirmation, and an item you may not use is greyed out with the reason written on it.
Not every master record arrives from a source system. Mastering → Author Records lets a steward, data owner or admin create and edit a golden record directly in the hub, through a form generated from the entity's Data Dictionary and validated against that entity's DQ rules before it saves. Authored values carry MANUAL provenance, so lineage never pretends a human-entered value came from a source, and the entity can require an approval workflow before an authored record goes live.
Use authoring for the records that legitimately have no upstream owner — a new legal entity, a correction agreed with the business — and resist using it to paper over a broken feed. A value you type today is a value the next pipeline run may argue with; if a source should own it, fix the source or the survivorship policy instead.
Mastering → Record Timeline is the other half of the story: golden records are bi-temporal. You can ask what a record looked like as of a business date, and what the platform knew at a point in time — two different questions, and the difference is exactly what an auditor asks about. The timeline shows effective-dated versions, when each became current, and what changed.
Analytics → GR Explorer walks the golden set through its relationships. Start on an entity, see the domain-to-domain relationship strip, then open a tab per relationship to see the related golden rows resolved through the relationship's key columns — and pivot: any related row becomes the new focus, with a breadcrumb trail behind you (Customer ▸ Order ▸ …). It is read-only and consumption-grade: the same row menu, publish line, population badges and exception-ordered columns as the golden grids.
Two things make the walk faster. Every relationship tab carries a row count, so you can see which relationships actually hold rows without opening each one — and a count that could not be computed draws a dash, never a zero, because “none related” and “this relationship cannot be resolved” are different answers and only one of them is about the data.
The search box can also reach through the relationships. Somebody hands you a Sales Order key and asks whose customer it is: turn on related keys and searching that key on the Customer entity finds the Customer that owns it. Previously that meant switching entity, reading the join column off the row, switching back and filtering by the value.
Two properties of that search are worth understanding, because they are what make it safe to use as evidence. First, it says how far it reached — the result names the related entities it searched, and names the ones it skipped, whether because the relationship declares no attribute on both sides or because you have no access to that entity. A silently narrowed search is indistinguishable from a record that is not there. Second, a record you are not cleared to see can never be used as a lens onto one you are: the match itself would disclose that a record with that key exists and is linked to this one, so the search fails closed rather than filtering the row out afterwards. Searching by a restricted record’s key finds nothing through it, and that is the correct answer rather than a gap.
Entities with a navigable hierarchy also gain a Hierarchy rail beside the grid, with a source picker offering up to four never-blended sources. Tiers is the model's tier dimension as a bidirectional ladder — a clear button per pick, up/down steppers, arrow keys — and clearing a broad tier drops the narrower picks beneath it; where a tier's field is standardized but not yet mastered, the ladder notes that it groups by the cleansed value. Record tree is the entity's own parent-key structure in the published data, shown with business names leading and codes muted; records with no parent group under a visible amber "Unparented (N records)" divider instead of masquerading as roots. Managed is a maintained hierarchy from the Hierarchies workbench. Value hierarchy is a declared containment chain bound on the entity, walked level by level — and unlike tiers, where every pick is sent because the levels are independent columns, here the deepest pick is the filter: Johannesburg is already inside Gauteng. Its optional derive toggle (off until you turn it on) also shows records placed by the hierarchy from a lower level, labelled, with nothing written. Picking a rail value filters the grid — including cross-entity, so a Product Category tree can filter Products. The rail is a persisted treeview: one fetch, your expansion remembered across visits, an oversized tree says it was capped rather than pretending the visible slice is everything, and a capped branch is never drawn as a leaf. An entity with no hierarchy shows no Hierarchy control at all — absence is the honest answer. And when published data merely behaves like a tree with no hierarchy declared, the Explorer shows a measured one-line suggestion with its evidence (how many records resolve, how many do not, how many roots) and Declare this hierarchy / Dismiss buttons — declaring goes through normal governance, nothing is inferred from column names alone, and a dismissal lasts for the session.
Every surface that renders a hierarchy — this rail, the Hierarchies workbench, Data Quality's By-hierarchy view — resolves the hierarchy's label attribute: the node shows the category name, with the code muted after it. The label is chosen when a hierarchy is created from a parent relationship (the "Node labels from" picker) and can be changed later from any surface that shows the tree — the change is saved on the hierarchy, and every surface follows.
Analytics → Report Center is the gallery of published reports and dashboards — where the rest of the business meets your work without needing to know what survivorship is. It is empty until report definitions exist, which is a content gap, not a fault.
Both screens need a completed MATCH → SURVIVE → PUBLISH run behind them. On a fresh install they will be empty, and that is the correct behaviour: they show the published master, and nothing has been published yet.
Measuring what "good" means and systematically fixing what fails.
Profiling examines an entity's actual content: completeness per column, distinct values, patterns, min/max and outliers. It answers the question every remediation plan starts with — which fields can we trust, and which are noise?
Profile before you author rules: a column that is 40% empty needs a sourcing conversation, not a validation rule. Profiling both source previews and the mastered model lets you see whether problems originate upstream or were introduced by mapping.
Validation rules encode what good data means: an email matches a pattern, a customer number is present and unique, a credit limit sits in a sane range. Rules carry a severity and a dimension (completeness, validity, uniqueness, consistency…), and group into rulesets per entity.
Authoring is assisted end to end: the rule advisor infers the dimension, operator, pattern and threshold from the rule's name — deterministic and explainable, backed by a curated regex library rather than a language model — and declarative operators (starts/ends with, contains, casing, trimmed) cover common checks with no regex at all. Every rule gets a unique auto-numbered code. Test a rule before saving it (dry-run against live data), then run the ruleset to produce a quality score with per-dimension breakdowns. Scores are not decoration — they are the baseline you defend: a falling score after an ingestion run points straight at the batch that caused it.
Scores are read in the tabbed Data Quality report — Overview, Entities, By tier, By dimension, By hierarchy, Coverage, Targets, Domain Health — where clicking a domain or entity in the scope tree selects and filters everything on the page. Dimensions carry their letters (C·V·U·Cn·I·A·T) with a legend, and grey means not measured — not a pass, not zero. By tier groups entity → tier level → values with record-weighted rollups and record-count pills, and a row whose tier level was never recorded lands honestly in "(level unknown — recompute scores)" rather than being guessed into a level. By hierarchy scores quality down a tree through the same three never-blended lenses as GR Explorer — Managed tree, Record tree and Tiers — each disabled with its reason written on it when that source does not exist for the entity. Tree nodes carry their own-record pill and an "N below" subtree pill; the Tiers lens drills level by level in place, and a "(no value)" row cannot be expanded — it is a finding, not a branch.
Rows that fail rules land in Exceptions with the failing rule, value and severity attached. The steward's loop: filter to the worst severities, fix the underlying value (or the source), and resolve with a typed resolution — Corrected, Fixed at source, or Accepted. The platform then re-validates automatically: a still-failing value reopens the exception immediately, so an ineffective fix can't hide. Rules flagged for auto-remediation apply the attribute's standardization cascade and close their own exceptions. Exceptions you deliberately accept can be ignored with reason — visible, not buried, and never counted as progress.
The queue is not a flat list. Its left tree rolls open exceptions up domain → entity, with dimension and severity drill-downs underneath each entity, so you can see where the damage is concentrated before you touch a single row; the tree's selections are deep-linkable, so "the Customer / Address completeness pile" is a URL you can send someone. Your own assigned exceptions also appear in My Work alongside every other task type, ranked by SLA.
The queue can also be read as a list of rules rather than a list of records — Group by rule — which is the view for "which checks are failing most" rather than "which rows"; counts stay the same, only the grouping changes. Failed records are flagged wherever golden data is browsed, so quality problems surface exactly where people use the data. An exception queue that only ever grows is a process problem, not a data problem — which is what campaigns exist to fix.
A workflow worth practising: start in the Data Quality report's By hierarchy or By tier tab to see where in the business structure the damage concentrates — a branch with a weak score and a heavy record pill, or a "(no value)" row, is a located finding — then take that scope to the exception queue's domain → entity tree and work the pile it points at. Hierarchy tells you where; exceptions are where you fix it.
A campaign turns a pile of exceptions into an assigned, trackable effort: pick a scope (entity, rule, severity), split it into batches, assign batches to stewards, and work the queue with Work this campaign. Progress is honest — resolved, ignored and bounced are counted separately, and the pass rate is snapshotted at launch so "at launch X% → now Y%" measures real improvement. Campaigns give remediation a deadline and an owner — the two things ad-hoc fixing never has.
Use campaigns for the big pushes (a legacy load's worth of bad phone numbers) and the steady drumbeat (this week's new exceptions). The campaign view is also your evidence to management that quality work is happening and finishing.
One thing campaigns deliberately do not do: there is no delete. A campaign is a record of an effort that was made, so it is closed out, not erased.
Three screens in the Quality hub answer questions before a rule or a match ruleset exists.
Placeholder Advisor reads a completed profile run and finds the values that are pretending to be data — "N/A", "UNKNOWN", "0000000000", the same email on 4,000 rows. These matter far beyond completeness: a placeholder acting as a match key silently merges thousands of unrelated records. The advisor shows its evidence and proposes; applying anything is an explicit review step, never automatic.
Source DQ runs quality checks directly against a raw source table with no model involved — the answer to "is this feed even worth mastering?" before anyone maps a column. A check that proves useful can be promoted into a real DQ rule on the modelled entity.
Source Comparison is a read-only diff across systems of record: same real-world thing, three systems, which fields actually disagree and how badly. It has two modes. Matched records compares the sources inside a match cluster, so it needs a completed match run. Tables compares raw source tables directly by a record key you choose — no model, no match run — which is the mode to reach for before anything is mastered (the next lesson walks it). Either way it is the fastest way to build the trust model that survivorship will later depend on — and unresolved comparison conflicts arrive in My Work as their own task type.
All three need something behind them — a profile run, matched data, or a pair of connected source tables; on an empty install they have nothing to say, and they say so.
Turning a rule off with is_active has no memory: it stays off until a human remembers. A suspension is a window instead — a date the rule comes back and a mandatory reason. The rule stays configured, stays visible, stays in its rule set, and resumes by itself.
The law worth memorising: a suspended rule is not a passing rule. It follows the same path as a rule that cannot be evaluated at all — no pass rate, no exceptions, no side effects — and the run's aggregate reports how many rules it did not evaluate. A suspension therefore never flatters your score; it removes a measurement and tells you it did.
Four things happen without you: an expired suspension resumes (and the platform records that it did); a rule whose target attribute has vanished is auto-suspended; a persistently noisy rule — roughly 1% pass or worse across three consecutive runs — produces a proposal and nothing else; and you are warned before a suspension expires. The noisy-rule panel says it out loud: nothing is suspended by this.
Two task types reach My Work from here and they are deliberately different: suspension expiry is a deadline the system will honour, noisy-rule proposal is a question with no deadline. Suspending is classed as operational work, so it does not require a model checkout.
Table mode answers a question the match pipeline cannot yet: do these two systems even agree about the records they both hold? You pick a table on each side, name the record key on each side, line up the fields to compare, and run. Nothing is written; the result is a diff you can read.
The key rarely sits in one column on both sides. A derived key builds it from what is there — concatenate first and last name with a separator, take the digits of a phone number, a substring of a code, a padded number, or the other way round: split a full name to meet a system that stores it in two. Every recipe is described in words on the screen, and a recipe that can lose information (a split, a substring) is marked lossy, so you know when two different records could collapse into one key.
Preview the key before you run. The preview counts rows and unique keys on each side and reports how many keys the other side actually joins to — a key that joins nothing is a diagnosis (no rows, rows but no key, one source only, keys do not join), written on the run rather than left as a silent zero. The key advisor profiles the columns, ranks candidate pairings by how unique, complete and mutually joinable they are, and lets the AI narrate why the top pick is the top pick — the arithmetic decides, the model explains.
Real tables repeat keys. Distinct collapses rows that are exact copies of each other before the diff, and says how many it collapsed. Rows that share a key but differ are the interesting case: by default they are compared copy against copy and reported as within-source conflicts — a finding about that system, kept apart from cross-source differences — instead of stopping the run. Only if you set the key to refuse duplicates does a repeated key block the run, and then the preview tells you before you press Run.
Reading a run: cross-source differences per field, within-source conflicts per source, collapsed copies, and the rows only one side has. A comparison set can be edited after it is saved — the mode, tables, key and fields — and re-run; the run history keeps every earlier answer.
Classification, clearances, masking and restriction — plus row-level access groups: stewardship of who may see which records and which values.
Every attribute can carry a sensitivity level — Public, Internal, Confidential, Restricted — set in the Data Dictionary and cascading domain → entity → attribute, where the highest level in the chain wins. A domain default of Internal with email raised to Confidential is the typical shape.
Classification is the steward's map of risk: it costs nothing at labelling time and drives everything at serving time — masking, restriction and audit all read these levels. Unclassified sensitive fields are the gap an audit will find first.
A clearance grant lets a user see classified values up to a chosen level, scoped to a domain, an entity or a single record, optionally with an expiry. Above their clearance, users see values masked (••••, or partially for contact/identifier fields) — consistently across golden records, reports, exports and review screens.
Masking is serve-time, not storage-time: the data stays intact, only its visibility changes per caller. That means a grant takes effect immediately and a revocation bites just as fast.
A glossary term can also carry a masking policy, which chooses the shape of the redaction: FULL, FIRST_INITIAL, YEAR_ONLY, LAST4 or EMAIL_DOMAIN. Three rules govern it. A policy never decides whether masking happens — that is decided solely by classification level versus clearance, and there is deliberately no "none" or "off" option. When two governing terms disagree, the most restrictive wins and the loser is reported. And a policy the engine cannot parse fails closed to FULL. Note that a policy can legitimately reveal more than the default would (LAST4 on a card number), so treat writing one as a governance decision, not formatting.
Some records are sensitive as a whole — VIP customers, employees, minors. A steward can restrict a golden record with a level and a mandatory reason: users below that level don't see a locked record, they see nothing — lists skip it and direct opens report not-found, indistinguishable from absence.
Access is then the exception you grant: an admin can add a per-record viewer at exactly that record's level. Restriction protects the published (mastered) layer, and clearing it restores normal visibility instantly.
Sensitive access leaves a trail: every restriction, every grant, and every unmasked serve of classified data to a cleared user is logged. The Data Access page's access log shows who saw what, when — the record you reach for when someone asks "who has seen this customer?"
Around all of it sits governance: structural and governed data changes queue as change requests for approval when governance is active, and the audit trail records the decisions. Stewardship is exactly this pairing — the freedom to fix data, inside a system that remembers everything.
One limit to know before you promise it to an auditor: the Audit Trail's search covers username, action, resource type and resource id — the four things printed in the grid. It deliberately does not search the before/after payloads, because a substring search across payloads would be an unrestricted read of governed values the searcher may have no clearance for. "Search the audit trail for a customer's name" is not a thing this product does, on purpose.
Governance → Approval Workflows is a configurable, multi-step approval engine: each step names a role and an SLA, and approve/reject routing decides what happens next. It governs both change requests and authored golden records, and every action is kept as history. This is what turns "someone should check this" into a named person with a deadline.
Governed changes also carry RACI. The catalog's Owner and Steward facets are named Accountable and Responsible; Consulted and Informed are resolved from the asset's own facets when the change is raised — the Consulted are listed on the request, the Informed are notified.
Two details that matter to a steward. First, the RACI written onto a request is a snapshot: an audit fact recorded at the moment of raising, not a live view that changes when someone edits the catalog afterwards. Second, if a name on the Informed list matches no active user, the request says so by name — "not notified" is reported, never quietly dropped. Chase those; an unmatched name is usually a leaver nobody replaced.
Only Accountable and Responsible inherit from a governing glossary term; Consulted and Informed are set on the asset itself.
Classification and clearance decide which values a person may see; access groups decide which records they may see at all. A group grants access scoped by domain, hierarchy tier (e.g. Tier 1 = CORPORATE), value hierarchy (e.g. Province L3 = Johannesburg), a tree node or subtree, or a single column value — the row-level counterpart to a clearance.
Composition is worth learning once. Within one group, different kinds AND together and the same kind ORs (Tier 1 = CORPORATE and (Johannesburg or Sandton)); across a user's groups the grants union (OR). There are no negative rules — narrowing comes from what you are not a member of. And a rule that cannot be resolved is refused, never ignored, because dropping it would silently widen the scope.
A domain is only governed once an administrator arms it; until then nothing changes. When it is armed, a scoped steward sees a filtered slice everywhere at once — the golden grid, the exception queue, quality scores, hierarchy and tier counts — and locked filter chips name the groups doing the filtering, so a smaller number never reads as missing data.
A refusal is a designed answer, not a fault. Ask for a domain your groups do not cover and the product says so by name — "you are not in a group that covers Supplier" — as a calm 403, never a red error and never an empty grid that reads as "no data". A surface your role cannot use isn't shown at all: it's absent from navigation, and a deep link lands you somewhere you can work.
Because one scope rule is applied by every serving surface, every count and calculation aligns to your access groups — a By-tier total, a domain-health figure, a campaign's progress. Two figures a steward relies on: a governed domain you hold no group for is not listed (its absence is stated, e.g. "2 domains you have no access to are not shown"), and a cross-domain campaign rolls up per domain, so you own and see only the slice your groups grant.
Working the external-asset register, and reading the counts that describe it honestly.
The external-asset register is a steward's artefact, and it decays like any other if nobody owns it. Registering is audited but not review-gated: your write lands immediately, with your name on it. That asymmetry is deliberate — recording that a warehouse exists is documentation, and a review queue in front of documentation is how registers go stale. Editing a catalog facet stays governed, because a statement about ownership and meaning should be reviewed.
Retiring is where the judgement lives. Retire never deletes. The dialog states how many links the asset carries before you confirm, and that number is the question: retiring an asset that three glossary terms and two mapping specifications point at is a different act from retiring a stray. On confirm the asset stops being emitted, and the next reindex tombstones it in the catalog — marked gone, its history and its human-set facets preserved, never vanished.
And the limit to keep in mind whenever you trust the register: external assets are the only catalog assets whose truth the platform cannot check. Every other asset is projected from a module that owns it, so a wrong entry there is a bug. An external asset is a person's statement about somewhere else — it is true for exactly as long as a steward keeps it true.
Pipeline Health's source-to-target view carries external specifications as their own section, with their own counts, deliberately kept out of the attribute-coverage numbers beside them. A steward should be able to say why: an external specification does not cover one of your attributes, so folding it into a coverage percentage would make one number mean two things — and a number that means two things is a number nobody can act on.
The same discipline appears as NOT MEASURED. On a hub whose specification version tables predate the release, a set reads NOT MEASURED, not zero. Nothing recorded yet and nothing there are different facts. If you report a zero that was really a NOT MEASURED, you have told your organisation something false — and it is the kind of false that sounds precise.
You will meet the same shape elsewhere: a suspended DQ rule is reported not evaluated, never as passing; a tier node with no record pill means not recorded, never zero; a grey dimension strip means not measured. Learn the pattern once and you read every scorecard better.
The cleansed value reaching the golden record, fixes derived from failures with their proof, and queues scoped by hierarchy that say what they exclude.
An attribute with standardization rules produces a cleansed value — but the golden record only carries it when the attribute's master standardized value flag is on. Off, the rules still run and matching still uses the cleansed form, yet every published golden record keeps the raw survivor: the cleansing is invisible to every consumer. Three things keep that from happening quietly, and a steward should know all three.
The default. The first time a rule is attached to an eligible attribute on which nobody has yet decided, the flag defaults on. The decision is recorded — by whom, when — and the three states stay distinguishable forever: undecided, on, and off by somebody's explicit choice. A recorded human "off" is never overturned by the default, no matter how many rules are attached later.
The offer. Attributes that predate the default are offered, never flipped — switching a column on rewrites its published values at the next Publish, which is a decision, not a migration. Each candidate is previewed against its real data first, and a column whose cleansed value would change records that currently pass their rules is refused until you acknowledge that collateral by name. Where no DQ rule judges the column, the collateral is reported as unknown — which is not zero — and still needs an explicit acknowledgement.
The disclosure. Until a tier-supplying attribute is mastered, its tier groups by the cleansed value while the stored column keeps the raw survivor. The tiers page marks the binding "standardized for grouping — stored value is raw", the Explorer's tier ladder carries the same note, and the offer (which also lives on the tiers page for exactly these attributes) is the way to make them agree. Switching mastering on changes nothing by itself — the cleansed value is published at the next Survive + Publish.
A DQ rule and a standardization rule are near-opposites — one detects a bad value, the other rewrites it — and the exceptions a rule raises are, by construction, the exact specification of what the cascade did not cover. The Fix action (the wrench) on a targeted rule turns that into a governed workflow: it reads the rule's real failing values (distinct, with counts, the cap stated), pairs the rule's operator with a candidate transform from a governed registry, and proves the candidate on the bench — the transform runs over the real failing values and the rule's own predicate re-evaluates each output, so the answer is "this fixed 805 of the 805 exceptions these values account for", with its denominator, never a bare percentage.
Three pairing kinds, each honest about itself: FIXES (the transform makes failing values pass — refused if it proved nothing), ENABLES (it makes the data agree with what the check found — nulling a whitespace-only value fixes zero exceptions, and the panel says that zero is the correct outcome), and NONE (there is no safe transform, and the entry exists to say why).
Accepting creates the standardization rule inactive, assigned, and routed through the same governance a hand-authored rule takes — and the server re-derives and re-proves before creating, so a caller cannot assert its own gate. Because a bench that reads only failing values is blind to the records that were fine, the accept is wired to the preview: a fix with collateral — passing records it would rewrite — is refused until you acknowledge that collateral by name.
The GR Explorer's Hierarchy rail is not only the Explorer's. The same rail, with the same sources and the same laws, mounts on the Exceptions workbench, the pre-publish Golden Records browser and the Golden Fields records grid — one implementation, so a branch means the same records on every surface, and every count beside a scoped grid counts the scoped population.
Each surface adds one honest nuance. On Exceptions, an exception is in a branch when its golden record is — so exceptions with no golden link (a source-record finding, or a record whose golden was re-published away) are excluded while a scope is active, and the filter chip's footnote says so. On the pre-publish browser, a rail pick is evaluated against the published golden records — a survived row is in the branch when its published golden record is — so a branch means the same thing there as everywhere else; survived rows not yet published are outside any branch while a scope is active, and the chip says that too.
And everywhere, a branch too large to resolve blocks the query with its reason rather than silently widening to the whole list. A scoped queue that quietly included what it could not scope — or quietly widened when the branch was big — would be a queue whose counts you could not repeat to anyone. Exclusion, stated, is the honest shape.
Turning quality scores, exceptions and match outcomes into something the business reads without you in the room.
Analytics → Report Center is the gallery of published reports and dashboards, and Report Studio is where they are built. For a steward this matters for one reason: it is how the rest of the business sees what you have done without needing to know what survivorship is.
The sources you will report on most are the ones you already work in — golden records, data-quality scores and exceptions, match pairs and decisions, and pipeline runs. A scorecard split by domain gives one KPI card per domain; a pivot over exceptions by dimension and severity gives the triage list you would otherwise rebuild in a spreadsheet every week.
Two habits from stewardship carry straight over. Unknown is not zero — a value that could not be computed renders as unavailable with its reason, exactly as a NOT MEASURED score does, and a chart that cannot honestly draw its data refuses rather than drawing something wrong. And a subtotal over an average is weighted by the records behind each group, so a domain with eleven records does not carry the same weight as one with eleven million.
Once a report answers a recurring question, stop opening it. A saved view captures a set of filters, sorts and drill positions under a name — make it your default, or share it with the report, and "the version I actually look at" becomes a link rather than a ritual.
A subscription schedules a report or a whole dashboard to arrive by email. One rule matters more than the schedule: each run executes as the subscriber. A subscription can never deliver rows the recipient could not open themselves, so sending a governed report to a wider audience does not quietly widen their access. Where the hub has no mail server configured, a run is recorded as SKIPPED — not reported as sent.
Separately, subscribe to the jobs and job groups you depend on and hear about failures as they happen. One incident sends one message: if you watch both a job and its group, the job — which names the thing that actually failed — is the one that writes.
MDM Studio Certified Data Steward — Exam — 53 questions, 65 minutes, 70% to pass.