A scheduled job can report success five runs in a row — exit code 0, dashboard green — while the process it was supposed to run has been dead for days. The lie isn't in the bot. It's in the wrapper. This is the evidence discipline that catches it.
15 minutes, or skip the call: I'll send the Week-1 scope doc. Either way I can show a wrapper lying, live, in under two minutes.
A log handle inherited by a background server bricked every future run of a wrapper in under a second. The success ledger got written anyway. No exit code caught it, no heartbeat caught it — output just quietly froze for four days.
A trading bot's restarter faithfully relaunched a process an exhausted API quota kept killing — 187 times in a single day, each one logged as a normal restart, not an incident.
A pipeline ran "healthy" for five weeks on default inputs because its real data sources had died. Its own graceful-degradation logic was, by design, hiding exactly that.
A paid "speed edge" data feed, once actually audited for attribution, had fed 0 of 20 trades. The free fallback fed all 20. The dashboard never distinguished the two.
For teams running scheduled jobs, wrappers, or agent automation in production, where a false "success" costs money before anyone notices. Nothing runs unattended? Not for you yet.
Jaime Bell. I run a fleet of ~60 trading/agent repos: every incident above is mine, found on my own fleet before any client's.
If an agent or scheduled job of yours has done something in the same family — reported success it didn't earn, asserted something that wasn't true, or quietly went dark behind a green light. Tell us about it. No pitch on the first message.
15 minutes, or skip the call: I'll send the Week-1 scope doc. Either way I can show a wrapper lying, live, in under two minutes.