Testing the Verifier: Precision First

A false positive destroys operator trust faster than a false negative destroys accuracy. When your verifier flags a correct output as defective, the engineer stops reading the report. They assume the tool is noisy. Once that assumption takes hold, the verifier becomes a checkbox exercise rather than a quality gate. You have built a deterministic checker that returns located violations. Now you must prove it does not lie. The strategy is simple but unforgiving: tune for precision first. Chase recall only after you have eliminated false alarms on clean data. This approach protects the human in the loop from alert fatigue. It ensures that when the pipeline screams, the engineer listens. The test suite for the verifier is not a standard unit test. It is a fixture-based evaluation against known ground truth. You need two sets of inputs. The first set contains outputs you know are correct. These are your clean fixtures. The second set contains outputs with specific, seeded defects. These are your defective fixtures. Run the verifier against both. Record the results. The metric that matters most at this stage is precision. Precision is the ratio of true positives to all positives. If your verifier flags ten items and one is correct, your precision is ninety per cent. That single false positive is unacceptable. It means the operator has to manually inspect one good item to find the nine bad ones. Do this often enough, and the operator will stop inspecting at all. Start with the clean fixtures. These should cover the variety of outputs your pipeline produces. Include edge cases. Include long outputs. Include outputs with complex formatting. Run the verifier. If it flags any of these, you have a bug in your rules. Fix it. Do not move on until the false positive rate on clean fixtures is zero. This is non-negotiable. A verifier that cannot distinguish good from bad is worse than no verifier at all. It gives a false sense of security. It wastes time. It erodes confidence in the entire system. Once the clean fixtures pass, introduce the defective fixtures. Seed specific defects into the outputs. For example, if your verifier checks for JSON schema compliance, create outputs with missing fields. If it checks for tone, create outputs with aggressive language. If it checks for factual accuracy against a reference, create outputs with swapped numbers. Run the verifier. Record which defects it catches. Record which it misses. This gives you recall. Recall is the ratio of true positives to all actual positives. Low recall means you are missing problems. High recall with low precision means you are flagging everything. You want high precision first. Then you improve recall. Tuning for precision often means tightening rules. If a rule is too broad, it will catch good outputs. Narrow it. Add constraints. Use regular expressions that are specific. Use structural checks that are strict. For example, instead of checking if a field exists, check if it exists and has the correct type. Instead of checking if a word is present, check if it is in the correct context. This reduces false positives. It may reduce recall. That is acceptable. You can always add more rules later. You cannot undo the loss of trust caused by false alarms. Consider the cost of each rule. Some rules are cheap. Checking string length is fast. Checking JSON structure is fast. Other rules are expensive. Checking against a large reference document is slow. Checking for subtle semantic errors is hard. Prioritise cheap, high-precision rules. They provide the most value for the least cost. Expensive rules should be added only when cheap rules have been exhausted. This keeps the verifier fast. Speed matters. If the verifier takes too long, engineers will bypass it. They will run the pipeline without checking. The tool becomes dead weight. The test report is the artifact you produce. It is not a single number. It is a table of results. It shows precision and recall for each rule. It shows which fixtures passed and which failed. It highlights false positives. It highlights false negatives. This report is your evidence. It proves the verifier works. It proves it does not lie. It proves it catches the defects you care about. Generate this report automatically. Run it on every commit. Fail the build if precision drops. This enforces the discipline. It prevents regression. It ensures the verifier remains reliable.

The table above illustrates the goal. Zero false positives on clean outputs. High precision on defective outputs. The mixed set confirms the verifier handles real-world variety. If you see false positives in the mixed set, investigate. Are the rules too broad? Are the fixtures not representative? Fix the rules. Do not adjust the metrics. The metrics reflect reality. Change the reality by improving the verifier. Admit the limitation. This approach requires manual effort to create fixtures. You must write the good outputs. You must write the bad outputs. You must maintain them. This is a cost. It is not automated. It is not scalable in the way LLM-based evaluation is. But it is reliable. It is deterministic. It does not hallucinate. The cost is worth it. The alternative is a verifier that gives wrong answers. That is not a tool. It is a hazard. The test report is your deliverable. Generate it. Review it. Commit it. It proves the verifier is ready. It proves the pipeline is safe. It proves the loop is closed. The next step is integration. The verifier must run in the pipeline. It must block bad outputs. It must allow good outputs. It must do this without slowing down the engineer. The test report gives you the confidence to deploy. It gives you the evidence to trust. Use it. The course gate is simple. Five of five seeded defects caught. Zero false positives on good fixtures. pytest –pack green. If you have this, you have built a verifier that works. It is deterministic. It is precise. It is trusted. The next lesson covers deployment. It covers integrating the verifier into the pipeline. It covers handling edge cases in production. It covers monitoring performance over time. The foundation is laid. The verifier is ready. Now put it to work.

Apply it to your work