Privacy Notice

Project Seneca — Privacy Notice

Version: Draft 1 · Prepared: 27 August 2026 · Status: unapproved, unpublished

Layer 1 — The short version

This is a summary. It is not the full notice. The full notice begins at Layer 2, and where the two differ the full notice governs.

Who holds your data. Project Seneca (pre-incorporation, operated by its founder), at registered address to follow on incorporation, is the controller of your personal data. Privacy questions go to [email protected].

What we hold. Your email address; the profile you write about yourself (name, bio, city, role, institution, age, availability, what you can share, what you want to learn); the skills and evidence you add; who you express interest in and any note you attach; your direct messages; your session and credit history; reflections you write after an exchange; vouches you write about other members; and any avatar or media you upload. If you applied or joined the waiting list before becoming a member, we also hold that application, including any voice transcript.

What we do with it. Run your account, show you to other members, help you find people to exchange skills with, arrange and record exchanges, and administer the credit system. When you ask for an AI suggestion, six fields from each profile are sent to an external AI provider — see the separate AI Notice.

Where it goes. Our suppliers include Supabase (database, sign-in, file storage), Vercel (hosting and request logs), Anthropic and OpenAI (AI features), and Resend (email). These are United States companies, so your data leaves the UK. Two further services — OpenFreeMap and Open-Meteo — receive your IP address directly from your browser on certain pages.

How long we keep it. No retention period has been set for any category of data. In practice this means data is kept indefinitely. Setting retention periods is an outstanding decision: not yet fixed — being decided during the beta; this page will be updated.

Things you should know before you decide to join. These are true of the product as it stands today:

• Your email address is private from other members, and was not before 27 August 2026. Some fields the interface does not display, including your age and your institution, can still be read through the API by any signed-in member. Administrators can read your email address, for administrative purposes.
• Uploaded media is private to the community, not to you. Since 27 August 2026 the media buckets are closed to anyone who is not signed in, and the file listings can no longer be read. Any signed-in member can still view any member's photos and recordings. Anything that was public before that date may already have been copied.
• Reflections you write after an exchange can no longer be read by the person they are about, since 27 August 2026. Administrators can read them.
• You can delete your account yourself, from your profile, and it happens straight away. Your personal data is removed from the database. The credit ledger keeps its entries because it is append-only by design, and after erasure they no longer identify you. Your uploaded photos and files are deleted first, before the records that name them, and your published skill entries go with them. If you cannot reach your profile, write to us instead.
• Your data is not anonymous, and messages are not end-to-end encrypted. Our suppliers can technically access what they store and process for us.

Your rights. You can ask for a copy of your data, correct it, object to some uses, restrict processing, and ask for erasure. Erasure is something you do yourself, from your profile (see §9). You can complain to the Information Commissioner's Office at any time.

Layer 2 — The full notice

1. Who we are and how to contact us

Project Seneca is an invite-only community in which members exchange skills with one another. This notice covers the website at projectseneca.com, the member application served at /mobile and /m, and the Expo mobile application.

Minimum age. 18. We record an age field on member profiles, but no age gate is enforced anywhere in the product today. Setting and enforcing a minimum age is an outstanding decision.

2. What personal data we hold

The table below is taken from a live inventory of the database columns. "Reaches supplier" names the external companies that receive each category in the ordinary course of operating the service.

We also process technical data — IP address, user agent, requested path, referrer — as an unavoidable consequence of serving web requests. This sits in our hosting supplier's platform logs, which we do not control.

3. Special category data

users.admin_gender records a gender marker set by an administrator for the purpose of monitoring the community's composition. Whether this constitutes special category data under Article 9 UK GDPR has not been decided. If it denotes sex or gender identity, an Article 9 condition — and, for most conditions, an appropriate policy document under Schedule 1 DPA 2018 — is required before it may lawfully be processed. FOUNDER/LEGAL DECISION REQUIRED.

Two internal reporting views (metrics_gender_coverage, metrics_interested_drift) use this field. The audit confirmed those views are reachable only by our own service credentials and not by members or the public.

Until that decision is made, this notice cannot state a lawful basis for processing admin_gender, and no such basis should be assumed.

Voice recordings are also relevant here. The waiting-list voice feature transmits a person's live voice to an external provider. Voice is not automatically special category data, but it is closely adjacent, and a decision is needed on whether it should be treated as such. FOUNDER/LEGAL DECISION REQUIRED.

4. Why we process your data, and on what lawful basis

