core/customer-data-in-logs

No customer data (MSISDN, email, account IDs, names, addresses) in logs, analytics events, error messages, or metric labels.

Read it in the terminal

The same facts, from the checkout you are already in — no browser, and no network.

$ npx redlinegate explain core/customer-data-in-logs

Where this came from

You are most likely here from a review comment. A finding names its rule and, when your repository has told Redline where the standard is published, its address:

Redline/BLOCKER [core/customer-data-in-logs]: …
  → …/r/core/customer-data-in-logs

That second line is written by redline init --docs-url and is empty until an organisation sets one — there is no default, because a link to somebody else's copy of the standard is worse than no link. See Onboard a repository.

In context

This is a core rule: it applies in every profile, and every stack extends it rather than overriding it. The core standard lists it beside everything else a reviewer is asked to consider.

Other BLOCKER rules in this stack

• core/hardcoded-secretsNo hardcoded secrets, API keys, tokens, or credentials — including in test files, fixtures, config samples, and comments.
• core/unvalidated-boundary-inputAll external input validated at system boundaries (forms, API responses, deep links, query params, webhook payloads, message-queue payloads).
• core/html-injection-sinkNo unsanitised HTML injection sinks (`dangerouslySetInnerHTML`, `innerHTML`, template autoescape disabled).
• core/missing-auth-checkAuth checks on every server action / API route / service endpoint — not only in the UI layer or at the gateway.
• core/sensitive-data-in-client-storageNo sensitive data in browser or device storage (`localStorage`, `AsyncStorage`, `UserDefaults`, `SharedPreferences`) without platform-keystore encryption.
• core/query-string-concatenationNo query built by string concatenation with external input — parameterised only.