DEV Community: Trent Wade

Ambiguous submission outcomes should never be retried

Trent Wade — Wed, 23 Sep 2026 01:03:36 +0000

Every retry policy you have ever configured treats a failed operation the same way: back off, try again, repeat until it succeeds. That reflex is correct for idempotent work — fetching a page, writing a log line, queueing a message. It is wrong for exactly one operation that job-application automation performs constantly: submitting.

Submitting is not idempotent. Pressing "send" twice on an application does not refresh the first one. It creates two applications with your name on them. And a system that retries an uncertain submit is playing dice with your reputation every time the network blips.

The timeout you can't read

The scenario is mundane. The application packet is complete. The form is filled, the button is clicked, the POST goes out — and the response never comes back. Timeout. Tab crash. The ATS returns a blank page.

Now the system knows nothing. The server may have accepted the application and then dropped the connection on the way out. It may have rejected it. The record may not exist at all. Every one of those worlds is consistent with what you observed.

The standard engineering instinct says retry. Most automation does retry — on failure, on timeout, on anything that didn't return 200. And most of the time, retrying a job application is harmless. The one time it isn't, you've submitted the same application twice to the same role.

Ask what that looks like from the employer's side. Two identical applications, same name, minutes apart. It reads as either a glitch or spam, and neither reading helps. Your name is on both of them. The candidate pays for the retry; the bot that retried pays nothing.

The ledger of record

Keel handles this with a ledger, and with rules about the ledger that look paranoid until you think about what they prevent.

The first rule: the intent is recorded before the attempt, not after. Before any network call happens, the ledger holds a row for this attempt: which role, which materials, timestamped. The attempt exists in the record before it exists in the world.

The second rule: an attempt that ends ambiguously is marked UNKNOWN — and that mark is terminal. Not a soft failure that gets retried with backoff. A state the system will never resolve on its own. It is never downgraded to a plain failure (because the application may exist), and it is never retried (because the application may exist). Both errors are the same error seen from opposite sides: acting on information you don't have.

The third rule: a second attempt for the same role is refused while the first is unresolved. The ledger raises an OpenIntentExists error. This is not a suggestion. The operator can only proceed after the open attempt is reconciled — by a human, checking the ATS or their inbox for actual confirmation.

The fourth rule: marking an attempt submitted with empty confirmation text is refused outright. The confirmation has to say something. "Application submitted" with a reference number on the confirmation page is what closes an attempt. A guess never is.

What reconciliation looks like

Take Alex Candidate, the synthetic applicant Keel ships for demos. He submits to a role; the POST times out. The ledger marks the attempt UNKNOWN and the system refuses his next scheduled attempt at the same role with OpenIntentExists. Nothing proceeds. The pipeline stops and names the reason.

Now a human does the one thing a machine can't do safely: check the world. Alex looks at his email. There it is — the ATS confirmation, reference number included. He reconciles the attempt as submitted, with the confirmation text recorded as evidence. The submission counter increments exactly once.

Consider the counterfactual. No confirmation email exists. Alex checks the ATS portal: no application on record. He closes the attempt as failed — and that closure is a deliberate human decision, not an automatic retry. A fresh attempt can now be made, as a new intent, with the earlier history attached. The difference matters: the second attempt was never a blind retry of an unknown. It was a new decision made with knowledge.

Why the number means something

This is the design behind the figure the series keeps quoting: 210 verified submissions as of September 22, 2026. That count increments only on explicit-confirmation closes. Attempts sitting in UNKNOWN were never counted. Attempts closed as failed were never counted. The number is not "applications we probably sent." It is applications the ledger can prove, each with its confirmation evidence attached.

Every submission metric in the auto-apply industry is built on the opposite convention: attempts counted as submissions, retries counted separately, duplicates invisible. A pipeline that retries ambiguous submits and counts the retries is manufacturing its own traction figure out of its own uncertainty. The honest count is smaller, and it is real.

