陈科林

Posted on Jun 21

Building a Transparent Digital SAT Score Estimator Without Pretending It Is Exact

#webdev #nextjs #typescript #learngoogleaistudio

Score calculators look simple from the outside: enter a number of correct answers, apply a conversion table, and display a score.

The Digital SAT makes that approach unreliable.

It is adaptive, its operational scoring model is not publicly reproducible, and College Board does not publish one universal raw-to-scaled conversion table for every test form. An independent calculator therefore has two choices:

present false precision, or
make uncertainty part of the product.

I chose the second approach while building a free Digital SAT score estimator.

The core product decision

The most important decision was not a framework or library. It was deciding what the output should mean.

The tool does not claim:

that every question has a fixed point value;
that the same number of correct answers always produces the same score;
that it can identify a student's exact adaptive route; or
that its result will match an official score report.

Instead, it answers a narrower question:

Based on these practice-module results, what broad score range is useful for study planning?

That wording changes the implementation, interface, and content around the calculator.

Why module-level inputs still matter

The Digital SAT contains two modules in each section:

Math: 22 questions per module;
Reading and Writing: 27 questions per module.

Performance in the first module affects the difficulty of the second module. The interface therefore asks for four inputs rather than one overall percentage:

Math Module 1 correct;
Math Module 2 correct;
Reading and Writing Module 1 correct;
Reading and Writing Module 2 correct.

The current estimator captures those module results separately but uses their section totals to select broad planning bands. It does not infer which Module 2 route the student received. That limitation is shown directly in the UI.

Keeping the implementation deliberately boring

For this kind of tool, understandable code is more valuable than an impressive-looking formula.

Here is the simplified Math estimator used by one calculator path:

function estimateMath(total: number) {
  if (total >= 41) return "760-800";
  if (total >= 36) return "700-770";
  if (total >= 31) return "640-710";
  if (total >= 26) return "580-650";
  if (total >= 21) return "510-590";
  if (total >= 16) return "430-520";
  if (total >= 11) return "340-440";
  return "200-350";
}

The Reading and Writing path follows the same pattern with thresholds appropriate to its 54-question total.

Inputs are clamped before calculation:

const first = Math.min(22, Math.max(0, Number(module1) || 0));
const second = Math.min(22, Math.max(0, Number(module2) || 0));
const total = first + second;

This prevents negative values, values above the module limit, and empty inputs from producing impossible results.

The interesting part is what the code intentionally does not do. It does not hide a speculative formula behind decimal places. A result such as 700-770 communicates the model's actual level of confidence better than an unsupported result such as 742.

Treating limitations as part of the interface

A disclaimer buried in a footer is easy to ignore. For an educational estimator, limitations should appear near the result.

The calculator explains that:

the range uses correct-answer totals;
it does not reproduce College Board's operational scoring model;
it cannot know the exact characteristics of the questions on a real test;
different forms and adaptive paths can produce different official scores; and
an official Bluebook score should take priority when one is available.

This is not just defensive copy. It helps users understand why two students with the same number of correct answers may not receive identical official scores.

Sources before formulas

Before defining score bands, I started with the public structure and scoring language in College Board materials:

Those sources establish what an independent tool can responsibly say. They do not provide enough information to recreate the official scoring engine.

That distinction matters. Public documentation can support an educational estimate without supporting a claim of exact prediction.

Product lessons from this small project

1. Precision and accuracy are different

Adding more digits makes an answer look precise. It does not make the underlying model more accurate.

2. Uncertainty can be useful output

A range is not a failure when the data cannot support a point estimate. It is often the more honest product.

3. Explainability belongs in the main flow

Users should be able to understand what inputs are used, what the output means, and what the model cannot know without reading legal text.

4. Educational tools need careful language

Phrases such as "estimated range," "planning use," and "independent tool" are functional parts of the product, not marketing decorations.

5. Simple code is easier to audit

Threshold-based bands are limited, but their behavior is visible. Future calibration can improve them without pretending the current version is more sophisticated than it is.

What I would improve next

The next useful improvements are not cosmetic:

version the score-band assumptions;
test all boundary values automatically;
compare estimates against a larger set of official practice-test outcomes;
communicate uncertainty more visually;
explain why an official Bluebook result can differ; and
keep methodology changes visible to users.

The long-term goal is not to reverse-engineer an unpublished scoring system. It is to make a planning tool more transparent and better calibrated.

I published the current assumptions, sources, and limitations on the project's methodology page.

The project is independent and is not affiliated with or endorsed by College Board.

If you have built calculators around incomplete public data, I would be interested to hear how you communicated uncertainty without making the tool feel unhelpful.

DEV Community