The claim intake agent that refuses to guess

Claim intake is a form filled in by speech recognition. When the recognizer mishears a policy number, the claim lands on the wrong file, and nobody finds out until someone is denied. The failure is silent, because the agent has no way to know it was wrong. This agent splits the job. It listens and proposes. It does not decide. Every value goes through a server-side validator that checks it against the real policy data and returns one of three verdicts. Accepted, and it moves on. Rejected, and it asks again. Unconfirmed, and it reads the value back and waits for the caller to agree. The agent speaks the validator's exact words. It never invents a spelling. I tried three times to fix the recognizer instead. Transcription mode, turn-detection patience, and tool format hints were each measured against the same four policy numbers, and all three were null. The recognizer loses the D in KD4-1188 the same way in every configuration. That failure is acoustic, and no setting reaches it. Then I made it worse. AssemblyAI lets you bias the recognizer toward known terms, so I fed it the list of valid policy numbers. Accuracy improved and it started manufacturing false accepts. On one call the transcript's first reading was C411 and its final answer was KD4-1188, a real policy belonging to someone else, which then passed exact-match validation perfectly. The validator rested on an assumption I had never written down. The transcript is supposed to be an independent observation of what the caller said. Biasing the recognizer toward the answer key destroyed that, and every guard downstream stayed intact and stopped working. I removed the biasing. Policy numbers now require spoken confirmation whatever the match quality, because an exact match was never as strong as it looked. A reviewer sees every attempt, not just the ones that succeeded, each linked to what the caller said and when. The agent can be wrong. The record cannot be silently wrong.