Data Handling
Plain-language technical boundaries for reviewers.
The point of this page is to make storage classes, network boundaries, and retention posture readable to technical reviewers without sending them into internal product UI.
Data Classes
The main storage classes in the launch architecture.
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
Local posture stays local; account records have separate retention needs.
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.
Readiness Map
The current compliance-readiness checkpoints.
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