Inspiration

Grading is the part of teaching that eats evenings. A class set of essays means reading the same rubric thirty times, and keeping scoring consistent from the first paper to the last is hard. Handwritten work adds another step: someone has to get it off the page before it can be reviewed at all.

The design goal behind Markwise: let AI draft the slow first pass, show the evidence behind every suggested score, and keep the final decision with the teacher.

What it does

Markwise is a grading assistant for paper classrooms, built around a teacher-approval step:

Teachers collect typed essays (paste or .txt upload) or photograph handwritten tests. A photo of the answer key turns each question into a rubric line.
The first pass suggests a score for every rubric criterion, each with a quote pulled from the paper, so the teacher reviews evidence rather than trusting a number.
The review queue surfaces drafts worth rechecking first: quotes the validator could not verify, weak evidence matches, and text in the paper aimed at the grader.
Scores can be edited and work sent back with revision notes. Approved grades flow into a gradebook with CSV export and a class heatmap showing where points were lost.
Students get a goal planner, returned feedback, streaks and XP. The gamification is engagement only; it does not change grades.
A /try sandbox grades a pasted paper with no sign-up, and the seeded demo class runs on labelled local demo engines with no API key.

How we built it

TypeScript end to end: Next.js 16 and React 19, server actions and API routes, Prisma over Postgres (Neon in production), deployed on Vercel.
AI routing lives in one module. Essays run on Claude; photos, briefs and the goal planner run on Claude or GPT-4o-class models depending on which key is configured; with no key, a deterministic demo engine takes over and is labelled on screen.
The approval gate is structural. The grader modules only write suggestions. A single publish function writes approved grades, and it re-reads the acting teacher, the class ownership, the approval state and every final score from the database inside one transaction, rolling back if anything fails to check out.
Every paid AI call goes through a usage guard that reserves the call's worst-case cost before sending, then enforces per-session and per-network hourly caps, a site-wide daily call cap, a daily dollar budget and a kill switch. Repeat reads of the same content are served from a cache instead of a new call.
The interface follows Google Classroom's layout and vocabulary, so teachers and students start from familiar ground.

Challenges we ran into

Trusting model output. A grader that invents a supporting quote is worse than no grader, so nothing the model returns is stored unvalidated. Scores outside a criterion's range are dropped, a quote is kept only if it can be located in the paper itself (the matcher ignores whitespace, letter case and quote style), otherwise the teacher sees "No supporting quote found," and text addressed to the grader is flagged and never kept as evidence.

Keeping AI spend predictable on a public demo. Pay-per-call models need guardrails before they need features. The usage guard prices each call at worst case up front and holds its caps in Postgres so they apply across server instances.

Handwriting without faking it. Photographed tests are two problems, transcription and scoring. With an API key the scanner reads photos against the answer key; without one it falls back to a clearly labelled demo path, and the photo stays beside the draft in review so the teacher can check the transcription.

Accomplishments that we're proud of

The approval gate is enforced in one server-side publish path, and the student view, gradebook and CSV export read from published grades, not grader output.
The recheck ordering is computed from stored validation data, with no extra AI call.
The /evidence page publishes real evaluation scaffolding: 30 public essays from the ELLIPSE corpus scored against human raters, with committed results for the demo grader. The live-model run is wired as a single confirmed, cost-capped command, not yet run.
The seeded demo runs on labelled local demo engines with no API key, so judges can try the workflow without keys or setup.

What we learned

With AI features, validation and containment belong in the design alongside the prompts, not after them. A dependable grading workflow needs output checks and a publish gate around the model call, cost controls built into the feature itself, and demo behavior labelled openly rather than left ambiguous.

What's next for Markwise

Real LMS integration (Canvas, Google Classroom) to replace the CSV stand-in.
Running the paid live-model evaluation against the human-scored ELLIPSE sample and publishing the numbers.
Real authentication to replace the one-click demo sign-in.