Back to all writing

Verbal Knows Verbal. Quant Knows Quant. Intelligence Knows Me.

IPMAT Series•Part 24•10 min read•By Mikhil

Verbal Knows Verbal. Quant Knows Quant. Intelligence Knows Me.

There is a sentence that finally made the architecture click for me:

Verbal knows Verbal.

Quant knows Quant.

Intelligence knows me.

Not literally me as a person.

Not my entire life.

Not what I had for breakfast.

The learner.

The preparation state.

The evidence created across the two subject products.

That distinction became the reason Intelligence deserved to exist as its own application.

Analytics inside one subject can only go so far

Verbal can become extremely intelligent about Verbal.

It can understand vocabulary retention.

Recall.

Reading.

Grammar.

Question performance.

Verbal timing.

Exam behaviour.

Quant can do the same for its own world.

Topics.

Difficulty.

Formula use.

Calculation.

Short Answer.

DI.

Timing.

Mocks.

But preparation decisions are often cross-subject decisions.

If I have two hours today, where should they go?

If Verbal is improving and Quant is stagnating, should the allocation change?

If my Quant concepts are fine but timed execution is poor, what kind of work matters?

If vocabulary retention is decaying while Quant review debt is growing, which issue is more urgent?

One subject app should not pretend to answer everything.

So the larger synthesis needed somewhere else to live.

Intelligence is not another practice app

This was the first rule.

I do not want to solve vocabulary questions inside Intelligence.

I do not want to do arithmetic there.

The subject products already exist for that.

Intelligence should be the place I go when the question changes from:

What should I solve?

to:

What is happening in my preparation?

That creates a much cleaner interface boundary.

The Home screen starts with state

The Intelligence home is not supposed to be a trophy cabinet.

Its job is to show the current learner state.

What changed?

What needs attention?

How healthy is the evidence?

What are the highest-priority actions?

That sounds simple.

It depends on a lot underneath.

The system needs to know the difference between recent change and old history.

Between strong evidence and sparse evidence.

Between a temporary bad session and a persistent bottleneck.

Between a subject weakness and an execution weakness.

The interface can stay simple only if the model underneath is careful.

Combined analysis needed subject-specific views too

A combined dashboard is useful.

It can also become too broad.

Sometimes I want:

How is the whole preparation going?

Sometimes I specifically want:

What is happening in Verbal?

or:

What is happening in Quant?

So Intelligence keeps both.

Combined analysis.

Verbal analysis.

Quant analysis.

That separation matters because cross-subject synthesis should not erase subject detail.

A learner can have one overall preparation state while still needing very different explanations inside each subject.

Skills needed a graph, not only topic percentages

Topics are useful.

Skills can cut across topics.

A learner may repeatedly struggle with inference in different verbal contexts.

Or setup complexity across several Quant domains.

Or timed execution even when conceptual mastery is acceptable.

So the Intelligence layer has a skill view intended to expose bottlenecks, confidence and relationships rather than only displaying syllabus percentages.

The goal is to move from:

Weak at this chapter

toward:

This recurring capability appears to be causing problems across several kinds of work.

That is a much more interesting learner model.

Mocks deserve their own intelligence

Mocks are not just big practice sessions.

They reveal different behaviour.

Pacing.

Selection.

Risk.

Overinvestment.

Easy misses.

Negative-mark losses.

Recovery.

Section-level execution.

That means mock intelligence deserves a surface of its own.

A subject app can show the raw analysis.

The Intelligence layer can ask what the pattern means across attempts.

Did the same pacing problem repeat?

Did easy misses fall?

Did a repair intervention improve selection?

Is the learner consistently overinvesting before the end of a section?

That is where longitudinal evidence becomes valuable.

Retention became bigger than vocabulary

Verbal taught me to think about forgetting.

Words decay.

Review matters.

But retention is not only a vocabulary problem.

Formulas can be forgotten.

Concepts can become fragile.

A topic that looked strong three weeks ago may no longer deserve the same confidence.

So Intelligence has a retention surface for forgetting, durability, review debt and relearning.

I like this because it turns "I knew this once" into a measurable problem.

Learning is not only acquisition.

It is maintenance.

Planning became an output, not a to-do list

This is another place where EBO changed the design.

I do not want Intelligence to become a giant manual planner.

The plan should be generated from evidence where possible.

What is due?

What is weak?

What is improving?

What is urgent?

What has enough evidence to justify intervention?

What does the learner actually have time for?

That can become a daily or weekly plan.

The plan is still editable.

The learner remains in control.

But the system should be capable of doing more than displaying twenty charts and leaving me to translate them into action myself.

Insights need history

One recommendation is useful.

A history of what the system believed can be more useful.

If Intelligence says:

Timed algebra execution is weak

today, and says something different three weeks later, I want to know why.

Did the evidence change?

Did an intervention work?

Did confidence increase?

