The most dangerous moment in an automated pipeline is not when the AI gets an answer wrong. It is the moment it has no answer at all — and keeps going anyway.
Every automation system has a hole shaped like an unknown. A form asks for salary history and the profile has none. A posting's salary band appears on the listing but can't be verified against any official source. The network drops after the submit POST, and nobody knows whether the server accepted it. Three different unknowns, and every one of them has to go somewhere. In most pipelines, they go into the same place: a quiet assumption that everything worked out.
Keel's design starts from the opposite premise. Unknown is not a formatting problem. It is a first-class signal, and the pipeline is built to carry it without dropping it, rounding it up, or pretending it resolved.
The three kinds of unknown
It helps to be specific, because "unknown" covers three failure modes that demand different handling.
1. The unmapped question. The answer bank is the applicant's own stored answers, each with provenance — what was stated, and when. When a form asks a question the bank doesn't carry, the resolver abstains. It does not hedge, it does not approximate from adjacent fields, it does not write a plausible sentence. The gap is reported with its reason named: question asked, no bank entry, nothing invented.
2. The unverifiable posting. Before anything is built, the prescreen checks the posting against the applicant's policy. If a claimed fact about the role can't be verified from an official source, the posting is parked. Not rejected — parked, with the unverifiable item named, so the applicant can check it personally.
3. The ambiguous outcome. A submission attempt that ends without explicit confirmation — a timeout after POST, a page that never renders its receipt — is marked UNKNOWN. Not failed. Not submitted. A state that refuses to resolve itself.
What these three share is the refusal to let uncertainty collapse into a convenient answer. That collapse is where automation lying comes from: the missing answer that gets bridged with fiction, the unverifiable posting that gets applied to anyway, the ambiguous submit that gets counted as a win.
Unknown is not no
The subtle part of this design is what unknown does not mean. It does not mean "no."
A parked lead is not a dead lead. When the prescreen parks a posting because the on-site requirement exceeds the policy cap, the lead waits in a needs-input queue with its reason attached. The applicant reads the reason, checks the actual requirement, and either supplies the missing piece or walks away. The question stays open. Nothing was decided on the applicant's behalf.
This is the distinction that makes fail-closed usable instead of merely safe. A system that treats every unknown as a rejection would starve itself: legitimate postings would die in the parking queue because one field couldn't be verified. A system that treats every unknown as a yes would lie. Keel's third option — park, name the reason, wait for the one person who can resolve it — is the only shape that preserves both honesty and momentum.
Consider "Alex Candidate," the synthetic applicant Keel ships for demos. His bank carries two keys: start date and US work authorization. A form asks a third question — salary history — which the bank doesn't carry. Two questions resolve from the bank; the third is marked [ABSTAIN], and the gap lands in his review queue with the exact question quoted. He answers it himself, in his own words, and the bank grows. The unknown was never a gap in his candidacy. It was a question waiting for its only honest source: him.
Why the pipeline must stop
There is a reason this has to be a hard stop rather than a warning. In an autopilot, an unhandled unknown does not sit still — it decays into one of two outcomes, and both are bad.
The first decay is fabrication. A warning that says "salary history missing" next to an otherwise complete packet is one click away from being answered by the machine anyway. Under deadline pressure, in an overnight batch run, the convenient thing is to let the resolver have another guess. Once that door opens, the truthfulness contract is a suggestion, not a gate.
The second decay is the silent drop. The lead that can't be resolved gets quietly skipped, the posting that can't be verified disappears from the queue, and the applicant never learns what they missed. Nothing was lied about, but information was lost — and in a job search, a lost opportunity is a real cost.
Fail-closed chooses the honest inconvenience over both. The run stops. The reason is named. The applicant is the only one who can supply what the machine lacks. That is not the pipeline being fragile; it is the pipeline knowing exactly where its authority ends.
Uncertainty as a worklist
Handled this way, uncertainty stops being a failure mode and becomes a worklist. Every parked item carries its own resolution path: the question that needs an answer, the posting detail that needs verifying, the attempt that needs reconciling. The applicant doesn't debug the pipeline. They answer one question at a time, each with its reason attached, and the pipeline resumes from exactly where it stopped.
This is what "fail closed" means as a discipline rather than a slogan. Not that the system never moves, but that every move it makes is one it can stand behind — and every move it can't, it hands back, named and timestamped, to the person whose name is on the application.
This post was written by AI and published through an automated pipeline — same as the rest of the series. The point of Keel is transparent automation, so the byline says so plainly.
