Watch a student use a grammar checker and you'll see the failure mode of an entire product category: underline, click, accept, repeat. Thirty corrections applied, zero understood. The text improved; the writer didn't. For a consumer tool that's a shrug. For an education product — an LMS writing exercise, an ESL app, a university's writing center platform — it's the whole ballgame.

Building grammar feedback that actually teaches is a specific design problem. It comes down to four requirements most proofreading tools don't meet, and a privacy bar that's higher than anywhere else.

Requirement 1: every correction needs a reason

"I before E except after C" is a rule; "use visited, not have visited, because last year fixes the event in the past" is teaching. The difference is that the second one transfers to the next sentence the student writes alone.

Most checkers return, at best, a rule label pulled from a fixed list. What a learner needs is an explanation of this error in this sentence — ideally phrased in the language they're writing in, so a French student writing English gets feedback they can fully parse.

This is why AmberPen's evaluate mode exists. After the correction pass proposes edits, a second, high-reasoning pass reviews every proposed edit with its surrounding context and returns the edits worth applying — each with a short explanation in the input's language, a category, and every valid replacement ranked by relevance:

{
  "id": 0,
  "start": 2,
  "end": 7,
  "original": "have ",
  "replacement": "",
  "possibleReplacements": [""],
  "category": "grammar",
  "explanation": "With a finished time expression like “last year”, use the simple past: “I visited Paris last year.”"
}

The explanation is the product surface. Show it in the suggestion card, not a generic rule name — and your checker just became a tutor.

Requirement 2: restraint is a feature

Hand a learner's draft to an aggressive corrector and it returns forty suggestions, half of them stylistic preferences. The student learns two things: their writing is terrible, and clicking "accept all" is easier than thinking. Neither is the lesson you want.

Educational feedback research consistently points the same direction: focused feedback on a few error types beats exhaustive markup. Two mechanisms get you there with an API:

  • Filter by category. Evaluate mode labels each edit — spelling, grammar, style, repetition. Building a unit on articles and prepositions? Surface those, quiet the rest.
  • Let the pass filter for you. The evaluation pass drops the proposals it judges unwarranted before they reach your application, so an aggressive correction pass never turns into forty suggestions on a student's screen.

What does reach you is ranked: possibleReplacements lists every valid fix in descending order of relevance, so a suggestion card can show the best one and keep the alternatives behind a tap.

Requirement 3: the student makes the change

Auto-applied corrections teach nothing and, worse, blur authorship. The learning moment is the decision: seeing the issue, reading the reason, choosing the fix — or defending the original.

That has concrete design consequences for your editor integration:

  • Suggestions are offered, never applied silently. Accept and dismiss are both first-class actions.
  • Rejection is data. A student who dismisses "different than → different from" three times is telling your platform something a teacher would want to know.
  • Undo must be ordinary. An accepted suggestion is just an edit in the document history, reversible like any other.

The structured-edits model of a proofreading API supports this naturally: your UI receives ranges and replacements, and your application — not the API — decides when text changes. The architecture guide for editor integrations walks through the interaction details.

Requirement 4: student data is not training data

Schools, districts, and universities ask pointed questions about student writing, and regulations like FERPA and GDPR stand behind them. "We might train on your students' essays" ends procurement conversations.

The answers an education vendor needs from a proofreading API:

  • No training on submitted text. AmberPen does not use customer text to train models — full stop.
  • No retention by default. Submitted text isn't stored once the response is returned — on every plan, with no setting to remember.
  • No server-side copies. Incremental proofreading keeps the previous version of a document in the client's memory, inside your own application, so re-checking only what changed adds no retention on our side.

There's also an integrity angle worth naming in your product's marketing: a checker that corrects and explains — but never generates — sits on the right side of most academic-AI policies. You're giving feedback on the student's writing, not writing for them. That's a distinction teachers can defend.

Measure learning, not just corrections

Consumer checkers measure acceptance rate and call it a day. Education products can do better, because the goal is change over time, not a clean document:

  • Acceptance and dismissal rates by category — which error types does this cohort understand, and which do they blindly accept?
  • Error rates across drafts — is the same student making fewer article errors in week 8 than week 1?
  • Explanation engagement — do students expand the reason before accepting? If they never read it, your UI is hiding the most valuable part.

These signals are why the per-edit metadata matters: categories and explanations make every suggestion a measurable teaching event.

Where to start

The loop is small: one text field, one evaluate-mode request, suggestion cards that show the explanation before the fix. Everything above — category filters, ranked alternatives, dismissal analytics — layers onto that foundation as you learn what your students need.

The getting-started guide covers evaluate mode end to end, the testing guide explains the free test key (no paid plan required), and the SDK reference documents every field on the evaluated edit. Your students bring the drafts; bring feedback worthy of them.

If you're still evaluating providers, note that most of them don't return per-edit explanations at all — the grammar checker API comparison marks which ones do, and how grammar correction is measured explains why a checker's precision matters more for learners than for anyone else: a confident wrong correction doesn't just annoy a student, it teaches them something false.