An answer key that comes out wrong after a PDF extraction is almost never random. It is one of four failures, and each leaves its own signature: the key page was never read, so the answers are null; the wrong set column was used, so almost every answer is wrong; a printed label was carried across as an index, so every answer sits one option low; or the question is a numeric or match-the-column item the import format cannot hold, and its null is deliberate. Work out which signature you have before you fix anything. Three of the four are repaired by re-running the key alone, and the fourth is not a fault.
This is the troubleshooting pass after an import. Converting a question paper into import-ready JSON covers the extraction run itself, and the JSON upload guide carries the prompt and the repair prompts described below. The in-app "Import from PDF" button, where MockSetu runs the extraction server-side, is off by default and granted per creator on request; the universal route is the published prompt plus a JSON upload. Both run the same prompt and fail the same four ways.
Missing Answers Are Loud, Wrong Answers Are Silent
MockSetu checks whether an answer exists. It never checks whether the answer is right, because it has no way to know. A question with nothing marked gets a red border and an alert badge on its row in the editor, and at publish time the language holding it is listed with its question numbers and a "Go fix" link straight to the row - that language's toggle is disabled until the key is filled. The gate runs on every language you publish, not only the primary, so a Hindi twin with an empty key is caught too.
An off-by-one produces none of that. It writes an index that is an integer, inside the option range, and non-empty. Every check in the product passes it. The first reader to notice is a student comparing the score report against the official key.
A missing answer is loud - a red badge in the editor and a publish gate that will not open. A wrong answer is silent all the way to the student's score report.
Failure One: the Key Page Was Never Read
Signature: everything null, or whole sections null, with no complaint about any one question. Cause: exam papers print the key at the end - after the questions, after the rough-work pages, inside a solutions booklet - and a model reading front to back reaches it only after it has written every question down.
The current prompt attacks this directly: read the whole PDF last pages first, then transcribe the key verbatim into the extraction summary's answer_key block before writing a single question, so the model reads its own transcript instead of recalling a page it saw once. If your JSON came from an older prompt, re-run it with the current one. Then read answer_key. Found says whether a key exists anywhere in the PDF, and transcript should hold one token per question. Empty transcript with found false means the PDF has no key, no inline answers, no solutions and no marked options. Empty with found true means the key was located and could not be joined - the next failure.
Failure Two: the Wrong Column, or the Wrong Row
Keys for papers issued in multiple booklets carry one column per set - Set A to D, Series, Booklet Code, Shift 1 and Shift 2. The columns differ because the question order differs per booklet. Taking the leftmost by habit marks a wrong answer on nearly every question, and the result looks perfect: nothing null, nothing flagged, every question confidently answered. Nothing in the product flags it.
Check answer_key.set_used against the set printed on your paper's cover or running header. The prompt forbids defaulting to column one: when the paper's set is not printed or is not among the key's columns, the correct outcome is every answer null plus one paper-level review entry saying so. A wall of nulls beats a wall of plausible wrong answers, so do not read it as the extraction failing you.
The same fault hits rows. If the key numbers questions continuously while your exam is built as sections that each restart at 1, the second section's printed Q1 is not the key's entry 1 - it sits after every question of the first section. Build SSC MTS as two sections for its two 45-minute sessions, 90 questions and 270 marks, and that offset is waiting for you.
Failure Three: a Printed (3) Is Index 2
The importer's correct_answer is a zero-based index into the options array. First option "0", second "1", third "2", fourth "3", fifth "4". A printed digit on a key is a label, never an index - a key entry of (3) becomes "2", and (1) becomes "0". Letters map the same way by position: (a) is "0" whatever the paper's own options are labelled. Never search the options for the label's text.
The first signature is obvious once you look: every answer sits one option further down than the printed key says. The second is the one creators miss - questions going missing. If the key prints (4) on a four-option question and the conversion wrote "4", that index is out of range and the parser rejects the whole question rather than importing it wrong. It never reaches the editor at all. So a section that imported short is worth re-reading as a conversion error before you blame the PDF. The same rejection catches a letter, "Option 3" or "Bonus" in that field; a blank is treated as not marked, which keeps the question and loses the answer.
Failure Four: the Nulls That Are Supposed to Be There
The importer does not carry numeric, TITA and match-the-column questions. They arrive as placeholders - two sentinel options naming the manual entry needed and the PDF question to look at - and the import preview warns about each one. Their correct_answer stays null even when the PDF prints the answer, and that is deliberate: any index there would tick one of the two placeholder strings. The printed value rides in the review reason instead, so you can finish the question without reopening the file.
Do not re-run the extraction to fix these. Nothing will change. Open each one in the editor, replace the sentinel options with the real ones, and mark the real answer.
Reading the Rate, Then Auditing by Hand
The extraction summary reports its own coverage: answered counts the ordinary questions given a real index, left_null counts those it could not answer, and each of those carries a reason starting "answer key" quoting what the PDF printed. The import preview shows that list as "AI-flagged for review" and says those questions will still be created. What the rate means is worth being precise about.
- Almost everything null: the key was missed or could not be joined. Read answer_key.note and the single paper-level review entry first - it names the reason.
- A scattered handful null, each with its own reason: healthy. Those are genuine ambiguities - a question marked Bonus or dropped, a key accepting two options, an illegible glyph in a scan - and they are meant to be finished by hand.
- Nothing null at all on a scanned or messy paper: a warning, not a win. A model that found an answer for every single question may have solved some instead of transcribing them, which the prompt forbids.
- Everything answered and the answers wrong: no count shows you this. Only the audit below will.
Do the audit with the key page of the PDF open beside the editor.
- Take the first question, a middle one and the last one of every section. A wrong column is wrong everywhere; a numbering offset shows itself at the ends.
- For each, read the printed label on the key, count the options down from the top of the question, and confirm the editor marks that same option.
- Include one question whose printed answer is the last option. A conversion error there goes out of range, so the symptom is a deleted question, not a wrong one.
- Count each section against the PDF. A short section is a conversion error, not a reading error.
- Solve three questions yourself and compare. This is the only check that catches a key that is internally consistent and belongs to a different booklet.
Fixing It Without Starting Over
Three repair routes, cheapest first. The upload guide ships a missing-answers fix prompt: paste it into the same chat that produced the JSON, paste the JSON under it, and the model re-reads the key and re-emits the file with questions, options, sections, passages and marks untouched. For a handful of questions, skip that and fix them in the editor - expand the question and edit the correct answer inline. On a bilingual paper that save writes the same index to every language twin, because the answer is a position and positions are shared.
The third route is a fresh import in Replace mode, and it has a deadline. Once a student has submitted an attempt in that language, Replace is refused and only Append is offered. That is the argument for auditing before you share the link: scores are worked out when a paper is submitted and stored on that attempt, so a correction changes what the next student scores, never what the earlier ones scored. If you are already past that point, correcting an answer key after students have attempted covers what is still recoverable.
Why Previous-Year Papers Punish This Hardest
A key error on a paper you wrote yourself stays between you and your batch. A key error on a previous-year paper built as a mock test is public knowledge: the official key exists, serious candidates have already seen it, and the first mismatch costs you the credibility that made them attempt the paper at all.
Be clear-eyed about the blast radius. Published papers on MockSetu are public - anyone with the link can attempt them, there is no private or paid delivery to one batch, and there is no proctoring of any kind. There is no CSV or Excel export of results and no per-student report card, so you cannot quietly re-issue corrected scores to a list. The audit before publishing is the control you have.
MockSetu is free and takes no card. Everything a creator can build - sections with their own clocks, bilingual papers, a marking scheme per question, a listing in the public library - sits behind one account. Spend the extra pass on the key. It is the one part of the paper a student can check against an official document.