# Privacy and Safety

## Why this matters

The concept depends on location and inferred social context. That makes privacy protection central to product viability, user trust, and legal compliance.

## Core guardrails

- Do not expose user identity, names, handles, or profile-level venue presence.
- Do not show exact headcounts.
- Do not expose data for very small samples.
- Do not let users filter in ways that can isolate a single person or tiny subgroup.
- Do not present historical patterns as current fact.

## Launch privacy rules

### Minimum thresholds

- Age output requires at least 10 active users and a dominant band of at least 55%.
- Relationship-based social vibe requires at least 10 active users and a dominant segment of at least 55%.
- Crowd prompts are used for 6 to 9 active users and require at least 2 matching votes inside a short window.

### Suppression behavior

If thresholds are not met, the system should:

- Hide the segment entirely, or
- Show a non-sensitive fallback such as `Mixed social vibe` or `Limited live data`

### Consent

The app should request:

- Account and email consent
- Foreground location consent
- Separate background location consent
- Clear explanation of how anonymous aggregation works

## Safety review topics before production

- Data retention duration for location events
- Hashing and rotation strategy for user identifiers
- Anti-stalking and anti-targeting abuse cases
- Minor-age exclusion and age-gating logic
- Regulatory review for location tracking disclosures
- Venue claim and moderation workflows

## Recommendation

Before building the production version, run a joint review with legal, privacy, and security stakeholders. The rules in the prototype are a solid foundation, but the live product should formalize them in policy, telemetry design, and abuse prevention systems.