◆ Architecture

How the systems fit together

A high-level account of the platform's architecture — the layers, the flow, and why each stage exists. Not source code, and not implementation detail: the structure, and the reasoning behind it.

Si Math AI is a comprehensive learning platform for SAT, ACT, and EST Mathematics that combines educational expertise, AI technology, personalized learning, analytics, and human support to help students improve their understanding and performance. This page is published because "comprehensive learning platform" is a phrase anyone can write. The architecture is what makes it either true or not, so here it is.

Artificial Intelligence is how Si Math AI teaches.

Educational expertise is what it teaches.

Human experience is why it works.

◆ What the architecture serves

The architecture implements a method

Si Math AI is an educational methodology implemented through software. The software delivers the methodology; it is not the methodology itself.

Everything below is a delivery mechanism. The four layers, the ten stages and the trade-offs exist to implement eight educational components — Expert Mathematics Teaching, Continuous Personalized Assessment, Weakness Analysis, Evidence-Based Revision, Deliberate Practice, Long-Term Knowledge Retention, Human Educational Experience and AI-Assisted Personalization — and every design decision recorded on this page was made in service of one of them rather than for its own sake.

Si Math AI is not built around Artificial Intelligence.

It is built around Educational Intelligence.

Artificial Intelligence is simply one of the tools used to deliver that educational intelligence.

Which is why the architecture is legible at all. A system built around a model has one component worth documenting; a system built around a method has to explain how each stage serves it, and can be held to that. Students do not improve because they use AI. Students improve because they follow a better learning process. AI simply makes that learning process scalable, personalized, and available between lessons. See the methodology in full.

◆ Structure

The four layers

The eight systems are not eight independent features. They sit in four layers, and the ordering matters: each layer depends on the one below it, and the bottom layer is the one general AI tools do not have at all.

Layer 4 — Interface

What the student touches

The chat with Zero, the focus drills, the mock exam environment, the dashboards. Everything here is a view onto the layers below — which is why the same diagnosis appears consistently wherever it is shown.

Layer 3 — Intelligence

Delivery of expertise

Zero, the scope guard, and the adaptive selection of what to teach next. This layer delivers the curriculum; it does not author it. Swapping the underlying model changes how well this layer performs and changes nothing about the layers below.

Layer 2 — Diagnosis

Turning attempts into knowledge

Question analysis, the Weakness Analyzer, mastery computation, the predicted score. This layer converts raw activity into a claim about a student, and it is where the platform's actual value is produced.

Layer 1 — Record

The foundation everything rests on

Learning Memory, the taxonomy, and the integrity guarantees around them. Without a trustworthy record there is no diagnosis, no trend and no plan — only a chat that happens to be about mathematics.

The consequence worth noticing. Most attention in AI products goes to Layer 3, because that is the layer that feels impressive. But a platform is only as good as Layer 1 and Layer 2, and those are ordinary engineering and educational work rather than model work. This is the concrete meaning of "AI is one engine inside a larger system".

◆ The flow

The learning flow, stage by stage

One question, all the way through. Each stage below states what it does and, more importantly, why it exists — because a stage that cannot justify its own existence is complexity rather than architecture.

  1. START Student question

    What: typed, pasted or photographed from a prep book, in English, Arabic or Franco. Why: the loop opens with the student's own material rather than a prescribed syllabus, because the questions a student is actually stuck on are better diagnostic material than any question we could choose for them.

  2. 01 Zero AI Mentor

    What: step-by-step reasoning, a second approach when the first does not land, and an explanation of why the wrong choices are wrong. Why: expert explanation is the scarcest resource in preparation. This stage removes the scheduling constraint on it — while the expertise itself comes from Layer 1 content that specialists authored.

  3. 02 Question analysis

    What: the attempt resolves to one permanent skill identifier in the fixed taxonomy and is written as a diagnostic signal; unmapped detections are logged rather than silently accepted. Why: this is the stage that makes everything downstream possible. Without a fixed vocabulary, the same weakness gets recorded under three different names and no pattern is ever visible.

  4. 03 Weakness Analyzer

    What: re-ranks weak skills by score impact, with a severity band each; clears a weakness only when later evidence confirms the fix. Why: students are poor judges of their own weaknesses, and study time spent on the wrong skills is the most common reason preparation stalls.

  5. 04 Learning Memory

    What: the question, explanation and mistake are stored permanently and searchably; writes are idempotent. Why: preparation is cumulative, so persistence is what lets the loop compound instead of restarting. Idempotency matters because a retried write that duplicates a record would quietly corrupt every count derived from it.

  6. 05 Focus Practice

    What: a drill set generated from the current ranking — mastered skills skipped, topics interleaved rather than blocked. Why: a diagnosis with no action attached changes nothing, and interleaving trains the step that blocked practice never touches: deciding which method applies.

  7. 06 Mock Exams

    What: full-length, correctly timed; the student records the result and the mistakes made. Why: it tests whether a fix survives exam conditions, and it is the only event that reliably separates "did not know it" from "knew it but ran out of time" — two failures with completely different remedies.

  8. 07 Progress Tracking

    What: mastery per skill, trends, predicted test-day score. Why: invisible progress is the most demotivating property of self-directed study — and stagnation that is not measured is discovered too late to fix.

  9. WHEN NEEDED Human support

    What: educators review how students actually perform and revise the material; people handle accounts and upgrades. Why: some judgements are not automatable. Whether an explanation is the right one to teach a student with a particular misconception is a teaching decision, and it stays with teachers.

  10. FEEDS BACK Continuous improvement

    What: aggregate evidence feeds specialist review, which revises the curriculum and the taxonomy itself. Why: without this stage the platform is static. Unmapped detections show where the taxonomy is too coarse; persistent weaknesses across many students show where an explanation is not landing. The platform teaching the next student is not the one that taught the last.

