Email Is Not an Identity

At a Glance

Problem: Email was how our systems recognized a student, but the email often wasn’t the student’s. It might belong to the school, the family, mom, or dad. When a student moved to another school or district and the email changed, they became a completely new user, and their history was lost.

Why I acted: Students change schools. That’s normal, not an edge case. A key that breaks on a normal event can’t be trusted to hold identity.

Approach: I started introducing external IDs and other unique identifiers, and built new integrations on those instead of email. When we built our first AI feature, we set a no-PII policy and tied each AI session summary to a session ID, with the connection back to the student kept outside the model.

Outcome: Never a 100% fix, and I won’t pretend otherwise. New integrations moved onto stable IDs, and the AI summaries connected to the right student without any PII going to the model.

A student moves to a new district. Their email changes, because the old one belonged to the old school. The next time their record comes through, our systems see an address they have never seen before.

So they create a new student.

The old record doesn’t disappear. It just stops being connected to anything that happens next, and the history attached to it is effectively lost. From a data perspective, a student we already knew became a stranger.

Why email looked safe

Email is everywhere. Every system has it, every import includes it, and at any given moment it is unique. When two systems need to agree on who someone is, email is the obvious answer, which is exactly why nobody questions it.

The problem is who the email actually belongs to. In our case, it depended. Sometimes it was the student’s school account. Sometimes it was a personal or family address. Sometimes it was mom’s, and sometimes it was dad’s. We were treating it as the student’s identity, but the student often didn’t own it, and whoever did could change it on their own schedule.

A match key isn’t just a field. It’s a claim about identity. If the value can change while the person stays the same, the claim is false, and every system built on it inherits the error.

This isn’t an EdTech quirk. Even Google tells developers not to use email as a user identifier, because a single account can have different email addresses over time.

The work, honestly

I started introducing external IDs and other unique identifiers, values our systems controlled that didn’t depend on which inbox a family happened to use. New integrations were built on those instead of email.

I’d like to say that solved it. It didn’t, not completely. There was never a 100% fix. What there was, was a direction: each new integration moved one step away from email and toward something that actually identified the student.

The same question, from a different direction

When we built our first AI feature, an AI session summary, we defined a policy at that moment: no PII goes to the model.

That was the easy decision. The harder question came right behind it. A summary is only useful if it belongs to the right student. How do you attach an AI output to a real person without the AI ever knowing who that person is?

The answer was the session ID. The summary was tied to the session ID. Outside the model, in our own systems, the session ID connected back to the student. The AI never needed a name or an email, and the summary still connected to the right student.

Look at what that required. The identifier going into the AI couldn’t be PII, and the connection back to the person had to live somewhere the model couldn’t reach. Email fails both tests. It’s PII, so it can’t go in. And as the district move showed, it can’t be trusted to hold the connection anyway.

Two separate pressures, the identity problem and the AI policy, pointed at the same answer: identify people with something you control, and keep the mapping to the real person on your side of the line.

The question worth asking first

AI can’t tell you which field your systems quietly trust to mean “this is the same person.” It doesn’t know unless you tell it.

So before any story touches data moving between systems, I’d ask two things. What does each system match on? And who actually owns that value?

If the answer isn’t a stable ID you control, you’ve found a constraint. Better to find it in the spec than on the day someone’s email changes.