Deep Battle Cards G–L
G — Business Rule vs DQ Rule vs Metric vs Threshold
Definition: business rule expresses expected behavior; DQ rule creates a dimension-aligned test; metric calculates conformance; threshold decides acceptability.
Flow: EXPECTATION → TEST → SCORE → PASS/FAIL.
Owners: business owners/Stewards approve expectations; DQ/technical teams implement tests/reporting.
Scenario: “Every U.S. customer must have ZIP” → rule; “97.4% conform” → metric; “must be ≥99%” → threshold.
Trap: a sentence such as “≥98% complete” can combine rule and threshold; separate the layers mentally.
Source: pp. 432–434, 454–456.
H — DQ SLA vs Scorecard vs Issue Report
Definition: SLA = service expectation/response commitment; scorecard = summarized quality status; issue report = case-level incident/assignment/resolution state.
Purpose: commit service vs communicate condition vs manage workflow.
Deciding distinction: commitment vs condition vs case.
Scenario A: resolve critical supplier defect within four hours → SLA.
Scenario B: completeness 97%, validity 99.2% → scorecard.
Trap: scorecard alone does not define who responds by when.
Memory: SLA promises; Scorecard shows; Issue report tracks.
Source: pp. 446–450.
I — Parsing vs Standardization / Transformation vs Enrichment
Definition: parse = decompose/recognize; standardize = change representation; enrich = add data/context.
Inputs: raw values/patterns; target standards; trusted external/internal context.
Outputs: components; standardized values; augmented records.
Deciding distinction: decompose vs change vs add.
Scenario: split PERSON_NAME → parse; convert Tenn. to TN → standardize; add latitude/longitude → enrich.
Trap: standardization does not prove accuracy.
Memory: PARSE pieces; STANDARDIZE form; ENRICH more.
Source: pp. 451–453.
J — Fully Automated vs Manually-Directed vs Manual Correction
Definition: fully automated commits under deterministic rules without human review; manually-directed combines automation/confidence with human review; manual is human-performed through controlled interface.
Deciding distinction: where is the human control point?
Scenario A: low-confidence identity match routed to Steward → manually-directed.
Scenario B: deterministic postal-format correction auto-commits → fully automated.
Trap: manual ≠ uncontrolled direct production SQL.
Memory: AUTO commits; DIRECTED reviews; MANUAL performs.
Source: pp. 458–459.
K — DQ Function vs Improvement Project
Definition: DQ Function = ongoing BAU capability; improvement project = temporary scoped change initiative.
Outputs: continuous rule/monitor/issue operations vs project-specific remediation.
Deciding distinction: ongoing vs temporary.
Scenario A: six-month duplicate remediation → project.
Scenario B: daily monitoring/rule/issue response after project → function.
Trap: do not close DQ operations when cleanup ends.
Memory: Project fixes; Function lives.
Source: pp. 424–426, 445–450.
L — Top-Down vs Bottom-Up vs Hybrid Implementation
Definition: top-down gives sponsorship/consistency/resources; bottom-up discovers actual problems and demonstrates incremental wins; DAMA generally favors hybrid.
Purpose: combine authority with evidence.
Inputs: readiness, pain points, support, actual-state evidence.
Outputs: roadmap, funded operations, incremental improvements.
Deciding distinction: sponsor + discover.
Scenario: leadership funds standards while teams profile priority domains and deliver wins → hybrid.
Trap: “hybrid” here is implementation approach, not Metadata architecture.
Memory: TOP funds; BOTTOM finds; HYBRID works.
Source: pp. 459–462.