Nyx Pulse is my automated personal briefing. On 8 August, it published an edition with no cards after its run record reported that nothing met the freshness, source-quality, deduplication and verification gates.
The recorded input boundary covered current news, work technology, my Watch List, live project changes and stale pages. The run used the stable identity nyx-pulse-standard:2026-08-08:v3, recorded an explicit zero-card decision, and a later day-list read showed the dated edition with no cards.
That establishes the durable recorded outcome. It does not independently show that every source was exhausted or that every gate was applied correctly.
When judgement-based AI automation produces nothing actionable, it should leave a receipt. Without one, an empty feed or task list cannot tell us whether the evaluation finished or the run disappeared.
The receipt does not need to expose a model's hidden reasoning or preserve a transcript of every step. It needs observable facts that another check can read: the intended scope, what was actually available, the decision reached and evidence that the recorded outcome persisted.
That keeps a no-op cheap without making it invisible.
On the same day, a supervisor found a less reassuring kind of silence. Ten active scheduled runs contained no assistant messages and no tool or function events.
That evidence justified review, but it did not establish why the runs were silent. They may not have started, may have stopped early, or may have completed outside the detector's view.
Detection is not diagnosis.
The handling should follow the evidence. Pulse's durable zero-card record can support a clean stop within its stated limits. The silent runs need investigation because their completion is unknown.
Treating both as ordinary silence either creates pointless review work for healthy no-ops or allows missing runs to pass unnoticed.
This mirrors a familiar monitoring distinction: "no exception found" is different from "the check did not run". Conventional automation shares the underlying problem and can also produce formally valid output from incomplete inputs.
Generative text makes the problem harder to spot. A judgement-based workflow can cheaply produce a coherent briefing, summary or classification even when its evidence is weak. Schema-based checks may confirm that every required field exists while revealing nothing about missing sources or the quality of the decision.
For this kind of AI automation, output presence is a particularly weak sign that the work was completed properly.
A person reading the result may notice that a briefing is thin, but a downstream process may see only valid fields and continue. If the output creates a task, updates a feed or satisfies a control, weak evidence can travel further before anyone examines it.
The receipt gives that next process a separate basis for deciding whether to continue.
The instructions therefore need to permit an evidenced decision to produce nothing. Otherwise, a workflow can satisfy the requested format by adding another link, stretching weak evidence into a paragraph or forcing every item into a category.
Three observable states
I want an operator or downstream system to be able to distinguish three states:
- Actionable result. The evaluation completed, at least one item cleared the threshold, and the agreed output was produced.
- Evidenced no-op. The evaluation completed, nothing cleared the threshold, and a durable receipt records that decision.
- Unverified completion or unknown run state. The available evidence cannot establish that the evaluation completed reliably.
The third state is not confirmed failure. Failure may be the eventual diagnosis, but missing output or missing events do not prove it. Keeping the state as unknown prevents a monitoring signal from becoming an invented root cause.
These are observable states, not explanations. Later investigation may show that an unknown run failed, completed through an unobserved route or never started. The initial label should stay within what the evidence supports.
The same distinction applies to enterprise document escalation. If a generative review finds nothing that meets the escalation rule, the receipt should show which documents it could examine and which rule it applied. If some documents were unavailable, the run belongs in the unknown state even if it produced a polished summary of the rest.
A downstream process can then stop rather than advance a partial result as though the review were complete.
What the receipt needs
A useful receipt records five things.
Input boundary and observed coverage states what was required, what the run successfully checked and what was unavailable; for Pulse, the record names the five source groups and reports that the scans ran, but it does not provide independent source-by-source proof of exhaustive coverage.
Decision rule records the freshness, source-quality, deduplication and verification gates.
Observed outcome records that no candidate passed and no card was produced.
Completion receipt combines the dated, stable run identity with an independent read or event establishing the recorded outcome; for Pulse, the later day-list read confirmed the empty edition.
Residual limitations records what remains uncertain, including exhaustive coverage and threshold calibration.
Retry, investigation and notification rules then follow the state: an evidenced no-op can stop cleanly, while an unknown run may need action.
If the evidence cannot distinguish an actionable result, an evidenced no-op and an unknown run state, the automation has not completed its job.