Every lawful basis in this table is proposed, not settled. Each REQUIRES FOUNDER/LEGAL CONFIRMATION before this notice is published. Where legitimate interests is proposed, a legitimate interests assessment must be completed and recorded; none exists today.

A data protection impact assessment has not been carried out. Given the vouches, the reflections, the voice processing and the invite-only community model, one is likely to be required. FOUNDER/LEGAL DECISION REQUIRED.

5. Who can see what

This section describes the product as it is configured today, not as it is intended to be. The audit tested each claim against the live database and storage configuration. Where a control works, it is marked as holding; where it does not, the current true state is given.

5.1 What holds today

5.2 What does not hold today

These are real, current exposures. They are listed here because a privacy notice that omitted them would be inaccurate.

The intended access model, confirmed by the controller on 27 August 2026. The exposures in this table

are defects against that model, not the model itself. As intended: an administrator may access member and

applicant email addresses for legitimate administrative purposes, and does so server-side or through the

database dashboard — never through a key exposed to your browser; you may access your own email address;

other members may not access it; and anonymous visitors may access no member's or applicant's email

address at all. The remediation for the two email findings is scoped to close the member-to-member and

anonymous paths while preserving administrative access. Until it is applied, the row below describes what

is true today.

| Every signed-in member can read every member's full account row, including email, age, admin_gender and institution | All members | The interface does not display these fields, but the API returns them to any member who asks. Anonymous visitors cannot read the member directory — this is a member-to-member exposure. |

| Uploaded media is not private | All members who have uploaded anything | All three media buckets are configured as public. A file can be fetched by anyone holding its URL, without signing in, and the file listings of all three buckets can be read by anyone at all. File paths contain member identifiers, so a listing links files to members. This applies retroactively to everything already uploaded. |

| Reflections can be read by the person they are about | Anyone writing a reflection | The access policy grants a read to any participant in the match, which includes the person being described. In-product copy saying "your answers stay private" is not accurate at the database layer. No reflections exist yet. |

| Connected-account data, including the raw payload returned by the provider, is readable by every signed-in member | Anyone linking an account | No accounts are linked today, so nothing is exposed yet. This must be fixed before account linking is offered. |

| Availability, skills and vouches are readable by every signed-in member | All members | This may be intended for a member directory. It is disclosed here rather than assumed. |

| A signed-in member can start a message thread with any other member without a mutual match, and can create connection state marked "accepted" directly | All members | The requirement for a mutual match is enforced by the interface, not by the database. This undermines the promise that someone learns of your interest only when it is mutual. |

| Admitted applicants' email addresses are readable by anonymous visitors | Six people admitted to date | A database view exposes them without any sign-in. Whether these individuals require notification of a personal data breach is an outstanding legal decision. |

| Invitation codes are readable by anonymous visitors, and the redemption function can be called by anyone without signing in | Prospective members | The invitation system provides no access control in its current configuration. |

| Security headers are absent | All visitors | There is no content security policy, no frame protection, no referrer policy and no permissions policy. Transport security (HSTS) is present. |

| Sessions have no time limit | All members | There is no absolute session lifetime and no idle timeout, so a signed-in session persists until you sign out. |

5.3 Administrators

Administrator accounts can read applications, member approvals and certain member data. applications.review_note is free text written about an applicant by an administrator; the applicant has no way to see or contest it today. Whether to surface review notes to applicants on request, and how, is an outstanding decision.

6. Suppliers who process data for us

Supabase's own sub-suppliers, including its cloud host and the shared mail relay used for sign-in email, sit behind our relationship with Supabase and are not separately listed. Obtaining and recording that list is an outstanding task.

We have not verified that a data processing agreement is in place with each supplier above. Doing so is an outstanding task. FOUNDER/LEGAL DECISION REQUIRED.

Safety identifier. Requests to OpenAI on the waiting-list path carry an identifier derived from the visitor's IP address. Because the value used to scramble it is a publicly visible constant, that identifier can be reversed back to the IP address. It is therefore pseudonymous at best and must not be described as anonymous.

7. International transfers

All five core suppliers — Anthropic, OpenAI, Vercel, Supabase and Resend — are United States companies. Your personal data is therefore transferred outside the United Kingdom.

The transfer mechanism relied upon has not been established: UK-approved safeguards, being documented during the beta. The options to be decided between include the UK International Data Transfer Agreement, the UK Addendum to the EU Standard Contractual Clauses, or reliance on the UK's adequacy findings for the relevant framework. A transfer risk assessment must accompany whichever is chosen. Until this is decided, this notice cannot state that transfers are subject to appropriate safeguards.

