FOUNDING ACCESS · APPLICATION STAGE
Founding Access Privacy Policy
Draft for review · Version theora-privacy-2026-10-20-v6 · 20 October 2026
This notice describes the Founding Access application operated by the Theora team. Contact info@theora.io for privacy, access, correction, deletion or marketing-choice requests. It covers application and campaign administration, not future use of glasses or health data.
What we collect and why
We collect a name to review an application, email for mailbox verification and account/operational messages, and phone for an operational verification text, later eligibility or allocation contact and duplicate prevention. A typed number alone is not verified. Email verification completes registration; a phone number with country code is required, and phone ownership is verified later before shipping allocated glasses. No SMS verification is required at registration. Keyed digests of normalized phones and recognized email-provider aliases flag possible repeat applications for staff review, without combining accounts. A verified email identity cannot be claimed by a second registration. A typed phone number is unverified and cannot establish a unique person. Repeat phone numbers are reviewed; a verified phone cannot authorize shipment for a second registration, and staff review cannot override verified-phone uniqueness. A phone number does not authorize marketing calls or texts. We store an application ID, timestamps, accepted document versions/hashes, application states, original source references, approval order, and separate cohort and waitlist referrals. Optional marketing email is unchecked and not required. No initial address, payment card or health information is requested. Existing registrations and paid reservations are reconciled without rewriting their original records or rights.
Campaign measurement and choices
The first-party application stores allowlisted source, medium, campaign and referring-page categories for attribution. First touch is retained for the seven-day visitor cookie, and an application keeps its original acquisition source. Cohort and waitlist attribution remain separate. Anonymous visit, Apply-click and form-start/error events run only after you allow analytics. With the separate PostHog analytics choice enabled, our server also forwards allowlisted funnel and committed operational events to PostHog in its US cloud, using a random visitor identifier rather than contact details. Your choice is versioned and stored per browser and in our protected database. Earlier first-party-only permission does not silently enable PostHog. Change this choice with Analytics preferences; declining remains compatible with applying. Attribution supports numbered launch campaigns 01–99 for X, LinkedIn, Reddit, email and community links. Unknown campaign text is discarded. Known external referrers may identify a channel when no explicit source tag is present; missing referrers cannot identify a source or individual post. Declining does not prevent applying. Operational saved-application, verification, approval and referral events are deduplicated server-side. Saved applications count only after the database transaction commits. A registration is not a paying customer or retained user.
What analytics exclude
Names, emails, phone numbers, addresses, health data, form contents, verification tokens and full referring URLs are excluded from analytics. There is no session replay, keystroke capture, advertising pixel or third-party browser analytics SDK in this flow. PostHog receives only allowlisted events from our server after the separate analytics choice: event time, canonical page category without query strings/fragments, source, medium, controlled campaign name, referring-page category, referral type and fixed error codes. We do not forward browser IP addresses or user-agent strings, create contact-based PostHog profiles, or send invitation codes and application IDs to PostHog. Only fixed event, page and error codes enter event records. Campaign values are allowlisted and verification tokens use URL fragments removed by the page before tracking. We do not generate contact-bearing application URLs or log application request bodies.
Providers, storage and security
The website/API are hosted on Render; application records and separate operational analytics tables use the existing Supabase PostgreSQL project; verification and operational emails use Resend. There is no SMS step during registration. A server-only SMS adapter is prepared for later phone verification before shipping. The provider for that later stage and its sending budget remain to be confirmed before the shipping-verification workflow is enabled. The selected SMS provider will process the phone number for verification; its identity and terms must be confirmed before SMS is enabled. These providers process data for application operation. PostHog processes consented pseudonymous event data for campaign and funnel analytics; its project settings govern retention of accepted analytics events. Turning analytics off cancels queued, unsent events but does not erase already accepted events. Contact info@theora.io for analytics access/deletion requests as well as application requests. Contact records use server-side authenticated encryption, normalized-email keyed digests prevent duplicate records for the same email; separate phone and email-alias keyed digests support abuse review, and verification/session tokens and email codes are keyed or hashed in storage. SMS codes are checked with the approved provider rather than stored or logged by this application. Protected later eligibility/address records use the same authenticated encryption; they are collected only after an approved allocation policy and a separate request. Private tables have row-level security with no browser/anonymous policies. The server’s private service credential is never placed in browser code. Restricted staff roles and audit records protect approvals and exports; no staff role is granted merely by applying. No data sale or model-training permission is created here. Shipping partners have not been selected through this application and receive no address now.
Cookies and email links
Secure, HttpOnly, SameSite first-party cookies protect a seven-day visitor context and verified member session. Cohort and waitlist referral context is held separately. Verification and email sign-in links expire after 24 hours and are single use. Email and SMS codes expire after 10 minutes, permit at most five checks per challenge and have a 60-second resend cooldown. Clearing cookies or changing devices does not delete an application or its sharing code. Use email sign-in to return to the same record; this does not create a new application or change your consent, approval or paid-reservation rights. An analytics choice is stored locally in your browser and can be changed with Analytics preferences; marketing preferences remain separate. Only the intended recipient should use a verification link. Duplicate submissions receive a generic confirmation and do not disclose another person’s account.
Retention, access and deletion
No fixed production retention schedule has been finalized. Applications remain in protected program storage while operated; withdrawal and deletion requests are queued for authorized review. An owner can anonymize current-program contact and address data after reviewing a deletion request. Original paid-reservation records, consent/audit history and minimal keyed identity references remain separately protected where needed to preserve rights and prevent multiple claims. Provider/backups and original paid records require separate handling; anonymizing program contacts does not falsely report those copies erased. No automated deletion schedule is enabled. Requests and original paid-reservation records may need separate handling to preserve existing rights and legitimate recordkeeping. Contact info@theora.io for access, correction, deletion, withdrawal or marketing changes. Backup retention and deletion must be considered during request handling. Do not submit health records or information about someone else. Eligibility rules and any additional shipping-data notice will be provided before hardware selection; participation in any future research or health-data program requires its own explicit process.
Admission records
We store registration serials, cohort positions, single-use invitation ownership, claim and redemption timestamps, and invitation attribution to enforce the 200 founder, 300 invited, 1,000 public-entry and 3,000 total-registration limits. These records are separate from contact data sent to analytics. Member pages show only their own invitation progress, not another applicant’s name, email or phone. Recognized earlier reservation rights remain separate. Numbers do not prove a unique human identity or a hardware allocation; suspected duplicates require review.