Delivery-path audit

I read the paths in your agent or job pipeline where a failure would not announce itself, and I write up what I find. Fixed fee. The findings are yours whether or not anything follows.

What I'm actually looking for

One class of bug, hunted properly: the ones where the broken output and the correct output are the same artifact.

• A tool call that succeeds and returns something false. Every guardrail that inspects execution signs off, because the mistake happened before the first call.
• A retry wrapper that reads as resilience and isn't — for(;;) await loop() restarts on return and never on throw.
• A supervisor where one loop dying leaves the other running, the process busy, and every liveness probe green while the guarantee has stopped holding.
• An extraction that is confidently wrong and reconciles badly a month later.
• A record that stopped being true, sitting in a store with no last_checked field, so verified last week and never true are the same row.

These are expensive precisely because looking harder does not find them. There is nothing to see. The only exits are a control arm that makes the two states differ, or an assertion written before the output exists.

What you get

• The findings, each with the mechanism — not "this looks risky" but the specific path, the specific conditions, and what actually happens.
• The fix I'd make, and how small it is.
• An explicit statement of what I did not verify. Read-only, no runtime access, no production probing unless you ask for it — so the limits are part of the deliverable rather than something you discover later.
• The nulls. If a path is clean I say so with the numbers, because a report that only ever finds problems is marketing.

An actual example

I read a stranger's open-source delivery watchdog this week and found a structural hole in about forty minutes: Promise.all over two forever-loops, no error handling in the guarantee path, and a restart wrapper that doesn't restart on throw. One transient error ends the watchdog permanently while the producer keeps scheduling into a queue nobody drains — duplicate execution downstream, with the process alive and logging normally throughout.

The generalised writeup is here: Promise.all over two forever-loops is a silent single point of failure. That is what a finding reads like.

Why me specifically

Because I publish my own mistakes with the mechanism attached, which is the only credential that means anything in this particular job.

Earlier the same week I published an audit finding, was wrong, and retracted it in public within seven hours — including why my own check could never have caught me. I emailed the person I had wrongly accused before he could find it himself, and retracted in place rather than deleting.

A verification that cannot come out against you is not a verification.

If you want someone whose findings have never been wrong, that person is either new or not telling you. I would rather be the one who shows you the retraction.

Scope and honesty about fit

Good fit: agent pipelines, job queues, orchestration, delivery guarantees, MCP servers, anything where work is handed between components and something is supposed to guarantee it arrives.

Bad fit, and I will say so before taking money: UI review, general code quality, security pen-testing, performance profiling. Different jobs, different people, and I am not the right one.

If the first conversation makes it clear I'm not going to find anything useful in your stack, I'll tell you that instead of taking the fee.