The Analog Handshake: Checking Handwritten Work Without Storing It

There is a quiet fear running underneath every conversation about AI in schools: that the moment a student can photograph a problem and get a finished answer, the actual work — the pencil-on-paper grind of reasoning through it — disappears. Teachers do not just want the right answer in the box. They want evidence the student did the thinking. And that thinking still happens, overwhelmingly, on paper.

PDP Shikshya, built by pdpspectra, bridges that paper-to-screen gap with a feature called the Analog Handshake: a student photographs their handwritten working, a vision model confirms it shows genuine step-by-step reasoning, and the platform awards points for the process. The twist that makes it safe to deploy in a school full of minors is that the photo is never stored. (For the wider picture of how the platform defends real learning, see the overview post.)

What the handshake actually checks#

The Analog Handshake lives behind the tutor’s camera button. A student finishes working a problem in their notebook, taps the camera, and uploads a photo. On the backend, the request hits a single endpoint that does one focused job: verify the image with a vision-capable model and report what it found.

The model is given a tight brief. It is told to set verified=true only when the image clearly shows genuine handwritten problem-solving — equations being worked through, steps, diagrams, or written reasoning. It is told to set verified=false for a blank or near-blank page, for printed or typed text, for a screenshot, for an unrelated photo, or for a bare final answer copied down with no working shown. That last case is the important one: a lone “x = 7” with nothing above it does not pass. The handshake is specifically engineered to reject the copied-answer shortcut.

The response is structured, not free text. The vision call returns three fields:

• verified — a boolean: did this show real hand-worked reasoning?
• steps_found — an integer count of the distinct handwritten reasoning steps it could see.
• summary — one plain sentence describing what the working shows, or why it failed.

That steps_found count is what turns a yes/no gate into something a teacher and student can talk about. “The model saw four distinct steps” is a far more useful signal than a thumbs-up.

Structured output, not prose to parse#

A detail worth dwelling on, because it is where a lot of vision integrations go wrong: the handshake does not ask the model for a paragraph and then try to grep a verdict out of it. The verification call requests a typed result — a small schema with the verified boolean, the steps_found integer, and the one-line summary — and the model is constrained to return exactly those fields. The application code receives a clean object it can branch on immediately. There is no brittle string-matching, no “did it say yes or no” ambiguity, and no risk that a chatty model buries the decision in hedging. The vision model’s only job is to look at the page and fill in three blanks.

That discipline also keeps the feature cheap and fast. The call is capped at a small token budget — it does not need to write an essay, just a verdict — so a handshake resolves quickly enough to feel like a scan, and the cost per check stays low even across a whole class.

Rewarding the process, not the artifact#

When the check passes, the student is awarded process points — a fixed bonus that flows into their points total and shows up on the class leaderboard. This is a deliberate inversion of the usual incentive. Most software rewards the finished, correct output. The Analog Handshake rewards the fact that you reasoned by hand at all, regardless of whether the final answer was right.

That design choice matters because it removes the motive to cheat the system. There is nothing to gain by photographing someone else’s clean final answer — the model rejects work with no steps. The only way to earn the points is to actually fill a page with your own working. The reward and the desired behaviour point in the same direction, which is the whole game in responsible-learning design.

Each verification is recorded as a lightweight row — the student, the subject and topic, whether it verified, the step count, the one-line summary, and the points awarded. Note what is not in that row: the image. The record is metadata about the check, not the check’s input.

The no-storage guarantee, in the code#

Privacy-by-design is easy to claim and hard to verify. Here it is concrete and checkable.

When the photo arrives, the endpoint reads the image bytes into memory, base64-encodes them, and passes them straight to the verification call. The raw bytes exist only for the duration of that one request. They are never written to a file, never persisted to a database blob, never cached to disk. When the request ends, they are gone.

A few guardrails surround that core promise. The upload must be an image content type, or it is rejected. Oversized uploads are refused before they are read into memory at all — there is a hard 25 MB ceiling, checked first against the declared size and then again against the actual bytes, so the service cannot be flooded. And the daily AI budget is enforced before the vision call runs, so the feature can never quietly run up cost.

Equally important is what the model receives. The vision call is sent only the image bytes plus the subject and topic — no student name, no roll number, no email, none of the PII that the platform’s edge anonymizer scrubs from every other model request. There is simply no identifying text attached to a child’s handwritten page. The model sees a photo of working for “Chemistry, chemical bonding” and nothing that ties it to a person.

Designing for the moment it fails#

A vision check that has to refuse work needs to fail gracefully, because students will sometimes upload the wrong thing — a blurry shot, a half-empty page, the printed question instead of their working. The handshake handles each case without drama.

If the model can genuinely see only a final answer with no steps, the result is an honest false with a steps_found of zero and a one-sentence summary explaining what was missing — feedback the student can act on by going back and showing their working, not a dead end. If the upload is not an image at all, or is empty, the endpoint rejects it with a clear message before any model call. And if the vision call itself fails — a provider hiccup, a timeout — the endpoint returns a plain “couldn’t verify the photo right now, please try again” rather than awarding points on a guess or leaving the student staring at a spinner. A verified handshake is the only path that touches the points total; every uncertain or failed case defaults to no award, which is the safe direction for a feature whose whole purpose is trust.

Why this is the right shape for AI in education#

The Analog Handshake is a small feature with an outsized point to make about AI implementation in schools. The reflexive worry is that AI dissolves real work. This is the opposite: the platform uses AI to defend real work, to insist on the pencil-and-paper part, and to celebrate it. The camera does not replace the notebook — it validates it.

It also models a privacy posture that scales. Schools handling minors’ data cannot treat every photo as a forever-asset to be warehoused. The handshake shows there is a middle path: use a powerful vision model for the thirty seconds you need it, extract a structured verdict and a step count, store that, and let the image evaporate. The school gets the signal it wants — proof the student did the thinking — without taking on the liability of a photo archive of children’s homework.

There is a workflow point underneath the privacy one, too. The handshake meets students where the work already is. It does not ask them to retype their working into a text box, photograph it into a permanent submission folder, or change how they study at all. They solve the problem the way they always have — on paper — and the camera simply confirms it. The friction is close to zero, which is why a feature like this gets used rather than avoided. Good privacy design and good adoption usually pull against each other; here they point the same way, because the thing that makes it private (the photo never lands anywhere) is also the thing that makes it light to use (there is nothing to manage afterward).

For a school running PDP Shikshya as its management platform, that combination — a verifiable bridge between analog and digital work, plus a no-storage guarantee that holds up to inspection — is what makes a feature like this deployable, not just demoable.

---

Want to build vision features that respect privacy by design — process them, score them, and never warehouse the input? Our engineers do exactly this kind of AI implementation. Reach us at pdpspectra.com/#contact, or try the Analog Handshake at pdpshikshya.com.