Proof-of-Thought: Making Student Thinking Visible to Teachers

A grade comes in at 72 percent. That number tells a teacher almost nothing about how the student got there — whether they reasoned their way through and slipped on arithmetic, or guessed twice and got lucky, or quietly gave up and copied. The final artifact hides the process, and the process is the part a teacher actually needs to coach.

PDP Shikshya, built by pdpspectra, addresses this with a feature called Proof-of-Thought — telemetry that captures the learning journey as it happens inside the AI tutor and surfaces it on a teacher dashboard. This is a Data Platforms and Operational Automation story aimed squarely at educators: instrument the thinking, not the answer. (For the wider product tour, start with the platform overview.)

The signals: five kinds of thought event#

Every meaningful moment in a tutoring session is recorded as a small, typed event. In the data model these are ThoughtEvent rows, and each one carries a kind, a session_id, a student_id, and an optional detail. There are five kinds the dashboard cares about:

• attempt — the student engaged with the problem and pushed forward rather than stalling.
• hint_requested — the student leaned on the tutor for a nudge.
• struggle — the student signalled they were stuck.
• breakthrough — the student worked past a sticking point.
• escalation — the system decided the student needs a human, not more AI.

The crucial design choice is where these come from. They are not self-reported and they are not a quiz score. They are emitted automatically by the tutor as the conversation streams. When a student’s message trips a struggle marker — phrases like “I’m stuck”, “I don’t get it”, or the Nepali cues thaha chaina and garna sakina — the tutor logs a struggle event and increments a per-session struggle_streak. When the next message moves forward instead, the streak resets and an attempt is logged. The signal is a by-product of normal use, which is exactly why it stays honest.

The cognitive fingerprint#

Raw event counts are noisy, so the teacher dashboard rolls them into a single per-student number it calls the cognitive fingerprint. The formula is deliberately simple and legible — no black-box scoring:

It starts at a baseline of 60, rewards reasoning (each breakthrough adds 12, each attempt adds 4), and penalises over-reliance (each struggle subtracts 9, each hint subtracts 2). The result is clamped between 5 and 100. A student who attempts a lot and breaks through scores high; one who racks up struggles and hint requests trends down.

Two things make this trustworthy rather than gimmicky. First, the fingerprint is null until the student has actually done something — the dashboard zero-fills the entire class roster so a teacher sees every student, but it never invents a score for a learner who hasn’t started. Second, the weights are visible and opinionated: hint-leaning costs you a little, repeated struggling costs you more, and genuine reasoning is what moves the needle up. A teacher can look at the score and immediately understand why it is what it is.

Alongside the fingerprint, each roster row shows an engagement band — none, light, or deep, where “deep” means four or more substantive reasoning signals — and the student’s active subject, pulled from their most recent tutoring session. The dashboard also computes Class Cognition: live totals across the whole group so a teacher can read the room at a glance.

The escalation flag: routing humans, not just numbers#

The single most important column on the dashboard is needs_attention. It flips true when a student has any escalation on record, or when their struggle count reaches three. The roster is then sorted flagged-first, then by most-active, then alphabetically — so the students who need a teacher float to the top without anyone having to hunt.

This connects directly to Collaborative Trigger Routing inside the tutor: once a student’s struggle streak hits the escalation threshold, the session is marked escalated, an escalation thought event is written, and the tutor itself suggests bringing in a teacher or a peer. The platform’s stance is that an AI tutor should know when to stop being the answer and hand off to a person. Proof-of-Thought is how that hand-off becomes visible on the teacher’s side. (See the companion piece on the Socratic tutor and responsible learning for how the tutor decides to escalate.)

From a flagged row, the teacher has real actions, not just an alert. Opening a student’s profile drawer exposes the full event history — attempts, hints, struggles, breakthroughs, escalations — plus every tutoring session, an activity timeline, and the ability to leave feedback, generate an AI study-coach plan, or trigger an escalation action: route-to-review (logs a note and notifies the student and their parents that an in-person review is requested) or a peer study group (spins up a real group chat with the flagged students). Telemetry that ends in a human conversation is the whole point.

Visibility without surveillance creep#

The obvious risk with any system that watches students is that it slides into surveillance. PDP Shikshya draws the line in a few concrete places in the code, not in marketing copy.

Access is scoped by role and tenant. A teacher or department admin sees only their own department’s students; a tenant admin sees only their own school; data never crosses tenant boundaries. The telemetry endpoint refuses any caller who is not staff.

Students log only their own events. The event-recording endpoint rejects a student trying to write a thought event for anyone but themselves — there is no path for one student to pollute another’s record.

Parents see a different, gentler view. This is the part most platforms get wrong. A teacher is already responsible for assessing genuine work, so they see the named student and the granular journey. A parent, by deliberate design, sees only a wellbeing snapshot — subjects explored, active days, an engagement level. The per-attempt telemetry, the exact struggles, the escalation history, and the specific questions asked are teacher-only. The system treats “the adult responsible for teaching this child” and “the adult who loves this child” as different audiences with different needs, and gives each the view that fits.

The effect is that thinking becomes legible without becoming a panopticon. A teacher walks into class already knowing who quietly struggled with quadratics last night and who had a breakthrough on photosynthesis — and they know it from the work the students did anyway, not from a tracker bolted on top of it.

A worked example: what a Monday morning looks like#

Consider a science teacher with twelve students in their department. Over the weekend, the class used the tutor on a chapter about photosynthesis. On Monday the teacher opens the dashboard and, without reading a single chat transcript, can see the shape of the weekend at a glance.

Two students sit at the top, flagged. One hit three struggles in a single session and was escalated by the tutor; their fingerprint dropped into the low range because the struggle penalty outweighed their attempts. The teacher taps route-to-review, and both the student and their parents get a notification that an in-person review is coming. A second flagged student struggled repeatedly across two sessions but never escalated — the teacher pulls them and a third quiet learner into a peer study group chat and seeds it with a prompt to compare working.

Further down, a student shows a high fingerprint built on several attempts and two breakthroughs, with zero hint requests — exactly the reasoning profile the score is designed to reward. The teacher leaves a quick feedback note. Three students show none for engagement: they have not started, which is itself useful information for a Monday nudge. None of this required reading the underlying conversations; the telemetry compressed a weekend of twelve students’ thinking into a roster a teacher can act on in five minutes. That compression — many raw events into a few decisions — is the Operational Automation payoff.

Why this is an operational win, not just a pedagogical one#

For a school running PDP Shikshya as its school management system, Proof-of-Thought folds directly into the analytics and reporting layer. The same events feed department- and school-level rollups — breakthroughs, struggles, and escalations per student, “needs attention” flags, and a CSV export — so a head of department can spot a class that is collectively stuck on a topic, not just an individual.

This is what we mean when we say AI implementation in education has to be measured at the process layer. A test score is a lagging indicator. Attempts, hints, struggles, breakthroughs, and escalations are leading ones — captured automatically, scoped tightly, and turned into an action a human takes. That is the difference between a dashboard a teacher ignores and one that changes what happens in the room tomorrow.

---

Building learning analytics that surface thinking instead of just storing scores? We design Data Platforms and Operational Automation for education and beyond. Talk to our engineers at pdpspectra.com/#contact, or see Proof-of-Thought live at pdpshikshya.com.