Architecture & Design Brief · Confidential

The Adaptive
Assessment Platform

A separation-of-concerns architecture for a test-prep business that starts with PSAT / SAT / ACT — and is built from day one to extend into any subject, any market, any price point.

v0.1 — Design Discussion Three layers + one data asset Prepared for founder review
01 — The core idea

Stop building one app. Build three things that version independently.

The current build collapses four very different jobs into a single codebase: authoring questions, deciding what to ask next, presenting the experience to a user, and owning the data. When those concerns share one body, every edit risks breaking everything, and none of them can be sold, scaled, or experimented with on their own.

This design pulls them apart into three layers that each version independently — a Reference Data authoring system, a stateless Engine, and a family of Clients — all feeding one accumulating data asset. Authors can churn on content without touching production. The adaptive logic can be upgraded without rewriting the apps. New market-specific apps can launch without endangering the moat.

LAYER 1 Reference Data Interactive authoring app Mutable while you build… …freezes to an immutable versioned config. FROZEN CONFIG immutable JSON LAYER 2 The Engine Stateless · versioned ▸ Defines its input protocol ▸ Picks the next question ▸ Replays any past journey ▸ Runs counterfactuals ▸ Diagnoses: bad day vs.    true weakness loads Free / Data-capture client volume + history accumulation Tutor client cohort tooling, assignment view Parent premium · $1,500 progress monitoring, alerts Bleeding-edge / alpha newer engine version, isolated LAYER 3 — CLIENTS (own the state) input / replay state → ← next question The Data Moat Central event store — every journey, from every client, persisted in one place THE REAL ASSET · COMPOUNDS OVER TIME emits events
Reference Data / Authoring Stateless Engine Clients Data Moat
LAYER 01

Reference Data

An interactive authoring tool whose output is a frozen, immutable, versioned config — not a live database the apps read from.

How it works

  • Authoring is interactive and messy by design. Authors create and mutate questions, including semantic variants — questions that can be reworded or re-parameterized but still test the same thing.
  • The output is an artifact, not a connection. When an author is ready, they release a big JSON blob: a frozen, immutable configuration.
  • Clients pin to a release. A client points at a specific frozen config and stays there until it deliberately upgrades — so upstream edits never disrupt anyone mid-flight.
Why this matters

Authoring is the noisiest activity in the whole system — constant edits, fixes, new items. If the apps read live from that, every typo is a production incident.

By making the output an immutable, addressable artifact, you decouple the people creating content from the people consuming it. And it's not just questions — anything that needs to be authored, reviewed, and frozen can flow through the same machine.

FIG.02 — The versioning model

Each item carries three independent dimensions of identity, so a consumer can always ask: “what was live for this user at this moment,” or “what is current right now,” and get a stable, reproducible answer.

time → EFFECTIVE PERIOD · Jan–Mar = a Version. The set that was live for this window. r1 · r2 · r3 (in-place typo fixes) EFFECTIVE PERIOD · Apr–Jun = a new Version released for the next window. r1 · r2 … →
LAYER 02

The Engine

A stateless decision engine with a defined input protocol. It holds no memory of its own — which is exactly what makes it powerful.

How it works

  • Defined protocol in, decision out. Given a frozen config plus a client's input (the journey so far), it returns the next question to show.
  • Replay. Feed it a chain of past events and it reconstructs exactly what happened — deterministically.
  • Counterfactuals. Change a variable in that chain — “what if we'd shown the easier item here?” — and re-run to see how the journey would have diverged.
  • The diagnostic that matters. This is where you separate “missed it on a bad day” from “genuinely weak in this concept,” by reasoning over the full replayed pattern rather than a single answer.
Why stateless

Because it carries no state, the engine is versionable (pin a client to v3 while v4 bakes), reproducible (same inputs always yield the same output), and infinitely scalable — spin up thousands of identical instances and tear them down freely.

State is a liability you push to the edges. The engine becomes a pure function over (config, history)decision, which is what makes both replay and honest A/B-style counterfactuals even possible.

LAYER 03

Clients

The apps users actually touch. Each one owns the journey history and can target a completely different market — without polluting the engine or the moat.

How it works

  • Clients own the state. Since the engine is stateless, the client is responsible for storing the replay — the record of what the user did.
  • Clients tweak the gears. Their input shapes what the engine returns, so different clients can produce meaningfully different experiences from the same engine.
  • Clients can run different engine versions. One app on bleeding-edge, one on the stable line, alpha testing in full isolation from the primary product.
Why many clients

This is where the business model lives. The same core can power a free, data-hungry app, a tutor tool, and a $1,500 parent product — each with its own UX, features, and price — without any of them cannibalizing the others or leaking into the engine.

Want to chase a lower-income segment with a leaner interface? That's a new client, not a new platform.

FIG.03 — One engine, many go-to-market surfaces
ClientPrimary goalWhat's specialRuns on
Free tierAccumulate history at volumeFrictionless onboarding; data is the paymentstable
TutorB2B / professional useCohorts, assignments, intervention viewsstable
Parent premiumMonetize at $1,500Progress monitoring, alerts, accountabilitystable
AlphaDe-risk new logicIsolated; can't touch production datableeding-edge
CROSS-CUTTING

The Data Moat

Every client feeds one accumulating store. The engine emits events; nothing stays trapped inside an app. The data is the durable asset — and it compounds.

How it works

  • The engine pops events off to persist them centrally without ever holding state itself.
  • All clients converge on the same store, so a free user and a $1,500 user enrich the same asset.
  • New question domains plug in fast. Once the machine exists, spinning up LSAT, MCAT, or non-test subjects is mostly authoring + a client — the moat keeps deepening across all of them.
Why it's the point

The founder is right that the data is the moat — but a moat only forms if the data isn't fragmented across apps and tangled with presentation logic. This architecture exists, in large part, to keep that asset clean, central, and growing while everything around it is free to change.

Eventually that asset is what you license, sell into, or build new products on top of.

04 — For the conversation

Untangling the priorities

Right now these requirements sit on top of one another, which is what makes the project feel like one impossibly large thing. Assigning each one to the layer that owns it is how the scope becomes buildable — and how we decide what's actually phase one.

What the founder wantsWhere it lives
“Questions that can be modified but still mean the same thing”
REFERENCE DATA
Semantic variants + versioning in the authoring layer.
“Full replay history of a user's journey”
CLIENT
ENGINE
Client stores the chain; engine reconstructs it deterministically.
“Change the variables and see how the replay would have gone differently”
ENGINE
Counterfactual replay — only possible because the engine is stateless.
“Bad day vs. a subject they're genuinely weak on”
ENGINE
Diagnostic reasoning over the replayed pattern, not a single answer.
“The data is the moat”
DATA MOAT
Central event store fed by every client.
“Different markets and price points (free, tutor, $1,500 parent)”
CLIENTS
Each is its own app on a shared core.
“Extend beyond test prep into other subjects later”
ENGINE PROTOCOL
AUTHORING
New domains = new authored content + a client, not a rebuild.
05 — What this buys you
Change without fear

Authors edit, the engine upgrades, new apps launch — none of it breaks the others, because each layer versions on its own.

Scale on demand

A stateless engine spins up to thousands of identical instances and back down — no coordination, no shared memory.

Many businesses, one core

Free, tutor, premium, white-label — different price points and markets without rebuilding or cannibalizing.

A moat that compounds

Every interaction across every client deepens one central data asset that stays clean and sellable.