Data Handling

Storage, retention, and processing boundaries

This page is the public technical summary for buyers and reviewers who want to understand what data classes exist, where they live, and what extra review is required before broader launch.

Related docs

These pages are the current customer-facing trust and disclosure set for launch prep.

Data classes

What kinds of data exist in the current model

L1 - Local only

Foreground app names, hostnames, timestamps, block events, posture aggregates

L2 - Account

Email, password hash, license records, subscription status

L3 - Aggregate sharing

Optional weekly team-level signal summaries if the user opts in

L4 - Billing

Card and billing data handled by Stripe, with only reference IDs stored by Rooted Reality

Retention model

Local posture data stays under user control on the device. Server-side account and billing-reference records follow separate retention needs for account recovery and tax or subscription records.

Network boundary

The server-side boundary is limited to account creation, billing state, and license validation. The planned license API should never receive raw hostnames, content, or posture-event payloads.

Regulatory readiness

GDPR-related launch checks

This is an operating checklist, not a claim that every requirement already applies.

Transparency notice

Privacy draft covers data categories, purpose, retention, and sharing

Design and default

Local-first architecture keeps posture data on-device by default

Processing record

ROPA draft lives in the technical data-handling spec

Processor review

Stripe and any email provider require contract review before launch

DPIA trigger review

Required before Teams, youth programs, or employer-managed rollouts