consent-and-regulated-data-referencelisted

# Consent and regulated-data reference Systems that handle regulated personal data (health records, financial data, or personal data generally under a privacy regime) share a small set of hard rules regardless of jurisdiction or industry specifics. Get these wrong and the failure is not a bug ticket, it's a legal or compliance incident. The unifying principle: **fail closed everywhere, and never let a "test" or "verification" action create a legally material record.** ## Fail closed, structurally - No consent record → no processing, no send, no session. Don't let a missing consent check degrade to "allow, and log a warning." - A missing secret required for a compliance-sensitive path (a hashing salt, a signing key) should make that path fail hard (an error), never silently fall back to an unsalted or unguarded equivalent. This is one of the few places where "fail loud and ugly" is strictly better than "fail soft and available." - If your consent/communication model has more than one generation (an old model being phased out, a new authoritative one), the gate logic should read from the current authoritative model only. A legacy model kept around for backward-compatible reads should never be treated as satisfying a current-model check. ## Never mix communication scopes If your system distinguishes necessary/operational communication (e.g., service-related messages a user needs to receive) from optional/commercial communication (marketing, upsell, review requests), keep th