data-classification-guidelisted

## Purpose Give reviewers a shared, concrete way to decide how carefully a piece of data needs to be handled, instead of relying on a case-by-case judgment call every time. Most security and privacy findings ("this shouldn't be in the log," "this shouldn't be in the prompt") come down to misjudging which tier the data actually belongs to. ## When to use it Whenever a review needs to answer "is it OK for this data to end up here" — in an AI prompt or context window, in an application or access log, in a committed file (including test fixtures and example config), or in an error message returned to a client. Use it alongside `security-audit-checklist`'s injection/output-handling items and the `Data Classification Awareness` rule. ## The three tiers **Public** — safe for anyone to see with no restriction: published documentation, open-source code, marketing content, anything already deliberately made public. **Internal** — not secret, but not meant for outside distribution: internal architecture notes, non-sensitive business metrics, internal tooling config that doesn't grant access to anything, employee directory info the org treats as internal-only. **Sensitive** — data whose exposure causes real harm: personally identifiable information (names tied to contact info, government IDs, dates of birth), authentication material (passwords, API keys, tokens, private keys, session identifiers), financial data (card numbers, account numbers, transaction details), health data, an