One Student Should Not Have Three Identities
Login screens are deceptively simple.
Email.
Password.
Continue.
Done.
That is how identity looks from the front.
Underneath three connected learning products, it becomes much more serious.
Because once Verbal, Quant and Intelligence all exist, the system has to answer a basic question perfectly:
Who is this evidence about?
Not approximately.
Not most of the time.
Perfectly enough that one learner's history never becomes another learner's history.
Sharing authentication is the easy part
All three apps can use the same authentication provider.
That gives me one user ID.
Useful.
But one user ID alone does not create one learner.
The account also owns:
Attempts.
Bookmarks.
Vocabulary state.
Formula state.
Reviews.
Mocks.
Preferences.
Devices.
Offline queues.
Entitlements.
Recommendations.
Intelligence snapshots.
Every one of those things needs the same ownership rules.
If even one layer uses a different assumption, the account stops being coherent.
Account switching is where this becomes dangerous
Imagine this:
User A studies offline.
Some events remain queued locally.
User A signs out.
User B signs in.
The device reconnects.
Who owns the queued events?
This is not a theoretical edge case.
It is exactly the kind of thing that happens when local-first software meets multiple accounts.
If the queue is not identity-scoped, the system can upload User A's learning into User B's history.
That is not a minor sync bug.
That corrupts the learner model.
So account switching became one of the strongest tests of the platform architecture.
A queue belongs to a user.
A local cache belongs to a user.
A bookmark belongs to a user.
A pending write belongs to a user.
Identity has to travel all the way down.
One learner also needs one preference state
Preferences sound harmless.
Theme.
Motion.
Haptics.
Exam targets.
Daily goals.
Notification choices.
But if each app stores its own independent version, the ecosystem starts feeling fake immediately.
Imagine turning reduced motion on in one product and having another ignore it.
Or changing an exam target in Quant while Intelligence still plans around the old one.
Small inconsistencies make the system feel like three websites sharing a logo.
So shared settings became part of the platform.
Not because settings are exciting.
Because coherence is.
Bookmarks exposed the same problem
A bookmark is one of the simplest pieces of state in a learning app.
Saved.
Not saved.
Still easy to get wrong across devices.
Device A saves a question.
Device B unsaves it.
Device A reconnects later.
Which state wins?
If writes are just timestamps from whatever device happens to send last, clock differences can create nonsense.
If the system silently overwrites changes, the learner loses trust.
So even simple state needs a conflict model.
Versioning.
Acknowledgement.
A server-authoritative result.
Sometimes the boring parts of distributed systems show up inside a star icon.
Identity also has to survive content changes
Suppose I answered Question 42 last month.
Today, an editor fixes the wording.
Maybe the answer changes.
What does my historical attempt refer to?
"Question 42" is no longer enough.
The learner needs to own an attempt against the exact content version they saw.
Otherwise old analytics can change when new content is published.
That is terrifying.
History should describe the past.
Not today's mutable database row.
So immutable versions became part of identity too.
Not user identity.
Evidence identity.
Devices became real entities
At first, a device is just somewhere the app happens to run.
Once offline learning exists, devices matter.
Which device created the event?
Was it revoked?
Was it already synced?
Does it have a stale queue?
Is this event a retry?
Can this device continue working temporarily offline?
You do not need to show most of that to the learner.
The platform still needs to understand it.
That is how "continue on another device" becomes a real promise instead of marketing copy.
Access belongs to the same learner too
The account can have different product access.
Maybe Verbal.
Maybe Quant.
Maybe broader Intelligence access.
The exact commercial structure can change later.
The architecture should not require rewriting every feature when it does.
So access moved toward capabilities rather than scattered checks.
A feature asks:
Does this learner have this capability?
Not:
Which pricing card did they buy six months ago?
That separation keeps the product logic cleaner.
The account should also be exportable and deletable
This is where identity stops being only technical.
If the ecosystem holds a meaningful learner history, the learner should have control over it.
Export.
Deletion.
Account recovery.
Clear ownership.
Those are not glamorous features.
They become more important as the learner model becomes more personal.
If Intelligence is going to form conclusions from months of evidence, I should not treat that history like accidental exhaust.
It belongs to the learner.
One student, one history
This became the phrase underneath the backend work.
Not:
One database.
Not:
One giant app.
One learner history.
Verbal can remain specialised.
Quant can remain specialised.
Intelligence can remain separate.
But underneath them, the account has to be continuous.
The learner should not become a new person because they crossed a product boundary.
This is also why I stopped liking duplicated backend logic
If Verbal has one sync model and Quant has another, bugs diverge.
If one product handles account switching correctly and another does not, the ecosystem is only as safe as the weaker one.
If every app invents access checks independently, entitlement logic drifts.
Shared concerns should be shared.
That sounds like an obvious architecture principle.
I had to grow three codebases before it became emotionally obvious.
The interface should hide all of this
The learner should not care about any of these terms.
Ownership.
Versioning.
Device identity.
Conflict resolution.
Capability resolution.
Idempotency.
Queues.
They should sign in once.
Study.
Change devices.
Continue.
That is the whole experience.
The more infrastructure I build, the more I understand that good infrastructure is mostly invisible.
You notice it when it fails.
One student should not have three identities
That sounds like a product slogan.
It is really a database constraint.
The same person should remain the same person across:
Verbal.
Quant.
Intelligence.
Web.
Android.
Offline.
Online.
Today.
Three months from now.
If I can preserve that, the ecosystem becomes much more than three apps.
It becomes one history viewed through different tools.
That is the foundation I should have built before I started calling it an ecosystem.
At least now I know.