An enrichment filter that errors hands the paid step every candidate it was rejecting

Take the nine-in-ten filter literally. Working, it passes one candidate in ten to the paid lookup behind it. Erroring, with nothing written to catch it, it passes all ten, so the paid step runs at ten times the volume it was sized for ^[6][7]. That multiple is a property of one consultant's workflow. For it to transfer, your filter's real reject rate has to sit near nine in ten, and the step behind it has to have no per-run cap of its own. Assad's post does not include counts of workflows diagnosed or spend figures ^[18].

Fail open is not a setting anyone selected. Assad, who builds these systems and says he spends more time diagnosing broken ones than building new ones, describes the two deliberate answers as fail open, where the workflow carries on without the check, and fail closed, where it refuses to proceed past it ^[1][4]. He tells readers to put one question to whoever built theirs: "What happens to the run when that check throws an error?" ^[3]

The fail-open version survives in production because the money leaves quietly. Email finding, enrichment and verification each draw on a finite monthly allowance, and if nothing counts consumption as the run proceeds, you learn the allowance is gone when the pipeline output drops and somebody asks why ^[8]. Green does not distinguish "found nothing" from "could not look" ^[9].

Assad documents his own. He built a spend cap that recorded spend only when a run wrote a result, so a run killed halfway through wrote nothing, cost real money, and never reached the cap ^[10]. A guard of his skipped its check whenever a required field was simply absent from the record, because the field was missing, so the condition was never true and the check passed ^[11]. "Absence was read as permission," he wrote ^[12]. He also projected a run's cost from one narrow sample, launched on that projection, and killed the run three calls in when the real rate came back several times higher, in the same week he had written the rule against extrapolating from unrepresentative samples ^[17].

Ordering is the cheap half of the repair. Workflows get assembled in the order data becomes available, so the judgment about whether a company was worth contacting at all lands last, after the enrichment and the verification that cost money; every rejection at that step is correct and every one is too late ^[14]. Assad puts a small model on the original trigger signal instead, which can usually decide "not a fit" for a fraction of a penny before a single paid lookup fires ^[15]. That holds until the small model times out. If its fallback is enrich everything anyway, the result is worse than having no filter, since a missing filter is a gap you can see and budget around ^[16].

In my view fail closed is the right default for any guard whose job is to suppress spend, and a cap should write a reservation when a run starts, not a total when it finishes. Both choices cost something. Fail closed turns a flaky enrichment API into a stopped pipeline, and somebody has to be on call for a stopped pipeline ^[4].