Why QuizPilot is not an AI wrapper

Every document takes the shortest path that produces a correct result. It is read according to its file type, checked for whether it already contains questions, and classified by content type, because a physics sheet needs different formatting rules than a history quiz.

Then the deterministic parser cascade runs. Eleven format parsers try in order, and the first one that matches cleanly wins, with no model involved. If none fit, the document falls through to progressively more capable and more expensive stages: a structure parse that asks the model only to pick the correct option, then full extraction over chunks split at question boundaries, and finally a vision model for pages that are scanned or garbled. Most documents never reach that far.

This is the part the word wrapper gets wrong. The model in QuizPilot has a small, bounded job. It reads the options out of a chunk of text, or in the structure-parse stage it does only one thing: pick which option is correct. It does not decide where one question ends and the next begins, which answers are duplicates, or whether the result is good enough to ship. Deterministic code owns all of that, along with file extraction, detection, segmentation, validation, de-duplication, answer shuffling, caching, and metrics.

The result is measurable. About one in three real uploads is turned into a quiz with no extraction-model call at all, parsed end to end by the deterministic cascade. For the rest, the model is one bounded step inside a pipeline that checks its work, not the pipeline itself.

When the model is needed, the primary extractor is Gemini 2.5 Flash-Lite, with automatic failover to a second provider if it is rate-limited or refuses, and a separate vision model for scanned pages. The interesting engineering is not which model we call. It is how little we ask it to do. A smaller job is cheaper, faster, and has less room to go wrong.

A few real examples make the point. Inside a single document, question numbering is rarely consistent. One question reads 1. with a space after the dot, the next reads 2.Question glued straight to its text. A naive parser silently folds the glued one into the question above it, and you lose a question without ever knowing it was there.

Symbols are overloaded. A hash can be a question number, a correct-answer marker, or a delimiter, depending on context, and the marker for a correct answer changes by region and format. It might be a star, a plus, an equals sign, a hash, a check mark, or the words for correct answer spelled out. The same character has to be read three different ways on three different lines, which a single fixed rule cannot do and a careful cascade can.

Spreadsheets drift. An exam bank fills the subject column on the first row of a block and leaves it blank below, so a later row lines up against the wrong column and a correct answer gets marked wrong. That is invisible to a model reading cell by cell, and caught by code that knows the shape of the sheet. Each of these was a real bug, found in a real document, and each is now a permanent regression test so it cannot come back.

That single rule explains the entire verification layer. Before a quiz ships, every question is checked. It must have real options, not placeholders or empties. The options must be unique. The correct index must point to an option that exists, with an automatic fix for the common case of a model counting from one instead of zero. Questions with too few options, or a structure parse the model is unsure about, are dropped rather than guessed.

The assembled quiz is de-duplicated by a normalized signature, answer positions are shuffled so the correct choice is not always in the same place, and a failed or partial extraction is never cached, so a bad run cannot poison later ones. A coverage gate stops a handful of stray markers in a long document from hijacking the whole parse. And if a paying user ever loses more than a small fraction of their expected questions, an alert is raised automatically, so we hear about a bad document before they have to tell us.

Getting there took the kind of work that never shows up in a demo. A boundary-first splitter that respects where questions actually start cut mid-question breaks by 18 percent and reduced model calls by 13 percent. Teaching it to handle glued and hash-numbered questions cut those breaks by a further 33 percent.

The deterministic share is not frozen. It grows through a repeatable loop: capture the new document formats real users upload, find the ones the parsers miss, build and adversarially test a new parser against real files, and ship it. Every pass widens the set of documents handled with no AI at all. A wrapper is only ever as good as its model is this week. This gets better on its own schedule.

It is also built for a specific reality. Central Asian exam banks have their own conventions: tickets, mixed Cyrillic, Latin, and Turkic scripts, region-specific answer markers. A generic document-to-quiz tool faceplants on them. QuizPilot was shaped against thousands of these real documents, which is a moat that has little to do with the model and everything to do with the years of formats it has already learned to read.

None of this means QuizPilot avoids AI. It uses it, deliberately and narrowly, for the judgments a model is good at, with deterministic code doing everything around it and checking the result. The honest claim is not that the output is perfect. It is that answers on the deterministic path are traced to a marker in the source rather than inferred, and the model path is bounded and validated rather than trusted on faith.

Put together, the surgical use of AI, the regional formats, and a process that compounds are far harder to copy than any single model call. That is the difference between a wrapper and a system. One ships what the model says. The other is engineered to be right.