Three Apps Needed One Memory

Three applications can look connected while knowing almost nothing about each other.

Same logo.

Same account button.

Same colour family.

Links between them.

That is not an ecosystem.

The real test is memory.

If I solve something in Quant, does the larger system know?

If I review something in Verbal, can Intelligence understand it?

If I retry after going offline, does the event get counted once or twice?

If I switch accounts, can one learner's evidence leak into another learner's model?

If an old question changes, does historical progress still point to the version I actually saw?

Those questions became more important than the visual connection between the apps.

Because once Verbal, Quant and Intelligence all existed, they needed one shared understanding of the learner.

Separate products create separate truths by default

Every application naturally invents its own data model.

Verbal had attempts.

Word reviews.

Exam sessions.

Bookmarks.

Learning state.

Quant had its own attempts.

Sessions.

Review.

Tests.

Drills.

Evidence.

Intelligence wanted to consume both.

Without a shared contract, this becomes dangerous quickly.

What does "attempt" mean?

What is a "skill"?

How do you identify a session?

What counts as a review?

Which timestamp matters?

How do you know whether an event is new?

How do you know which user owns it?

If every app answers differently, the learner model becomes translation software.

That is not where I want the complexity.

One account is not enough

It is easy to say:

All three apps use the same user ID.

Great.

That solves identity.

It does not solve meaning.

The apps still need to agree about what they send.

A common identity with incompatible events is like three people sharing a contact list while speaking different languages.

So the shared platform needed a producer contract.

A way for Verbal and Quant to describe learning events consistently enough that Intelligence can consume them safely.

Stable event IDs became surprisingly important

Offline systems retry.

Networks fail.

Requests time out.

A client may not know whether the server received something.

So it sends again.

If the event has no stable identity, the server may count the same learning action twice.

One question becomes two attempts.

One review becomes two reviews.

One achievement unlocks twice.

One piece of evidence becomes stronger than it really is.

That is unacceptable.

So learning events need stable IDs and idempotent writes.

Retrying the same event should mean:

Make sure this exists.

Not:

Create another one.

This is one of those boring details that quietly protects every analytical feature built above it.

Offline needed a queue, not optimism

"Works offline" is easy to say.

The harder question is:

What happens to actions that need the server later?

The shared client now has an offline retry queue concept.

Events can wait.

Reconnect.

Retry.

Deduplicate.

That is much more honest than pretending an offline action magically synced while the device had no network.

The queue also needs to be identity-scoped.

If User A has pending events and User B signs in, those events cannot silently become User B's history.

That kind of bug would poison the learner model.

Raw evidence should remain raw

Another shared-platform rule:

Do not let the intelligence system rewrite the source history.

Attempts are evidence.

Reviews are evidence.

Mock interactions are evidence.

The derived learner state can change.

The raw event should not.

That means the platform can keep append-only evidence while storing new derived snapshots over time.

This becomes extremely useful when the model changes.

Version 2 can re-interpret the history.

The history itself remains stable.

Skills needed a shared taxonomy

A cross-product learner model cannot reason well if Verbal and Quant invent completely unrelated skill semantics without any registry.

That does not mean every skill needs to be generic.

Verbal still has Verbal-specific concepts.

Quant still has Quant-specific concepts.

But the shared platform needs a canonical graph that knows what exists and how the evidence attaches.

Otherwise Intelligence cannot distinguish:

A subject.

A topic.

A subtopic.

A skill.

A cross-cutting bottleneck.

The taxonomy becomes the map underneath the learner model.

Sessions needed more than start and end

A session is not only duration.

It creates context.

Which product?

Which mode?

Which items?

What happened in sequence?

Was it finalized?

Did the learner return after interruption?

Did the app close?

Did the same session resume?

Those details matter for reliability and later interpretation.

A cross-app system cannot safely treat every event as an isolated point.

Sometimes sequence matters.

Mocks needed especially strong history

A mock is one of the most valuable pieces of evidence in the ecosystem.

