ux-phi

Privacy notice

Last updated 23 August 2026

Draft. This notice is not final. It is published for review and still contains items marked for completion. Do not rely on it as a settled statement of practice.

Who is responsible

ux-phi is run by Nathaniel Hansen. For the ordinary use of this site — an individual signing up and playing a simulation — the data controller is ux-phi. [TODO: legal entity, contact address, ICO registration number.]

When your instructor enrols you in a class section, the relationship changes: your institution decides what is collected and why, and ux-phi processes it on their instruction. Questions about a class section go to your instructor or your institution’s data protection officer first.

What is collected

For anyone with an account:

  • Your email address and account identifier, held by our authentication provider so you can sign in across devices.
  • A display name, only if you choose one. It is never derived from your email, and it is what appears on public boards if you opt in.
  • Your conversations with the simulations, and the progress derived from them.
  • Membership tier and, if you support ux-phi on Patreon, the identifier linking your pledge to your account. Payment card details are never seen or stored by ux-phi.
  • Usage telemetry: token counts, model, cost estimate, and a hashed IP address. No conversation content is logged in telemetry.

Additionally, if you hold a seat in a class section:

  • The student or roster number you entered at enrolment, which is how your instructor matches your seat to their class list.
  • Activity counters per simulation: turns, approximate engaged time, first and last activity.
  • Evaluations generated at the close of a simulation — a spoken verdict you see in the fiction, and a rubric with dimension scores and supporting quotations that your instructor sees.
  • Your answers to collections, check-ins, thought-experiment stages, and anything you write in a paired discussion.
  • The date you affirmed the course consent form and a version stamp identifying the exact text you agreed to.
  • In a graded section only, the full transcript of your conversations in the class simulations. This is disclosed on the enrolment page before you take a seat, and it cannot be switched on for a section after students have joined.

Who processes it

ux-phi uses the following providers. Each processes only what the service requires.

  • Vercel — hosting, serverless functions, and page analytics.
  • Neon — the PostgreSQL database where everything above is stored.
  • Clerk — authentication; holds your email and sign-in credentials.
  • Anthropic — the AI provider whose Claude models generate the simulations. Your messages are sent to Anthropic to produce a reply, and to generate evaluations, discussion briefs, and summaries. [TODO: state the retention posture on the Anthropic account.]
  • Upstash — a Redis cache holding usage telemetry.
  • Patreon — membership status, for supporters only.
  • nat-hansen.com — hosts the class experiments. It receives a one-way tag identifying your seat, and your experiment responses. It never receives your name, email, or account identifier.
  • Google Fonts — typefaces, served to your browser.

Your conversations are not sold, and are not used for advertising or marketing. They are not used to train AI models.

Class experiments are pseudonymous, not anonymous

Opening a class experiment attaches a one-way tag derived from your seat so your own responses can be shown back to you afterwards. Your name and account are never sent to the experiment site, and your instructor sees class results rather than who answered what. But the tag is derived from your seat, which means ux-phi can re-associate an experiment response with your account. We describe this as pseudonymous rather than anonymous because that is what it is.

How long it is kept

[TODO: decide and state actual periods. Proposed defaults below — change them to whatever you will genuinely honour, because a retention promise you do not keep is worse than none.]

  • Account data: while your account exists, and erased when you delete it from your account page.
  • Class-section data, including graded transcripts: kept for the section, and deleted when the section is deleted. Deleting a section removes its rosters, activity, evaluations, transcripts, discussions and check-ins.
  • Usage telemetry: retained in aggregate; the hashed IP is not reversible to you.
  • Audit records of administrative access: retained as a security record and not deleted with the section.

Your rights

Take a copy, or delete everything, from your account page.Both are self-service and neither needs anyone’s permission: the export downloads as a JSON file, and deletion removes your account and everything in it immediately and irreversibly. To have something corrected rather than deleted, write to the contact address above.

Two things deletion deliberately does not erase. What you wrote in a paired discussion stays in your partner’s thread as a removal marker, with your name and your words gone — their record of that conversation is not yours to erase. And records of administrative access to a class are kept as a security log; an audit trail that erases itself on request is not an audit trail.

If you are a student in the United States, records your instructor uses for grading may be education records under FERPA, which gives you a right to inspect and review them and to request correction. Those requests go to your institution. If you are in the UK or EU, your UK GDPR / GDPR rights are exercised against your institution for class data, and against ux-phi for your personal account.

Grades are not decided automatically. The evaluations ux-phi generates are drafts for your instructor to read, override, or ignore; a person decides your mark.

Administrative access

A class section can be read through ux-phi by the instructor who owns it, and by nobody else. There is no administrator override: the operator of ux-phi cannot open another instructor’s roster, gradebook, evaluations or transcripts through the site, and no site-wide listing of other people’s classes exists.

Being precise about what that does and does not mean, because the difference matters: it removes standing access through the application. It does not remove the operator’s ability to query the database directly, which is inherent in running the service and which no application-level change can take away. Anyone who tells you otherwise about any hosted service is overstating it. What can be said honestly is that there is no routine path, no interface, and no day-to-day reason to look.

If your institution needs a stronger guarantee than that — contractual limits on operator access, or a support process that runs only on an instructor’s explicit invitation — that belongs in a written agreement with the institution, and is available on request.

Changes

When the course consent text changes, the new version gets a new version stamp, and a seat records the stamp it was taken under — so it is always possible to show a student exactly what they agreed to.

Terms of use