The exam stays on paper.The marking does not.
How 11+ Connect Hub - the platform behind Focused Mentoring’s mock exams - got computer vision to read photographed paper answer sheets - two independent detection pipelines, the same sheet read more than once, and a system that would rather return nothing than invent an answer on a child’s exam paper. Plus the feature that turned the same discipline inward and audited the platform’sown 34,678-question bank.
The situation
A meaningful share of Focused Mentoring’s revenue comes from offline mock exams. Children sit real papers at booked physical centres across Orpington, Kent and Bexley, under timed conditions, exactly as they will in the actual 11-plus. That authenticity is the product - a mock exam taken on a laptop at the kitchen table is not the thing being sold.
It is also the bottleneck. Every child leaves behind a paper answer sheet carrying 35 to 75 bubble rows, and until those rows exist in the database, nothing downstream can run: no analytics, no report to the parent, no weak-area breakdown, no practice recommendation. A sitting of 200 children produces 200 sheets, each needing dozens of transcriptions, in the narrow window where parents are waiting for results. Manual entry is slow, error-prone, and scales linearly with the business - every new centre is more typing.
The authenticity is the product. It is also the reason 200 answer sheets have to become database rows before anyone can be told how their child did.
What we built
Rather than betting on one approach, we built two complete detection pipelines and use each where it is strong. The first is geometric: a calibrated template expresses every bubble position as a percentage of image width and height, so the layout survives resizing, and ink density is sampled inside each option box. It is free, fast and works entirely offline - but it assumes a known sheet, reasonably flat and reasonably lit. The second sends the photograph to a multimodal vision model with a long instructional prompt and gets structured JSON back. That one survives skew, shadow, phone-camera noise and, critically, layouts it has never seen, because identifying the sheet’s structure is part of what it is asked to do.
The decision that matters most is what happens when the system is unsure. The guiding instruction appears verbatim in two places in the vision prompt: an invented wrong answer is far worse than a null. That is the correct calibration for a child’s exam paper, and it is enforced structurally rather than merely requested - confidence bands are specified, anything below 0.5 returns nothing instead of a guess, and the default is explicitly "not detected". Three levels of fallback sit behind it, because the failure mode of this feature is a child’s exam result being wrong.
Inside the system
What runs in production, and what keeps each part of it honest.
Reading the sheet
- Geometric pipeline: calibrated percentage grid, adaptive thresholding, ink sampled per option box
- Vision pipeline: multimodal model returns structured JSON, robust to skew, shadow and unknown layouts
- Sampling boxes narrower than the printed cell, so a strike-through overrunning its box does not bleed into its neighbour
- Ink read as the strongest vertical stripe rather than a flat rectangle mean, because the expected mark is a pen stroke
- A median baseline subtracted per row, so a grey-tinted row does not read as ink
- Fallback from WASM to plain canvas grayscale if the module fails to load
Reading it more than once
- N independent vision passes at deliberately varied temperatures, merged by per-letter majority vote
- A genuine pen stroke is stable across temperature variation; a hallucinated one is not
- Disagreement treated as signal and converted into a confidence score, not discarded
- Voting per letter rather than per row, so a real multi-select answer returns both letters instead of collapsing to "ambiguous"
- Rows where the passes disagreed are flagged for review rather than resolved silently
The prompt as written-down expertise
- Calibrate against the worked example row printed at the top of the sheet
- Printed letters and their brackets are part of the blank form, not marks
- Grey bands behind alternate rows are background tint, not pen strokes
- Ignore bleed-through from the reverse of the page, paper grain, dust and ruled lines
- A smudge beside a clear stroke is a smudge; a struck-then-crossed-out answer is a multi-mark for review
- Kent and GL mock sheets print an N column last - never map N to D or E
From pixels to a marked exam
- Handwritten names fuzzy-matched against the children actually booked onto that exam
- Detected letters mapped onto the exam’s real question and answer model
- Responses written through the same grading path a child’s online submission uses
- An operator reviews an overlay showing exactly what the system saw, before anything is submitted
The platform auditing itself
- The model solves each question independently first, and only then compares with the stored answer
- Five separate verdicts: answer, explanation, question quality, grammar and difficulty
- Difficulty calibrated to the domain - "beyond the 11+ curriculum", not merely "hard"
- Every axis carries a CANNOT_VERIFY option, so an image-based question is labelled rather than guessed at
- Nothing reaches the live bank without an admin approving it: pending review, approved, applied
- A dry-run preview reports what will update, skip and block before anything is written
The one feature children see directly
- A short story generated from the child’s own vocabulary list, with blanks and multiple-choice options
- Every sentence written so only one word from the list reads as clearly correct
- Wrong options drawn only from the child’s own assigned words - no invented vocabulary
- Near-matches banned: no synonyms, softer variants or confusable opposites as distractors
- Output validated in code before display - blank count, numbering, answer membership, option sourcing
- On validation failure the system retries rather than degrading the exercise
What changed
A photograph replaces the typing
A sheet of 35 to 75 rows is read from a phone photograph rather than transcribed by hand. The operator’s job changes from typing every row to confirming an overlay that shows what was detected, row by row, with a confidence on each.
The system says when it does not know
Below the confidence threshold it returns nothing and flags the row. Multi-pass consensus catches the cases where the passes disagreed. Both routes end at a human, which is the only acceptable destination for an uncertain answer on a child’s exam paper.
The question bank got audited against itself
34,678 questions across 331 subtopics, each carrying a human-written answer key and explanation. Roughly 1,647 had been flagged by users through support tickets - enough to know the problem was real, not enough to know its size. Reading them by hand was never a plan.
Cheap models over everything, premium on the disagreements
We modelled token counts from the real data and priced the full bank across seven models from three providers before committing to any of them. The result is a three-phase cascade: a free-tier sweep over the user-flagged questions first, then the whole bank on a low-cost model, then a premium second opinion on only the ~5% that came back wrong or ambiguous. Verification is cheap and adjudication is expensive, so you run the cheap model over everything and the expensive one over the disagreements - and an ongoing nightly review of newly added questions stays inside the free tier permanently.
The model is kept out of the scoring loop
No AI grades a child’s written work and no AI awards effort points. Marking is deterministic or human; rewards are computed by database triggers on real activity. For a product whose output is a child’s assessed progress and a parent’s purchasing decision, that is the right line to draw.
Three features deliberately use no AI API at all
For low-volume admin work done a few times a week, the application generates a paste-ready prompt for a free external chatbot instead. Building API integrations there would add key management, error handling, cost and three more failure modes to automate work someone is already sitting in front of. Knowing which tasks should not be integrated is part of the job.
How it was built
React and Supabase carry the platform. The question auditor runs server-side in a Supabase edge function and checks the caller holds an admin role before it does anything. Model selection is reasoned from the task rather than from a leaderboard - the vision path leads with a model strong on fine detail and fast enough that multi-pass consensus stays responsive, while the bulk auditor leads with models whose free-tier quota pools survive a run across tens of thousands of questions.
Other systems we have built near this one
Is something in your process still being typed in from paper?
Answer sheets, delivery notes, inspection forms, meter readings - anywhere a person reads a page and types what it says into a system, and everything downstream waits for them to finish. Tell us what the paper looks like and how much of it there is, and we will tell you honestly which part a machine can read, and which part still needs a human to sign off.