Keel refuses the second application until a human confirms the first one landed

Writing the ledger row before the POST is a write-ahead log, and the ordering is the part that has to be correct. A process that dies mid-call still leaves a row saying it tried ^[5]. Record after the call and you lose exactly the case the design exists for.

The state that row lands in has no automatic exit. Keel's write-up refuses both of the moves an ordinary retry layer would make, and for the same reason each time: the application may exist ^[6]. "Both errors are the same error seen from opposite sides: acting on information you don't have," the post says ^[7].

The demo path shows what that costs. Alex Candidate, the synthetic applicant Keel ships, submits to a role, the POST times out, and his next scheduled attempt at the same role is refused with OpenIntentExists ^[11]. He reads his email, finds the ATS confirmation with a reference number, and reconciles the attempt as submitted with that text stored as evidence; the counter moves by one ^[12]. In the other branch there is no email and nothing in the portal, so he closes the attempt as failed, and a fresh attempt starts as a new intent with the earlier history attached ^[13].

The check behind that evidence is weaker than the prose around it. Keel refuses to mark an attempt submitted when the confirmation text is empty ^[9], and the post describes the closing evidence as "Application submitted" with a reference number on the confirmation page ^[10]. Non-emptiness is cheap to enforce, and it does stop the automatic guess, but it cannot separate a pasted receipt from the word yes.

The counting convention follows from the same rule. Keel reports 210 verified submissions as of September 22, 2026, incrementing only on explicit-confirmation closes, with UNKNOWN and failed attempts excluded ^[14]. Some UNKNOWN attempts may have landed, by the post's own premise ^[6], so the number of applications actually delivered is 210 or more ^[16]. According to the post, every submission metric in the auto-apply industry is built on the opposite convention ^[15].

The write-up does not report how many attempts ended in UNKNOWN ^[17], so the human reconciliation load behind those 210 confirmed submissions cannot be worked out from it.

The pattern transfers on three conditions about the counterparty: no client-supplied idempotency key, no read API to ask whether the record exists, and some channel that a human can check instead. Keel's reconciliation step is a person looking at an ATS or an inbox ^[8]. You build that when the receiving system will not answer. Where the endpoint does deduplicate on a key you send, a second POST is safe and a ledger like this one is redundant.