01
Intended desktop boundary
Desktop prospect, evidence, draft, contact, campaign, and outreach data is designed to remain local.
02
Account service data
The web service may process account identity, plan and billing status, licence keys, Stripe references and processed-event identifiers, and device-activation records.
03
Optional telemetry
Anonymous telemetry and error-report ingestion are not implemented. The current desktop telemetry toggle is a local preference and transmits nothing.
04
Professional review items
Final controller, processor, retention, rights, and international-transfer language must be supplied after legal review.
05
Early-access waitlist
The waitlist collects a name, email address, optional company, intended use, optional plan interest, signup source, consent version, and signup time. It is used only for LUNAZET launch updates and early-access invitations.
Netlify deployments store waitlist entries in site-wide Netlify Blobs with normalized-email deduplication. Deployments using the existing account backend store the same fields in PostgreSQL. Every launch email must include an unsubscribe control, and no invitation campaign should begin until the suppression and deletion process is operational.
06
Launch eligibility data
A production launch may require account-country and organization-type evidence to enforce the stated US/UK boundary. The current private mock preview does not perform that verification. Counsel must approve the evidence, retention, correction, and appeal process before collection begins.
UK outreach is limited to a role-based corporate email address visibly published on the recipient's public business website. Named or personal UK addresses remain blocked until qualified counsel approves, and LUNAZET implements, a UK GDPR lawful-basis and transparency workflow. A public role address does not by itself make outreach lawful.