What we collect and how we use it.

Pilot requests and accounts

The pilot form collects only your work email and organization. We use them to review your request and follow up about fit and access. The database also records submission time, review status, and review information. A request is separate from an account or an access grant.

Invited sign-in uses Supabase Auth. Account and access records include the invited email and identifiers needed for authentication. Authentication uses browser cookies; no applicant case record is created by signing in.

Hosting, processing, and access

Vercel hosts the website and server endpoints. Supabase provides authentication and PostgreSQL storage for requests, grants, and throttling records. When analytics is configured, PostHog processes usage events. Visiting LinkedIn takes you to a separate service.

The public site is served over HTTPS. The public database roles cannot read pilot requests or access grants. Admin review and invitation endpoints check the configured admin identity and verified authenticator MFA on the server. Authorized infrastructure operators can access the services they administer.

These controls apply to the current enquiry and access flow. Applicant storage, team isolation, document access, and AI processing are not implemented. We have not published a verified region, encryption-at-rest, certification, or applicant-data compliance guarantee.

Analytics and request protection

When enabled, PostHog receives selected public pageviews and actions such as clicking a pilot link. Tracking can include browser identifiers and browser/device metadata. Verified invited users are identified by their account ID, without an email property.

Our analytics events do not include form values, organization names, applicant details, or documents. URL query strings and fragments are removed from URL properties. Automatic click capture, session recordings, surveys, and error capture are disabled in the current implementation.

To throttle public requests, the application stores a keyed hash derived from the client IP rather than the raw IP. Expired counters are eligible for cleanup after a day; cleanup runs during requests. Hosting and authentication providers may separately process operational logs.

Retention, deletion, and questions

Pilot and account records currently have no automatic deletion schedule. They remain until manually removed. No self-service deletion or export tool is available yet.

For a correction, deletion request, or a suspected data-handling issue, contact Ankan Ganguly on LinkedIn. Start with a general request; do not send documents or credentials. We will agree an appropriate way to verify ownership. Removing an active record does not mean provider logs or backups are immediately erased.

Before any real applicant data is used

A real-data pilot must have written scope and data-handling arrangements before records are transferred. Those arrangements need to cover:

• Storage and processing locations, providers, and who can access each team’s records.
• Verified security controls, team isolation, and the incident contact and response process.
• Whether AI processes any information, which provider does so, and its retention and training terms.
• Retention periods, deletion and backup handling, and export and exit responsibilities.

These are prerequisites to agree and implement, not controls we claim are already available. The first workflow discussion can use fictional data.