A rule worth stealing

Even if you never touch Keel, the rule generalizes. In any system that acts in the world on someone's behalf — applications, payments, registrations, anything that can't be un-sent — separate your outcome states into three, not two: confirmed, failed, unknown. Retry only the failed. Reconcile the unknown by checking the world. Never retry what you don't know.

Uncertainty is not a failure to retry harder. It is a state to resolve honestly, once, with evidence. Build that into the ledger and the double-submit disappears as a category — not because you got luckier with the network, but because the system was never allowed to gamble on your name.

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.

https://github.com/KeelDev-tech/keel

What happens when an AI doesn't know the answer?

Trent Wade — Wed, 23 Sep 2026 01:02:40 +0000

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.

https://github.com/KeelDev-tech/keel

The override protocol: how Keel lets the operator overrule a refusal — honestly

Trent Wade — Tue, 22 Sep 2026 22:25:51 +0000

Keel's refusals are hard gates: when a question can't be answered honestly, the run stops and the lead parks with its reason named. But a machine you can't overrule isn't a tool — it's a boss. So the override exists. What matters is how it's recorded.

An override is a first-class record, not an edit. The original refusal stays in the ledger — parked, named, timestamped. The override lands on top of it, carrying the operator's word with provenance: who said it, when, and exactly which refusal it unlocks. History is never rewritten. A later reader sees the refusal AND the override, in order, each stamped.

The rules around the override are as strict as the refusal it answers. It applies to exactly the refusal it names — never a class, never a blanket permission. Silence is never an override; the machine waits, and waiting means no. And the override answers only to the operator's own word: his sentence, his signature, his attestation — the things only he can supply.

This is why the fail-closed discipline survives human authority instead of dissolving into it. The operator is the only authority the machine recognizes, and the machine recognizes his authority by recording it — every override visible, every one attributable, none of them silent.

Build the pressure valve into the contract, and the contract holds even when you open the valve.

Repo link to include at the end: https://github.com/KeelDev-tech/keel (Apache-2.0).

Why auto-apply bots are spam (and what actually works)

Trent Wade — Tue, 22 Sep 2026 21:31:11 +0000

The pitch is seductive: apply to 500 jobs while you sleep.

So people do. And then something predictable happens — the kind of thing that’s obvious once you look at it from the employer’s side.

The problem with blasting

Every mass auto-apply bot solves the same wrong problem: more applications. But applications are a signal. When a flood of applications arrive that all say the same thing — the same templated phrasing, the same hedged non-answers — each one doesn’t just fail, it teaches the employer that your name produces noise.

Three things actually go wrong:

1. Generic applications are indistinguishable from spam.

If a bot submits the same template to a hundred postings, the result reads exactly like what it is. Employers and their filters notice patterns. And your name is on every one of them.

2. Bots inside your personal sessions put your accounts at risk.

Some auto-apply tools describe, in their own materials, driving your browser session to mass-apply — the very behavior those platforms’ terms restrict. (We documented this with vendor-disclosed sources in the repo’s comparison doc.)

3. The silent killer: invented qualifications.

When a bot fills a form on your behalf and the answer isn’t in your profile, the confident move for the bot is to make something up. That fabrication lands on your application, under your name. A bot has nothing at stake when it lies. You do.

So blasting gives you the worst of both worlds: low signal, real risk.

What actually works

The fix isn’t “apply to fewer jobs.” It’s treating every application as something you stand behind, and automating everything except the parts where honesty lives:

Automate discovery and scoring. Let software watch the boards, score postings against your profile, and kill the bad fits.
Automate the first draft. Resumes, cover letters, answer banks — generated from your verified profile, with every claim traceable back to it.
Put human gates around honesty. No answer ships unless it’s verified against your profile. No submission happens without you.
Fail closed, never fill in. If a question can’t be answered truthfully from what you’ve provided, the system stops and tells you — it doesn’t improvise.