Where OpenFreeMap and Open-Meteo receive an IP address directly from your browser, the destination and legal footing of that transfer are not established either.

8. How long we keep your data

No retention period is defined anywhere in this product — not in the database, not in the application code, not in configuration, and not in any published policy. There is no scheduled deletion, no expiry job and no archiving process. The practical effect is that every category of data is currently retained indefinitely.

This applies to member profiles, direct messages, expressions of interest, session history, the credit ledger, reflections, uploaded media, waiting-list entries including voice transcripts of people who never became members, and application records including those of people who were declined.

Setting a retention period for each category is an outstanding decision: not yet fixed — being decided during the beta; this page will be updated.

Two categories need specific attention when that decision is made:

• The credit ledger is append-only and hash-chained by design. Deleting entries would break the chain. That decision has been made: on erasure the member is anonymised in place and the ledger entries stay, identifying nobody.
• People who never joined — waiting-list entries, applications and recommendations — have the weakest justification for indefinite retention, and none of these people has an account through which to exercise their rights.

9. Your rights

Under the UK GDPR you have the right to be informed; to access your data; to have inaccurate data corrected; to erasure in certain circumstances; to restrict processing; to data portability; to object to processing based on legitimate interests; and rights in relation to automated decision-making.

To exercise any of these, write to [email protected]. We will respond within one month, extendable by two further months for complex requests.

Current limitations you should know about before relying on these rights:

If you are on the waiting list, applied, were declined, or were recommended by a member, you have the same rights. You have no account through which to exercise them, so please write to [email protected].

10. Security

What the audit confirmed is in place: encryption in transit with HSTS enabled; row-level access control on every database table; no analytics or error-reporting software in either client; no logging of secrets, session tokens, profiles, message bodies or AI prompts and responses; verified email sign-in with no password path in use; optional two-factor authentication available; rotating refresh tokens with a narrow replay window; and self-hosted fonts.

Updated 27 August 2026: the media buckets are now private (member photos are served through short-lived signed links); member-to-member reads of another member's email address are refused by the database; durable rate limits protect sign-in and the routes that call paid AI services; the sign-in token is removed from the browser address bar immediately after use; and baseline security headers are in place. Still missing, and disclosed rather than glossed: a full Content-Security-Policy and a session time limit.

We do not offer end-to-end encryption. Our suppliers can technically access the data they store and process for us. Nothing in this product makes you anonymous to us or to those suppliers.

11. Cookies, browser and device storage

Covered in the separate Cookie and Storage Notice. In summary: the storage we use is the sign-in session, a saved profile draft, and a small number of interface flags. There is no analytics or advertising storage of any kind.

12. Complaints

If you are unhappy with how we handle your data, please tell us first at [email protected] so we can try to put it right.

You can complain to the Information Commissioner's Office at any time, and you do not have to raise it with us first.

Information Commissioner's Office

Wycliffe House, Water Lane, Wilmslow, Cheshire SK9 5AF

Helpline 0303 123 1113 · ico.org.uk/make-a-complaint

13. Changes to this notice

We will publish a new version here when our practices change and will tell members when the change is material. This draft carries no publication date because it has not been published.

Outstanding decisions register

These must be resolved before this notice is published.

1. Controller identity, registered address, privacy contact, whether a DPO is required, and ICO registration.

2. Territories served, and the minimum age policy, together with how it will be enforced.

3. The lawful basis for every purpose in §4, and a recorded legitimate interests assessment for each purpose relying on legitimate interests.

4. Whether admin_gender is Article 9 data, and if so under which condition it is processed and whether an appropriate policy document is needed.

5. Whether voice recordings should be treated as special category data.

6. Whether a data protection impact assessment is required, and its completion.

7. A retention period for each category in §2, including how the append-only ledger is handled.

8. The international transfer mechanism, and a transfer risk assessment.

9. Data processing agreements with all seven suppliers, and Supabase's sub-supplier list.

10. Whether the six admitted applicants whose email addresses were exposed require breach notification.

11. Whether to build an erasure path as anonymisation in place or hard deletion, and by when.

12. Whether the member-to-member reads in §5.2 are intended and should be disclosed, or unintended and should be narrowed.

13. Whether to publish this notice before or after the release-blocking defects are fixed.