Cognitive training

What I built

A training app built on one honest premise: spaced repetition reliably improves what you retain, adaptive working-memory and reasoning tasks reliably improve the task you train, and neither of them reliably raises general intelligence. It does both, and it tells the user which is which.

Technically the interesting part is that it works fully offline with no account, and that signing up later adopts the history you already have instead of starting you over.

At a glance

Result

Fully offline with no account; signing up later adopts the history you already have

Training

Spaced repetition, plus adaptive working-memory and reasoning tasks

Architecture

The browser is the whole application; the server only holds a copy

Sync

One snapshot per user, last write wins, as a deliberate and bounded loss

Scheduling

The published algorithm this field has converged on, configured rather than reimplemented

Known limits

Levels are tuned by hand per task and are not calibrated against each other

Claims

Does not claim to raise general intelligence, because the evidence is contested

Architecture

Scroll sideways to see the whole diagram.

The browser is the whole application: it schedules reviews, generates the tasks, adapts difficulty and computes the statistics. The server exists only to hold a copy. That ordering is the design — not "offline support" added to a cloud app, but a local app that can optionally be backed up.

Engineering decisions

1. Local first, account optional and later

Problem

Daily-habit software is used for months or abandoned in one session. Asking for an account before the first exercise loses the people who would have stayed; but losing months of streaks to a cleared browser loses the ones who did stay.

Options

Require an account, keep everything local, or make the account a later, optional addition.

Chose

The third, and enforced it rather than promised it: the cloud routes answer that they are unavailable when no database is configured, so the app has to work without them by construction and cannot quietly grow a dependency. Creating an account adopts the local history that already exists instead of opening an empty one, which is the moment where most apps of this kind silently throw away the user's first month.

Cost

The local store can fail in ways you do not get to see — quota, private browsing — so every read and write has to tolerate being dropped, and the app must behave sensibly with no stored state at all rather than treating that as impossible.

2. Sync as one snapshot, last write wins

Problem

Two devices, one person, and state that changes on both.

Options

Sync per item with conflict resolution, or store one document per user and accept that the later write wins.

Chose

One snapshot per user, written as an upsert, with the statistics computed in the browser rather than stored. The data is small and single-user: a real merge strategy would have cost days and bought protection against a scenario — the same person training offline on two devices in the same window — that is rare and cheap to lose.

Cost

That scenario does lose work when it happens. The decision was to take a known, bounded loss deliberately instead of discovering later that a homegrown merge had corrupted a scheduler's state, which is the failure that would actually be unrecoverable.

3. The scheduler is not mine, on purpose

Problem

Review timing is the entire product. Get it wrong and the app is worse than paper.

Options

Write a heuristic — satisfying and almost certainly worse — or use the published scheduling algorithm this field has converged on.

Chose

The published one, configured rather than reimplemented: a retention target set explicitly, and interval fuzz on so that cards learned together do not stay clumped together for years. On top of it, the interval each answer button will produce is shown on the button, because the user's own rating is the only input the algorithm has and people rate more honestly when the consequence is visible.

Cost

A dependency at the core of the product, and the statistics needed a separate approximation of the forgetting curve because the library exposes scheduling rather than current recall probability. Reimplementing to avoid that would have traded a small annoyance for a large risk.

4. Difficulty comes from the rule, not from the numbers

Problem

The training only does anything at the edge of the user's capacity, so difficulty has to move — and the obvious way to move it is the wrong one. Bigger numbers make a reasoning task longer, not harder.

Options

Scale magnitude, which is trivial to implement and measurable, or scale subtlety, which has to be designed per task.

Chose

Subtlety. Operands stay small and the underlying rule gets less obvious as the level rises; each task type carries its own level configuration instead of a shared global difficulty, because "harder" means something different for a span task than for a pattern task. And there is a level picker, so someone who is already capable starts high instead of grinding up from the bottom — making a user spend a week below their capacity is not caution, it is the one thing that makes the training useless.

Cost

Every task type is tuned by hand and the levels are not calibrated against each other, so level 6 in one exercise is not level 6 in another. Fixing that properly needs data from real users, which is a reason to leave it visible rather than pretend the scale is uniform.