That’s the shape of Keel, the open-core project we maintain. It’s a job-application autopilot with a hard rule: it refuses to lie. Keel never submits an application on your behalf — it builds a verified launch packet (form values, banded rules, hard gates, per-field verification protocols) and you run it.

A concrete example: “Alex Candidate”

This isn’t theoretical. Keel ships a synthetic applicant profile (sample_data/applicant_profile.example.json) so you can see the honest-automation contract in action. Meet Alex Candidate — a synthetic backend engineer.

1. Discovery. Keel watches job boards for Alex and scores each posting against his profile. Bad fits are killed early; good fits get a draft.

2. Materials. The resume tailor drafts Alex’s materials from his profile file only. Every bullet has to be something Alex actually did — the sample file itself notes: “Every claim here must be TRUE.”

3. The honesty gate. A posting asks: “How many years of Go experience do you have?” Alex’s profile lists Python, not Go. A bot would write “3 years” or hedge. Keel’s answer resolver does the only honest thing: it abstains and flags the gap to Alex. Gaps are reported, never bridged with fiction.

4. The unverifiable posting. Another posting’s salary band is stated on the listing but can’t be verified from an official source. Keel’s prescreen rules say: if it can’t be verified, the posting is “unverifiable” and gets parked — not applied to. Keel would rather park a posting than apply to something it can’t verify.

5. The launch packet. What ships is a bundle Alex can execute himself: every form field, the rule it came from, and how to verify it. And the submission counter? It only increments on explicit confirmation evidence. An ambiguous run is marked UNKNOWN and barred from retrying — not optimistically counted.

That’s the difference: a bot that invents answers to hit its quota, versus a system that protects your name by stopping when it can’t be honest.

Free and open

Keel is open-source (Apache-2.0), self-hosted, and free — no paid tier, no quotas. The whole honest-automation contract (truthfulness gates, explicit confirmation, fail-closed design, no fingerprinting surface) is in the README, and the auto-apply comparison is in docs/keel-vs-autoapply-bots.md.

If you’ve been tempted by auto-apply bots, I get it. Just ask what each application you didn’t write says about you — and what it does to your name when it lies.

How Keel's honesty gates actually work

Trent Wade — Tue, 22 Sep 2026 20:34:18 +0000

In my intro post, I described Keel — an open-source, self-hosted job-application autopilot with one hard rule: it refuses to lie. The natural follow-up question is: what does "refuses to lie" actually mean in code?

It's not a system prompt asking the model to behave. It's three gates in the pipeline — validation that fires before anything reaches a human. I recently consolidated them into a single terminal demo that runs the real engines against synthetic data:

python3 demo/honesty_gates_demo.py

Here's what each gate does, straight from the repo.

Gate 1: Truthfulness — abstain, never invent

When Keel fills an application form, every answer comes from an answer bank: the applicant's own stored answers, each with provenance (what they stated, and when). If the form asks something the bank doesn't carry, the resolver doesn't improvise. It abstains.

The demo walks through a synthetic applicant, "Alex Candidate," whose bank carries two keys: start date and US work authorization. The form asks a third question — salary history — which the bank doesn't carry. The result: two questions resolved from the bank, one marked [ABSTAIN], with the gap reported rather than invented.

Keel never bridges a missing answer with fiction. Anything the profile can't support is reported as a gap.

Gate 2: Fail closed — park, never proceed

Before a launch packet goes anywhere, the prescreen step checks the posting against the applicant's policy. In the demo, a posting for "Staff Operations Manager" demands five days a week on-site; the policy cap is three. The prescreen verdict is PARK, and the lead is moved to a needs-input queue until the applicant resolves it personally.

Keel never proceeds past a commitment it cannot verify. Unverifiable postings, unmappable required questions, missing attestations: park, never proceed.

Gate 3: Explicit confirmation — nothing counts without evidence

