The Merge Policy That Ate the Consent Flag
A healthcare-adjacent wellness app ingests three sources: an app SDK (events + marketing_opt_in boolean), a CRM batch (demographics + email_consent), and a partner feed (purchase history, no consent fields). Governance policy marks email_consent as a sensitive attribute with a data usage label restricting it to the email channel. The team uses a merge policy of 'Dataset precedence: CRM > SDK > Partner' for all attributes. Last month, 22,000 users who had opted out in the app were emailed because the CRM record still showed email_consent = true. Legal is now involved. The team wants to switch the merge policy to 'most recent' to fix it.
1. Explain why the current merge policy caused the opt-out failure, and evaluate whether switching to 'most recent' is a correct fix.
Read the worked answer
Why it failed: dataset precedence CRM > SDK means the CRM email_consent value always wins for any attribute present in both. The app opt-out (marketing_opt_in = false) was written to the SDK-sourced attribute, but the profile's resolved email_consent was pulled from CRM, which was stale. Precedence is deterministic by source, not by recency or truth - so the authoritative opt-out signal was structurally overridden.
Is 'most recent' the fix? Partially, but not sufficient and potentially dangerous:
- Most-recent depends on ingest timing, not on legal authority. A late-arriving partner or CRM batch could overwrite a fresh opt-out with an older consent - same failure, different path.
- Consent is not a normal attribute to resolve by recency. It should be monotonic for opt-outs: an opt-out should never be overwritten by an opt-in from a less authoritative or older source without explicit user action.
Better approach: treat consent as a governed, separately-managed field - e.g., a dedicated consent dataset with highest precedence that only accepts opt-out from any source and opt-in only from a verified user action; or enforce consent at the destination/segment level via governance policy so activation is blocked when consent is false/unknown, regardless of merge outcome. Most-recent alone leaves you exposed.
2. Describe the governance controls you would put in place so this cannot recur, referencing data usage labels, policies, and enforcement points.
Read the worked answer
Layer defenses at ingest, profile, and activation:
- Label the data correctly:
email_consent(and any consent/health attribute) carries a sensitive data usage label. Contract/identity labels on the datasets too, so partner data is identifiable. - Policy with enforcement: create a data usage policy that denies marketing activation when consent is false or unknown, and restricts sensitive attributes to the email channel only. Policies must be enforced, not just documented - verify the policy is active on the destination.
- Separate consent from merge: put consent in a dedicated, highest-precedence dataset; document that opt-out is sticky. Do not let general merge policy govern consent.
- Destination-level guard: require the email destination to evaluate consent at activation time, so even a bad profile value can't leak.
- Audit trail: enable and review policy-violation/audit logs; alert on activation volume spikes or consent-false inclusions.
- Data hygiene: schedule recurring audits comparing app opt-outs vs. CRM consent; reconcile with a source-of-truth consent service.
Judgement: the exam rewards recognizing that governance is enforced at multiple points, and that a merge-policy tweak is a data-resolution change, not a compliance control.