1. Status of this draft#
This page is intentionally incomplete. The Eudorian operator identity, contact channel, production hosting, subprocessors, data-retention schedule, legal bases, supported privacy rights, and international-transfer framework have not been specified in the current implementation.
[PRIVACY AND LEGAL REVIEW REQUIRED BEFORE FINAL PUBLICATION] Complete a production data map and replace each unresolved item before treating this page as the final privacy policy.
2. Data handled by the current implementation#
The current web foundation supports optional Supabase email/password authentication. When configured and when you create an account, the application sends the name, email address, and password you enter to the configured Supabase authentication service. The password is submitted for authentication; the Eudorian application code in this repository does not define its own password database.
When you sign in, Supabase returns authentication and session information that is handled through cookies. Server code validates Supabase claims to protect the dashboard and reads the account email to display it in the interface.
The current interface also receives ordinary web requests. This repository does not document what production hosting logs, network metadata, or retention settings will apply because a production hosting configuration has not been provided here.
3. How current data is used#
In the present code, account and session data are used to create an account, confirm an email callback, sign in, refresh or validate a session, protect the dashboard, display the signed-in email, and sign out.
No analytics, advertising, profiling, payment, production AI inference, file-upload processing, compute scheduling, or credit-ledger implementation is present in this repository. This statement describes the inspected codebase, not any separate production system that may later be connected.
4. Current service providers and disclosures#
The repository integrates Supabase for authentication when public Supabase configuration values are supplied. Supabase’s handling is also governed by the agreement and configuration selected by the Eudorian operator.
[PRODUCTION DATA MAP NEEDED] Hosting, domain, email delivery, monitoring, support, abuse-prevention, connector, model, cloud-compute, and payment providers are not identified in this repository and must be listed or described if adopted.
5. Features and data practices not yet implemented#
The current repository explicitly treats the Eudorian Worker, GPU pairing, distributed inference, scheduler, production model execution, credit ledger, API key issuance, payments, purchased credits, and production API endpoints as planned rather than implemented.
Accordingly, this draft does not claim that Eudorian currently collects Worker telemetry, hardware details, workload content, model prompts or Outputs, API usage, contribution measurements, credit transactions, billing information, connector data, or distributed-processing logs. A final policy must describe each category before the corresponding feature processes real user data.
6. Retention, deletion, and account closure#
[POLICY AND CONFIGURATION NEEDED] The repository does not establish production retention periods, backup schedules, deletion timing, account-export procedures, or legal-hold rules. These must be based on actual Supabase and hosting configuration and on any future Worker, ledger, AI, support, and billing systems.
7. Security boundaries#
The current application validates signed-in Supabase claims on the server before rendering the dashboard and uses cookie-based session handling. Public environment variables are limited to the Supabase project URL and publishable key; service-role credentials are not part of the documented browser configuration.
No system is completely secure. The current code does not establish production encryption, incident-response, Worker sandboxing, distributed workload isolation, content residency, vulnerability reporting, or security certification claims. Those controls must be documented from the actual implementation before Eudorian makes such representations.
8. Your choices and privacy rights#
You can choose not to create an account. Authenticated features require the account and session data described above. Any legal rights to access, correct, delete, restrict, object, or receive a copy of personal data depend on the applicable law and the final identity and location of the Eudorian operator.
[LEGAL DECISION AND REQUEST CHANNEL NEEDED] Add verified request methods, identity-verification steps, response timing, appeal rights, and region-specific disclosures only after the relevant jurisdictions and operational process are known.
9. Updates required before future features launch#
Before enabling community Workers or production AI processing, this policy should explain contribution telemetry, device identifiers, hardware and network data, workload routing, what Worker operators can access, temporary storage, model and cloud providers, content retention, training choices, abuse monitoring, geographic processing, and incident handling.
Before enabling APIs, connectors, payments, or purchased credits, it should also explain API logs, connector permissions and revocation, third-party data flows, billing records, tax records, fraud checks, retention, and user controls. The final policy should use the same “Last updated” configuration value and provide notice of material changes.
10. Contact information#
For now, review the Terms of Service for related platform rules.
[PRIVACY CONTACT REQUIRED BEFORE FINAL PUBLICATION] Add a monitored privacy email or support URL and the verified legal identity of the Eudorian operator. Do not add a company address or data-protection contact until one has been confirmed.