The institutions that publish On-Screen Marking results on time, and the institutions that publish them three months late after a public controversy, are not separated by which platform they bought. They are separated by what they did in the seventy-two hours before the live evaluation window opened.
This is an operational checklist of the eleven things a conducting body should validate in a structured dry-rehearsal before its OSM window goes live. It is intended for examination controllers, registrars, and the small number of people inside a conducting body who actually own the operation.
We don't run On-Screen Marking. Our work is the OMR and result-processing side of an examination. But we sit close enough to OSM operations — often running the objective-paper half of the same cycle — to have watched which ones publish on time and which ones don't. This is what the difference looks like.
Why the dry-rehearsal is the most-skipped step in OSM
OSM, as a technology, works. The scanners read scripts correctly. The platforms distribute scripts to evaluators correctly. The marks files export correctly. None of this is mysterious anymore.
What does not work, predictably, is the operation around the technology. Evaluators who have spent twenty years marking on paper need practice on a screen. Marking schemes that read coherently on paper turn out to be ambiguous when annotated digitally. Centre-based evaluation hubs have network configurations that pass a basic ping test but fail under live load. Technical support teams that were "available" turn out to be reachable only during business hours.
A dry-rehearsal is the structured process of finding all of these before they affect live candidate scripts.
Most conducting bodies skip it. The platform vendor's contract typically does not require it. The conducting body's internal timeline is usually too compressed to fit it. The evaluator pool is paid per-script, so adding rehearsal scripts costs money. Each of these is a defensible reason individually. Together, they explain the majority of public OSM failures of the last three years.
The eleven checks — in the order they matter
Platform readiness
1. Can every approved evaluator log into the platform from the device they will actually use during the live window? Not "can they log in from a test device." From their actual device. About a quarter of OSM evaluators discover their browser is out of date, their two-factor token is misconfigured, or their institution's firewall blocks the platform — during the live window. The dry-rehearsal pulls these forward.
2. Has the conducting body's nominated officer been credentialled with read-only dashboard access, and can they actually see the data they need? The dashboard should show, at minimum: scripts allocated, scripts marked per evaluator, average time per script, flagged escalations. Confirm visibility before the window opens; do not discover during the window that the officer's account is in the wrong permission group.
3. Does the platform handle a multi-page script correctly under load — pages reassembled in order, no missing pages, no duplicate pages? Load test the platform with fifty real scripts of representative length. Have three evaluators mark in parallel. Watch for page-order corruption and duplicate-script delivery. Both are recoverable but only if they are caught.
Evaluator readiness
4. Has every evaluator marked a minimum of 50 practice scripts on the platform before the live window opens? 50 is a minimum. 100 is better. The evaluator who has marked zero practice scripts will spend the first 10 live scripts learning the platform interface — their marking quality on those 10 scripts will be unreliable.
5. Has the moderation sample tolerance been calibrated against the practice batch? Standard OSM workflow includes a moderator who second-reads a sample of every evaluator's marked scripts. The tolerance threshold (i.e. how much disagreement between marker and moderator triggers full-batch re-evaluation) needs to be calibrated against real evaluator behaviour. The practice batch is when to calibrate it — not during the live window.
6. Has every evaluator received a written briefing on the marking scheme, with worked examples for the three most ambiguous question types? Verbal briefings degrade in transmission. Written briefings can be referenced during the live window. The worked examples are what convert a marking scheme document into a marking action.
Marking scheme readiness
7. Has the marking scheme been pressure-tested against twenty real candidate responses, with two different markers, to confirm the scheme produces consistent marks? If two markers reading the same answer give different marks against the same scheme, the scheme is ambiguous, not the markers. Fix the scheme before the window opens. Most schemes have one or two ambiguous sub-questions that show up only under this pressure test.
8. Does the platform support annotation tools that match what the marking scheme requires? If the scheme requires markers to circle the candidate's reasoning step where they made an error, the platform's annotation tools need to support circling. Verify on the practice batch.
Operational readiness
9. Has technical support staffing been confirmed for the entire live window, including evenings and weekends? Live OSM windows often run 12–14 hours per day for 10+ working days. Technical support must be available the whole window — not a ticket queue with 24-hour SLA. Confirm staffing by name and shift.
10. Has a fall-back plan been agreed for platform downtime? Even good platforms have outages. The fall-back is not "stop marking." The fall-back is a documented protocol: who decides to pause, who notifies evaluators, how the lost time is recovered, who decides to resume. Agree the protocol with the platform vendor in the dry-rehearsal — not during the live window.
11. Has the result-publication date been recalculated against the dry-rehearsal data, not against the original contract estimate? Dry-rehearsal data tells you the actual evaluator throughput, the actual moderation rate, and the actual technical-support response time. These numbers may not match the contract estimate. If they don't, recalculate the result-publication date — publicly, before the window — rather than discovering halfway through the live window that the published date is no longer achievable.
What "going live without a dry-rehearsal" actually produces
If we read the past two years of public OSM controversies — board examinations whose results were delayed by months, university semester exams where individual marksheets had to be revised post-publication, recruitment exams whose evaluator pool produced inconsistent marks — the failure modes cluster around exactly these eleven items.
Specifically:
- Evaluators logging in for the first time on day one of the live window, discovering platform-side issues during marking
- Marking schemes ambiguous on real candidate scripts, evaluators applying them inconsistently
- Moderation tolerances calibrated against assumptions, not against actual evaluator behaviour
- Result-publication dates promised at contract stage, achievable only at evaluator throughput rates that the live window did not produce
None of these are platform bugs. All of them are operational omissions that a dry-rehearsal catches.
The cost of the dry-rehearsal
For a typical 1 lakh-script OSM operation with a 200-evaluator pool:
- 50 practice scripts × 200 evaluators = 10,000 practice scripts to source or generate
- 2 working days of evaluator time, paid at the same per-script rate as live
- Platform configuration time on the vendor side
- Coordination time on the conducting body's side
The total cost is real. It is also predictable, budgetable, and at least an order of magnitude smaller than the cost of recovering from a post-publication controversy.
The institutions whose OSM operations do not produce headlines have learned to budget for the dry-rehearsal at contract stage. Not to skip it because the timeline is tight.
What to expect from your OSM vendor
A serious OSM vendor will:
- Include the dry-rehearsal as a standard line item — not an optional add-on
- Refuse to run a live window without one
- Supply the readiness checks (evaluator, marking-scheme, platform load) as part of the contract
- Sign off on the publication date only after the rehearsal data is in
If yours won't do those four things, you are buying a platform, not an operation.
About ParikshaXpert
ParikshaXpert is the examination services unit of Booknerd Publication LLP. We handle question paper printing, answer sheet supply, OMR scanning and result processing — with a CBT platform in development — for IITs, central universities, examination boards and government PSUs. New Delhi · ISO 9001:2015 · CMMI Level 3 · DPIIT Startup India · UPDESCO + UPTRON empanelled.
We don't sell OSM, so there's nothing to pitch here. If you're planning an OSM cycle and want a second opinion on your dry-rehearsal protocol from someone who runs high-volume examination operations, the call is free — +91 72499 90299 or vp.sales@booknerdpublication.com. And if the same cycle has an objective paper that needs OMR printing, scanning or result processing, that part we do.