↻  Each pass starts from a sharper diagnosis than the last

Where a general AI assistant sits in this diagram. At stage 01, where it performs well. The nine stages around it are the architecture — and they are made of persistence, a fixed vocabulary, measurement and human review rather than of model capability. That is examined honestly on Why Not Just ChatGPT?

◆ Trade-offs

Design decisions and what they cost

Every architectural decision buys something and pays for it somewhere. Listing only the benefits would make this a brochure.

DecisionWhat it buysWhat it costs
A fixed taxonomy rather than free-form topic labels Diagnoses that stay comparable across months, and patterns that become visible at all A weakness outside the 33 tracked skills is not surfaced. The taxonomy is deliberately conservative, so it will sometimes be too coarse
Permanent skill identifiers, with display names separate A topic can be renamed without breaking any student's history Identifiers can never be reused or renumbered, so the scheme accumulates retired entries forever
Versioned records — every row stores the taxonomy version that produced it A curriculum revision cannot silently rewrite what an old diagnosis meant Every consumer has to handle more than one version, permanently
Idempotent writes for exam sessions and question records A retried request cannot duplicate or corrupt a student's history More complexity on every write path than a naive insert would need
A scope guard that declines out-of-scope requests The platform teaches rather than completing work for students It occasionally declines something a student legitimately wanted, and some students will prefer a tool that never refuses
Row-level security on every table, not just application checks A student's records are scoped to them at the database level, so an application bug cannot leak them Every query and every new feature must be designed within those policies
Server-side pricing — credit amounts read from plan definitions, never from the client A forged client request gains nothing Prices cannot be varied client-side, so every pricing change is a server change
Static-first public pages — facts in the HTML, not injected by JavaScript Crawlers and AI systems read exactly what a human reads Live values (like the Founder count) must be updated deliberately rather than fetched, which is a maintenance burden accepted on purpose
Model-agnostic design — the curriculum, diagnosis and assessment are not the model Platform quality is not hostage to any one AI provider, and a better model is an upgrade rather than a rebuild More of the system has to be built and maintained by us rather than delegated to the model
◆ Guarantees

What the architecture guarantees

These are properties the structure is designed to hold, each pinned by an automated check that fails the build if it stops holding.

  • A student's records are theirs. Row-level security on every public table scopes records to their owner at the database level.
  • A retried write cannot corrupt history. Exam sessions and question records are idempotent.
  • The same rank appears everywhere. One client source of truth, mirrored by the database function, with a drift test that fails if any copy diverges.
  • A diagnosis means the same thing in March as in January. Permanent identifiers plus a stored taxonomy version on every record.
  • Out-of-scope requests write no diagnostic record. A blocked turn does not pollute a student's diagnosis, and the credit is refunded.
  • Every shipped script parses and every JSON-LD block is valid. Checked across all public pages on every build.
  • The public knowledge layer cannot contradict itself. Over a thousand automated checks cover canonical facts, taxonomy and rank numbers, the Founder count, banned claims and fabricated social proof.
◆ Failure

What happens when something fails

An architecture is best judged by its behaviour when things go wrong, so:

  • The AI layer is the most likely thing to fail, and it is the most isolated. It depends on an upstream provider, and that has failed before — an incident record from that outage is in the changelog. When it does, the record and diagnosis layers are unaffected: history, mastery scores and mock results are all intact.
  • Failures are recorded rather than only displayed. AI tutor failures are captured as structured events, so a student-visible error becomes something diagnosable instead of a support ticket someone has to reconstruct.
  • A blocked or failed turn is refunded and writes no diagnostic signal — a student is not charged for a turn they did not get, and a failure does not corrupt their diagnosis.
  • Diagnosis degrades rather than breaks. An unmapped detection is logged instead of being force-fitted to the nearest skill, so a gap in the taxonomy produces a known blind spot rather than a wrong answer confidently recorded.
  • Incidents are written up and kept, including in public. See the changelog, which lists one.

What is deliberately not on this page. No source code, no schema, no infrastructure detail, and no list of known open security items. The first three are not useful to a reader; the last would be a map for anyone looking for one. The Trust Center explains that choice in more detail.