It is also one of the easiest to corrupt if the state model is weak.

Question order.

Section.

Timer.

Response changes.

Marked-for-review state.

Submission.

Score.

Analysis.

Recovery.

Those things need stable versions.

If a mock definition changes later, the old attempt should still be explainable.

Historical evidence should not mutate because the content pointer moved.

That is why immutable versions and append-only event trails became so attractive.

Recommendations needed history too

If the system recommends something today and the recommendation simply disappears tomorrow, Intelligence cannot learn from it.

So recommendations need a lifecycle.

Active.

Accepted.

Dismissed.

Completed.

Expired.

And ideally an outcome later.

Did the learner do it?

Did it help?

This is another example of memory changing the quality of intelligence.

A system that only remembers current state cannot learn from its own advice.

Shared memory creates new privacy responsibilities

One learner profile across multiple products is convenient.

It also means the boundaries have to be stricter.

Each query needs ownership.

Each queue needs ownership.

Each derived state needs ownership.

One account switch bug can become much more serious when three apps share history.

That is why account isolation and least-privilege access are not database chores anymore.

They are product requirements.

The smarter the ecosystem becomes, the more damaging cross-account contamination would be.

Server-authoritative Intelligence creates a clean boundary

The subject apps should be able to submit evidence.

They should not be able to rewrite official intelligence conclusions directly.

So the server can verify the learner, load the relevant evidence and derive the current snapshot.

That keeps the official learner state behind a stronger boundary.

It also means the service credentials needed for that work stay server-side rather than leaking into web or mobile clients.

Again, the architecture is mostly invisible.

That is the point.

Deep links complete the loop

Intelligence should not become a dead-end dashboard.

If it recommends repairing a specific Quant skill, the learner should be able to jump back into the correct Quant surface.

If it detects a Verbal retention issue, the action should return to Verbal.

That creates a loop:

Evidence from subject app.

Interpretation in Intelligence.

Action back in subject app.

Outcome returns as evidence.

That is the real ecosystem.

Not three icons on one website.

The shared platform is not fully integrated yet

This is important.

The platform contract exists.

The Intelligence application is ready to ingest it.

But the current Verbal and Quant repositories still need their real solve, review, mock and session flows wired into the canonical event system consistently.

That cannot be declared complete because the schema exists.

Integration is where assumptions collide with real code.

It still needs to happen carefully.

Old migrations cannot simply be thrown together

Another lesson:

Shared backend does not mean copy every historical migration from every app into one database and hope.

The new platform baseline needs to be reviewed against the final subject repositories.

Tables can overlap.

Semantics can conflict.

Privileges can conflict.

Names can lie.

The shared schema has to become canonical deliberately.

Otherwise the ecosystem inherits every old experiment forever.

This is where "one learner" became technical

For months, saying:

These products should know the same learner

was a product idea.

Now it has actual engineering consequences.

Stable IDs.

Shared taxonomy.

Ownership.

Event contracts.

Versioned evidence.

Queues.

Idempotency.

Snapshots.

Deep links.

Server authority.

Audit history.

None of those appear in the hero screenshot.

Without them, the hero screenshot would be lying.

The best infrastructure is boring to the learner

The learner should not think about event IDs.

They should not know an outbox exists.

They should not understand dedupe keys.

They should not care which service derived a snapshot.

They should open Verbal.

Study.

Open Quant.

Study.

Open Intelligence.

See a coherent picture.

That simplicity is purchased with a lot of invisible complexity.

I am starting to appreciate that as a design pattern.

The more seamless the experience looks, the more precise the boundaries underneath often need to be.

Three apps needed one memory

Not one giant database table.

Not one giant interface.

One coherent memory.

A shared history of what actually happened.

Enough structure that each product can remain specialised while the learner remains continuous.

That is what turns:

Verbal.

Quant.

Intelligence.

from three projects into one system.

The UI made the ecosystem visible.

The memory is what makes it real.