Worked example: pair questions and answers reliably
A question paper and a key can look alike, have familiar names and still belong to different revisions. Reliable pairing needs four separate checks: identity, version, item coverage and answer correctness. A checksum adds an integrity check, but cannot decide whether an answer actually solves a question.
The supplied PAIR-DEMO files make those distinctions testable. They are original, tiny teaching fixtures, not real examination papers. Each of two versions of MEASURE-A has three questions and three answers, available as structured JSON and readable TXT. The package also includes an exact renamed copy and an explicitly labelled invalid stale key for inspection.
Prepared example companions: the fixture guide, pairing cases, actual checksum manifest and question-version crosswalk are prepared for this example. Their local paths identify the supplied files for offline review; website hosting and access are pending verification.
Read the identifiers before the filename
Collection ID PAIR-DEMO identifies this demonstration. Paper ID MEASURE-A identifies the particular question set. Paper version identifies the whole revision. Question IDs Q01, Q02 and Q03 remain stable across revisions, while a content-version field records whether the individual question changed. “Q01” alone is therefore not a complete identity: many papers can have a first question.
Questions and answers carry the same collection and paper IDs but different roles. The answer file additionally states which question-paper version it supports. These are explicit declarations that still need checking against content. A file called final-answers.json is not stronger evidence than those declarations merely because its filename sounds decisive.
| Item | Version 1.0 | Version 2.0 | Content versions |
|---|---|---|---|
| Q01 | 48 cm ribbon; remove 19 cm. Remainder: 48 − 19 = 29 cm. | 48 cm ribbon; remove 17 cm. Remainder: 48 − 17 = 31 cm. | 1 becomes 2 |
| Q02 | Three boxes, six counters each. Total: 3 × 6 = 18 counters. | Same question and answer: 18 counters. | Remains 1 |
| Q03 | Convert 2 km to metres: 2 × 1,000 = 2,000 m. | Convert 2.5 km to metres: 2.5 × 1,000 = 2,500 m. | 1 becomes 2 |
The CSV and JSON question-version crosswalks record all six item/version combinations, the full prompt, its correct answer and the exact question and answer file paths. They let a reviewer distinguish an unchanged item inside a changed paper from a changed item that retained its ID.
A completed four-check record
| Check | Evidence and decision |
|---|---|
| Identity | Both declare PAIR-DEMO and MEASURE-A; roles are questions and answers. Pass. |
| Version | Both declare paper version 2.0; key matches question version 2.0. Item content versions are 2, 1 and 2. Pass. |
| Coverage | Each contains exactly Q01, Q02 and Q03 once. No missing, repeated or extra item. Pass. |
| Correctness | Independent calculations give 31 cm, 18 counters and 2,500 m. These agree with the key’s values and working. Pass. |
Coverage means more than equal item counts. A key listing Q01, Q01 and Q03 has three entries but omits Q02 and repeats Q01. Compare the actual IDs, then check uniqueness and any subparts. If a task is deleted or added, explain the change rather than quietly assuming the old numbering still works.
Worked case 1: a wrong-version pairing
Case C2 in pairing-cases.csv deliberately pairs MEASURE-A v2.0 questions with the v1.0 answers. Collection and paper identity agree. Version fails. Item IDs appear complete, but the content crosswalk shows changes to Q01 and Q03. Solving the new questions gives 31 cm and 2,500 m, while the old key gives 29 cm and 2,000 m.
Reject the pair and select the actual v2.0 answer file. Recheck all three items, including unchanged Q02, then record the corrected selection as case C5. Keep the deliberate wrong case visibly labelled so it cannot be mistaken for an approved distribution record. Correcting a pairing is a change to which files are used, not a reason to rewrite the old key as though it had always contained the new answers.
Worked case 2: changed questions, unchanged key
Case C3 is more subtle. INTENTIONALLY-WRONG-stale-key-labelled-v2.json says version 2.0 at the top but preserves the old item content versions and old answers. This models relabelling a file without updating its substance. The identity and top-level version labels appear to pass, and all three IDs are present.
The item-level check fails at Q01 and Q03: the new questions have content version 2, while the stale answers refer to content version 1. Independent arithmetic fails too. The key’s 29 cm plus the newly removed 17 cm totals only 46 cm, not the original 48 cm. Its 2,000 m represents 2 km, not 2.5 km. A trustworthy-looking label cannot resolve those contradictions.
Worked case 3: a harmless rename
Case C4 uses renamed-current-questions.json with the v2.0 key. The renamed file is an exact byte-for-byte copy of the correct v2.0 question JSON. Its SHA256 equals the original’s recorded value. Its internal identity, version, item list and mathematical content therefore remain the same for this demonstration.
Accept this pair after the same checks. Update the location in the catalogue if that renamed copy is the one to distribute. The filename changed; the content version did not. This is why stable identifiers should not depend entirely on a particular path.
Use checksums for their actual purpose
file-manifest.csv and file-manifest.json contain the real byte size and SHA256 of each of the ten fixture files. The two manifests describe the same file records. SHA256 values were calculated from the delivered bytes, including punctuation, spacing and line endings. The intentionally invalid key also has a perfectly legitimate hash.
A later hash match means the checked file agrees with that recorded byte reference. It does not prove the reference was correct, authorised, complete or paired with the right paper. A harmless formatting export may change the hash without changing a mathematical answer; a byte-identical wrong answer remains wrong. Preserve the original manifest, record a new revision after genuine changes and repeat semantic checks.
The National Archives guidance on digital-file preservation supports recording initial checksums and comparing them later. The collection IDs, question-version rules and pairing decisions in this example are an original teaching method.
Three independent matching tasks with answers
Task 1: the count agrees but coverage fails
A separate practice key for a paper with Q01, Q02 and Q03 lists Q01, Q01 and Q03. Both contain three entries. Can they be accepted?
Answer: no. Q02 is absent and Q01 is duplicated. Confirm which answer was mislabelled or omitted from the actual content, repair the correct record and repeat coverage and correctness checks. Do not merely rename the second Q01 to Q02 without inspecting its solution.
Task 2: identical version, different paper
A question file declares PAIR-DEMO, MEASURE-A, version 2.0. A key declares PAIR-DEMO, MEASURE-B, version 2.0. Its first answer happens to be 31 cm. Is that sufficient?
Answer: no. Paper identity differs. One coincidentally matching answer cannot establish the intended partner or full coverage. Find the MEASURE-A v2.0 key and inspect it. This practice description does not assert that a MEASURE-B file is supplied.
Task 3: a hash changes after export
The valid v2.0 JSON is exported with different indentation. The new SHA256 differs, but the parsed identities, prompts and answers appear unchanged. Must the new file be mathematically wrong?
Answer: no. The changed hash establishes a byte change, not its meaning. Retain the original reference, inspect the export, compare all IDs and content, open the actual result, and record a new file-level checksum after checking. A format-only change need not create a new question content version, but should not be hidden in the file record.
Frequently asked questions
Can a checksum prove that a key is correct?
No. It identifies bytes relative to a reference. Correctness requires solving the questions and comparing the actual answers.
Must unchanged questions receive new content versions?
Not in this model. Q02 keeps content version 1 inside paper version 2.0 because its prompt and answer are unchanged.
Is matching the paper title enough?
No. Titles can be reused. Check collection, paper, revision, item coverage and solutions.
Should I delete the old version immediately?
Do not silently erase the history. Keep a clearly separated record when needed, and distribute only the intended checked pair.
Why provide readable TXT and structured JSON?
TXT makes the tiny fixtures easy to inspect; JSON carries explicit fields for deterministic checks. Their different bytes need different hashes.
Does a rename alter the hash?
Changing only the filename does not change the file bytes. This package includes an exact renamed JSON copy to demonstrate that case.
Does this check validate existing member papers?
No. It validates only the supplied original fixtures. Other papers and keys require inspection of their own actual files and access conditions.
WhatsApp Us Now