Your Outreach Tracker Shows ‘Unverified’ — Exit Code 0 Doesn’t Mean It Ran

A phantom dispatch is a logged outreach event that carries a success exit code but no verified timestamp chain, meaning the system reports completion without evidence that the underlying action — a send, a query, a post — actually occurred.

Exit code 0 is a process claim, not an action claim

Exit code 0 tells you one thing: the process ended without raising an error. It says nothing about whether the work inside that process happened. A function can open a file handle, skip every write, close cleanly, and return 0. The shell is satisfied. The file is empty.

This distinction is abstract until you have a log entry that proves it. On 2026-09-09 at 17:33, a forced run of the SAVYX outreach pipeline produced exactly that result. The run returned LastTaskResult 0. The output file — earned_source_response_20260909_Source_of_Sources.json — exists on disk. So far, a clean success.

But the dispatch.verdict field told a different story. All three audit timestamps — query_url, deadline_at, and verified_at — came back null. The verdict field did not report “sent” or “failed.” It printed the only honest label available given what the data showed: unable to determine dispatch status. A null timestamp chain is not a network error or a retry. It is an absence of evidence that the action was ever attempted by the component responsible for it.

That is the gap exit code 0 cannot close.

Why this failure mode is structurally invisible

Most monitoring systems instrument the wrapper, not the action. They record that a function was called and returned, not that the downstream effect materialized. This is fast to build and catches the common case — crashes, timeouts, bad credentials — where the wrapper itself fails. It misses the less common but more dangerous case where the wrapper succeeds and the action silently does not.

The result is a verified-looking log row attached to an unverified event. If your reporting pipeline reads exit codes to count dispatches, the phantom shows up in your totals. It passes every automated health check. It never appears in an error report. The only signal it leaves is the null timestamps — and those are only visible if you query for them specifically.

The practical danger for outreach operations: a phantom dispatch inflates your sent count, deflates your apparent reply rate, and gives you no trigger to re-queue the contact. You are not flying blind in the sense of system failure. You are flying blind in the sense of confident, wrong instrumentation.

The non-obvious structural lesson: absence fields need their own alert tier

Standard observability treats null as “not yet populated” rather than “evidentially absent.” That is appropriate for fields that get written asynchronously. It is wrong for fields that represent completed verification steps.

The architectural distinction matters: a timestamp field on a verification step is not a nullable attribute — it is a boolean claim with a timestamp attached. If the step ran, it writes. If it did not write, the step did not run. Null on a verification timestamp is a first-class event, not a missing value. Monitoring systems that do not distinguish these two interpretations will suppress exactly the signal you need.

The fix is an explicit phantom-rate query rather than an error-rate query. Error rate counts non-zero exits. Phantom rate counts zero exits with null verification timestamps. The formula:

phantom_rate = (runs where exit=0 AND verified_at IS NULL) / (total runs where exit=0)

A non-zero phantom rate that persists across runs is a pipeline architecture problem, not a transient fault. It deserves its own alert threshold, separate from error rate.

What this means for outreach pipelines specifically

Outreach tracking has a tighter consequence window than most pipeline categories. A send that did not happen but is logged as sent means a contact is not re-queued. A deadline_at that is null means the pipeline cannot enforce follow-up timing. A verified_at that is null means no downstream system can confirm delivery.

The three null timestamps are not equivalent: query_url null means the lookup did not execute; deadline_at null means the scheduling anchor was never written; verified_at null means confirmation never ran. Each null points to a different component in the chain. Grouping them as “the timestamps were null” obscures which part of the pipeline broke, and debugging from a grouped symptom is slower than debugging from a named component.

When auditing a phantom dispatch, trace the three timestamps separately. The first null in sequence is the failure origin. The nulls after it are consequences, not independent faults.

The broader audit principle: instrument the evidence, not the process

The deeper pattern here is an instrumentation philosophy question. Outreach pipelines, AI agent pipelines, and automated reporting systems all share the same structural temptation: measure the process because it is easy to observe, and infer the action because the action is harder to confirm.

This works until it does not, and when it fails, it fails silently. The CARE-X radiology research from Microsoft illustrates the same principle in a different domain: a model that produces an output is not the same as a model that has verified the clinical measurement. Microsoft’s own disclosure notes CARE-X is a research model, not an approved medical device — precisely because the gap between “output produced” and “action verified” carries consequences when the domain is consequential. The instrumentation principle is domain-agnostic.

Instrument the evidence, not the process. A send is evidenced by a delivery confirmation. A query is evidenced by a stored response URL. A verification is evidenced by a timestamp. Exit codes instrument the process. Timestamp chains instrument the evidence. You need both — but when they conflict, the timestamps win.

Decision rule for your own pipeline

Audit before you report. Before any dispatch count enters a report or a pitch — the old figure of 26 posts cited zero times in the 2026-09-09 run is the measured example — run the phantom-rate query above. If phantom_rate is above zero, your sent count is not your actual sent count, and the difference is unknown until you trace each null timestamp chain.

That is not a catastrophic failure. It is a measurement gap with a straightforward close: add verified_at as a required field, alert on null at the same priority as a non-zero exit, and separate the three timestamp faults by component in your debug logs.

The system does not need to be more reliable. It needs to be more honest about what it has and has not confirmed.

Looking for more on ai & digital income? Visit SAVYX

Frequently Asked Questions

What does it mean when my tracker shows ‘Unverified’ with all timestamps null?

It means the pipeline exited cleanly but no component wrote a confirmation that the dispatch action — send, query, or verification — actually executed. The three null timestamps (query_url, deadline_at, verified_at) point to different components, so trace them separately to find the first failure origin.

Why does exit code 0 not confirm that outreach was sent?

Exit code 0 confirms the process wrapper ended without an error, not that the action inside it occurred. A function can skip its core work, close cleanly, and return 0. Verification requires a written timestamp, not a clean exit.

What is a phantom dispatch and why is it dangerous?

A phantom dispatch is a logged send event that carries a success exit code but no verified timestamp chain. It is dangerous because it inflates your sent count, suppresses re-queue triggers for the contact, and never appears in error reports — it only shows up in an explicit audit query.

How do I calculate phantom rate for my pipeline?

Divide runs where exit equals 0 and verified_at is null by total runs where exit equals 0. A persistent non-zero result is a pipeline architecture problem, not a transient fault, and warrants its own alert threshold separate from your error rate.

Why should null on a verification timestamp be treated differently from other null fields?

A verification timestamp is a boolean claim with a timestamp attached — if the step ran, it writes; if it did not write, the step did not run. Standard monitoring treats null as ‘not yet populated,’ which is wrong for a completed verification step. Null there is a first-class alert event, not a missing value.