The Exam Generator Has No Question Bank

Every assessment system we have seen in maintenance training maintains a question bank: a corpus of hand-written items sitting alongside the courseware, usually in a different tool, usually owned by a different person. The bank starts out aligned with the content and then the content changes — a torque value is revised, a procedure gains a step, a part is superseded — and the bank quietly does not. From that day the exam tests the old content, and every revision has to be made twice or the assessment is wrong.

TaskFlight has no question bank. The exam generator reads the same part records the trainer renders — the symptoms, fault conditions, corrective actions, tooling lists and procedure steps that are already the product — and constructs questions from them at generation time.

Five question forms from one schema

• Symptom → part — a fault symptom drawn from a record; the candidate identifies which component produces it. Distractors are sibling parts from the same aircraft, so they are plausible rather than absurd.
• Fault → action — given a diagnosed condition, select the correct corrective action from the record against actions belonging to related faults.
• Part identification — designation, location and function drawn from the record’s descriptive fields.
• Procedure ordering — steps from a real removal or installation task, shuffled; the candidate restores the sequence. The steps are the procedure, verbatim.
• Tooling — which tools and consumables a given task requires, distractored with the tooling of neighbouring tasks.

Grading explanations come from the same records: a wrong answer is corrected by the authoritative text of the part entry itself, not by a paraphrase written for the exam. When a record is revised, the question, the right answer, the distractors and the explanation all revise with it, in the same commit.

Seeded, so a paper is a document

Generation is driven by a seeded PRNG. The seed fully determines the paper — which records were drawn, which forms, which distractors, in what order — so an instructor can replay any student’s exact exam from its seed, and a disputed question can be regenerated and inspected rather than argued about from memory. Randomised does not have to mean unaccountable. Papers can draw from a single airframe or a mixed fleet: the generator ranges over whatever slice of the catalogue is selected.

Validation moves to the content

Generating from records concentrates all the risk in one place: the records had better be right. So the build refuses to proceed until a content integrity check passes — every part id referenced by the 3D models resolves to a record and vice versa, step numbers are sequential, quiz answer indices are in range, ids are unique. npm run build runs the validator before Next.js ever starts, and a dedicated exam test suite exercises the generator itself. The invariant that makes the whole scheme trustworthy: content that fails validation cannot ship, and an exam can only be generated from shipped content.