Was the original conclusion weak?

This is why insights become a timeline rather than a single current truth.

The learner changes.

The model should be allowed to change too.

The settings screen matters more than usual

An intelligent system should expose more than theme preferences.

I want to know:

What data is being used?

What is the current evidence state?

What assumptions are being made?

What preferences affect plans?

What can be disabled?

How can data be exported or removed?

Model transparency is part of the product.

If the app makes claims about the learner, the learner should not feel like those claims appeared from a black box with no boundaries.

The engine became much deeper than "weakest topic"

The current learner model can consider things like:

Difficulty and recency.

Timed versus untimed gaps.

Response-time effects.

Session position.

Retention stability.

Retrievability.

Relearning cycles.

Confidence calibration.

Contradictory evidence.

Evidence coverage.

Verbal-specific patterns.

Quant-specific patterns.

Mock pacing.

Selection.

Risk control.

Easy misses.

Overinvestment.

Cross-subject allocation.

Recoverable performance.

That list sounds extremely technical.

The learner should not have to see most of it.

The whole point is that complexity underneath should create simpler decisions above.

Readiness is deliberately not a score prediction

This boundary matters.

The system can eventually say something useful about preparation state.

It should not casually become:

You will score X.

There are too many assumptions in that sentence.

Instead, readiness remains evidence-gated.

Do we have enough relevant evidence?

Is it recent?

Is it timed?

Does it cover the necessary skills?

Are there contradictions?

That produces a state.

Not a fortune-telling machine.

I prefer that.

The next-best action needed a success condition

A recommendation is much better when it can define what success would look like.

Not only:

Do Algebra.

But:

Repair these unrecovered algebra mistakes, then check whether accuracy and pace hold on fresh questions.

That changes the recommendation from a generic task into a small experiment.

The system can later ask:

Did it work?

If not, why not?

That is the beginning of an intervention loop.

Intelligence should learn which interventions work

This is one of the most interesting parts.

Suppose the system recommends review.

The learner does it.

Performance improves.

That is evidence that the intervention helped.

Now suppose another kind of recommendation repeatedly gets ignored or produces no measurable improvement.

That matters too.

Over time, the intelligence system should not only model the learner.

It should model which kinds of actions actually help that learner.

That is much more useful than a fixed recommendation hierarchy forever.

The app should separate observations from hypotheses

This principle became so important that it deserves repeating.

Incorrect answer is an observation.

Execution bottleneck is a hypothesis.

Repeated vocabulary lapse is evidence.

Retention problem is an inference.

Three slow solves happened.

The learner needs speed training is a conclusion.

Those should not live at the same epistemic level.

The system treats inferences as versioned, evidence-backed claims rather than pretending every label is raw truth.

That is one of the biggest differences between Intelligence and a normal dashboard.

The orange theme was the easy part

I spent time making sure Intelligence did not just look like Verbal or Quant with another accent colour.

It eventually settled into a warmer orange identity.

That helped.

But the important difference is not the theme.

It is the job.

Verbal feels like a learning product.

Quant feels precise and analytical.

Intelligence should feel like synthesis.

A place where the noise collapses into a few meaningful decisions.

The UI can look different because the cognitive task is different.

It still runs partly in prototype mode

This is important.

The Intelligence application can run against synthetic raw event data during development.

That data passes through the same learner-model pipeline rather than hard-coding fake dashboard outputs.

But prototype data is still prototype data.

The interesting model logic exists.

The full real-world value only appears once Verbal and Quant are reliably emitting the canonical evidence and the system has enough longitudinal history.

That integration is still work.

I do not want screenshots of synthetic evidence to become a claim that the learner model has already been validated on a real population.

It has not.

The real integration boundary is now obvious

Intelligence is ready to receive a shared contract.

The subject apps still need to emit it consistently.

Attempts.

Sessions.

Reviews.

Mocks.

Stable IDs.

Retries.

Deep links back to the correct repair surface.

That work cannot be faked from inside the Intelligence repository.

The products actually have to agree.

This is boring integration work.

It is also what turns the architecture from a demo into a system.

Why not just put this inside the subject apps?

Because the questions are different.

Verbal should answer:

How do I improve Verbal?

Quant should answer:

How do I improve Quant?

Intelligence should answer:

Given what both products know, what deserves attention across my preparation?

If I force all three jobs into one interface, everything becomes broader and less clear.

Separation creates focus.

Shared evidence creates continuity.

That combination feels right.

The sentence still holds

Verbal knows Verbal.

Quant knows Quant.

Intelligence knows me.

Again:

Not my whole life.

The learner represented by the evidence.

The version of me that has answered these questions, forgotten these words, taken these mocks, repaired these mistakes and changed over time.

That is enough.

I do not need an omniscient study companion.

I need a system that understands the evidence it actually has and helps me do something useful with it.

That is what Intelligence is becoming.