This gate protects the ledger. In Keel's private loop, a submission attempt works like this:

The intent is recorded before any attempt — not after.
If the attempt ends ambiguously (say, a network timeout after POST, when the server may already have accepted it), it's marked UNKNOWN. Never downgraded to a plain failure, and never retried — a retry would risk a duplicate application.
A second attempt for the same role is refused with an OpenIntentExists error until the open attempt is reconciled.
Marking an attempt as submitted with empty confirmation text is refused outright.
Only explicit confirmation text closes the attempt — in the demo, an Ashby confirmation page quoting "Application submitted" with a reference number.

A submission counts only on explicit confirmation evidence. Nothing else. That's what makes the ledger's figure — 210 verified submissions, tracked in the repo as of September 22, 2026 — a real number rather than a decorative one.

Try it yourself

The demo uses the real engines — answer_resolver, prescreen, submit_intent — against synthetic data only. It runs fully offline, touches only a temporary scratch directory that gets cleaned up afterward, and needs nothing beyond Python 3.10+ (Keel is stdlib-only, no dependencies):

git clone https://github.com/KeelDev-tech/keel
cd keel
python3 demo/honesty_gates_demo.py

What the gates don't do

Being precise here matters more than the gates themselves. Keel's public loop never submits an application — it stops at the launch packet: job context, completed materials, and the outstanding questions, ready for the applicant to review and submit. The gates don't make the autopilot bolder. They make it stop earlier and say exactly why.

And gates aren't guarantees against every failure mode. What they guarantee is the direction of the failure: the system errs toward abstention, parking, and under-claiming — never toward fabrication.

The repo is open-source and self-hosted: github.com/KeelDev-tech/keel

🤖 This post was written by AI and published through an automated pipeline — same as the intro. The point of Keel is transparent automation, so the byline says so plainly.

I built a job-application autopilot that refuses to lie

Trent Wade — Tue, 22 Sep 2026 12:16:35 +0000

Auto-apply tools had a good premise and became spam cannons. Identical applications, invented qualifications, blasted at everything. It burns the candidate and poisons the channel for everyone — including people applying honestly.

I spent the last year running a production job-application pipeline, and the thing I kept coming back to was: the lying is the product defect. Not the automation. The automation is fine. The lying is the defect.

So I built Keel around a truthfulness contract, enforced in code rather than promised in marketing:

Truthfulness gates. Anything your profile can't support is reported as a gap, never bridged with fiction. No invented experience, degrees, or answers.
Explicit confirmation. Nothing counts as submitted unless the page itself confirms it. Not the browser accepting the task — the page confirming.
Fail closed. Unverifiable postings, unmappable questions, missing attestations: park, never proceed.
No fingerprinting surface. Nothing in the public repo helps ATS vendors identify or block automated applications.

The public half is Apache-2.0: discovery and fit scoring, truthful resume tailoring, a canonical answer bank, prescreen gates, an ATS capability radar (read-only probes), the launch-packet builder, append-only telemetry, and a dashboard. The execution layer — how applications are actually submitted — stays private deliberately. It holds submission-behavior techniques vendors could fingerprint, and publishing them would degrade the pipeline for everyone running it, including everyone who clones the repo. The boundary rule is public in SPLIT.md.

The traction figure: the private production pipeline running this discipline holds 210 verified submissions, recounted today from its ledger (202 with quoted confirmation evidence, 3 with pointer evidence, 1 URL-only, 3 unevidenced — counted, never estimated). I'll state the limit plainly: you can't independently re-run that pipeline. What's verifiable is the discipline — the gates, the telemetry, the fail-closed reporting rules are all public code.

If you're a builder, the quickstart is ~5 minutes, stdlib only, with a terminal demo in the README. If you're a contributor, I want help most on ATS behavior coverage, answer-bank ergonomics, and outcome analytics.

The repo: https://github.com/KeelDev-tech/keel