Worked examples

What a silent failure actually looks like.

Two worked examples, one for each check. A filing process that stopped running, and a nightly job that ran every night and produced nothing. Same shape both times: what the monitoring showed, what the check asked instead, and what somebody has to decide once it turns up.

These are illustrative examples, not client work. The systems, figures and dates are invented to show the shape of the failure. There is no published case study yet and I am not going to imply otherwise.

Demo 1Expected-run check

The VAT return that never ran

Two quarters where the submission did not execute, did not fail, and did not turn up anywhere as a problem.

The scenario

A finance team files VAT through an integration that pulls the figures, builds the return and submits it. It has run for years and nobody watches it, because there has never been anything to watch: it either posts a completion message or it does not, and it has never once gone red. The person who personally owns the filing obligation is relying on an absence of bad news, which is a different thing from evidence that four returns went in.

How the check runs

Input
The schedule it claims to keep
One submission per VAT quarter
Process
Compare claimed runs against execution records
Scheduler history, not the error log
Output
Every quarter with no execution behind it
Silent, so it raised nothing
Human check
You confirm which gaps are filings
A missed report is awkward. A missed return is not.

Step 1 · What the failure looked like

Illustrative example

The job history, last twelve months

VAT quarter	Job status	Finished at	Alerts raised
Q1	Completed	07 Apr, 02:14	None
Q2	Completed	07 Jul, 02:11	None

Every run in the last year finished cleanly and raised nothing. The two quarters missing from this table are missing because nothing happened, and a record of what happened has no way of showing you that. Nobody counts the rows.

Step 2 · What the check caught

Did anything execute at all?

The same year, with the quarters that never ran put back in

VAT quarter	Execution record	Submission receipt	Verdict
Q1	07 Apr, 02:14	Receipt stored	Ran and filed
Q2	07 Jul, 02:11	Receipt stored	Ran and filed
Q3	No run recorded	None	Never ran
Q4	No run recorded	None	Never ran

The trigger was disabled during a platform migration over the summer and never switched back on. From that point the job did not run, so it did not fail, so it raised nothing and appeared nowhere. There was no error available to catch, because nothing was executing to produce one.

That is the whole failure, and it is why the expected-run check compares the schedule a process claims to keep against the executions that actually exist. It is the only question in the stack that treats 'nothing happened' as an answer rather than as silence.

The exposure

Two returns that were never filed, and a dashboard that stayed green throughout. The fix is an afternoon. The uncomfortable part is that nobody can say when the trigger stopped firing, because the only record of a run is the run itself, and there were not any.

Step 3 · Human check

Finding it is the easy half. These are yours.

Confirm which of these processes are statutory filings and which are internal reporting.
Agree what counts as evidence of filing. An execution record is not a receipt.
Decide who is told, and in what order, before anything is submitted late.
Decide what should have alerted on the absence of a run, and who owns it.

Safeguard

Nothing is changed during a check. Read access to scheduler history and to the submission side, no write access, no production changes. If a finding needs fixing, that is a separate decision you make with the findings in front of you.

What you get

A written list of every unattended process, whether it ran, and whether anything landed. Where something did not, you get the period, the evidence and the exposure. Where everything is fine, that is what it says.

Demo 2Expected-output check

The erasure job that deleted nothing

A nightly retention job that finished green for eleven months and removed no records at all.

The scenario

A business holds personal data under a documented retention schedule: past a defined age, records are erased. A nightly job does the erasing. It has never failed, so nobody has ever looked at it, and the one number that would have given it away is the number nothing records: how many records it actually removed.

How the check runs

Input
What the process is supposed to emit
Deleted records, and a count of them
Process
Assert the output exists and is plausible
Present, non-empty, roughly the right size
Output
Runs that completed and produced nothing
Green, and empty
Human check
You decide how far back it goes
How long has this been true?

Step 1 · What the failure looked like

Illustrative example

Eleven months of a well-behaved job

Run	Duration	Exit status	Alerts raised
12 Nov, 01:00	4.1s	Success	None
13 Nov, 01:00	3.9s	Success	None
14 Nov, 01:00	4.0s	Success	None
The 320 nights before that	3.8s to 4.3s	Success	None

A job that finishes in four seconds every night and never errors reads as a healthy job. Four seconds is also roughly how long it takes to do nothing at all, and there is nothing in this view that tells the two apart.

Step 2 · What the check caught

Did it produce anything plausible?

The same nights, counting what came out of them

Run	Records past retention	Records erased	Verdict
Early Feb, before the change	874	874	Ran and erased
12 Nov	1,184	0	Completed, did nothing
13 Nov	1,190	0	Completed, did nothing
14 Nov	1,203	0	Completed, did nothing

A schema change in February renamed the column the job used to work out what was old enough to remove. The query still ran and still succeeded. It simply matched nothing from that night onwards, so the delete step was handed an empty set and exited cleanly. There is no error anywhere in this, because nothing went wrong in the sense the tooling understands. The job did precisely what it was told.

The expected-output check never asks whether the job succeeded. It asks what came out, and whether that is a plausible amount. Zero deletions on a night with eleven hundred records past their retention date is not plausible, and that implausibility is the only signal that was ever going to catch this.

The exposure

Eleven months of personal data held past the period the retention policy commits to, and a written policy saying it was erased. That is the kind of gap found by a subject access request or an auditor rather than by an engineer, and there is a paper trail claiming the opposite.

Step 3 · Human check

Finding it is the easy half. These are yours.

Confirm the retention schedule the job is meant to enforce, in writing, before anything is deleted.
Agree what a plausible nightly volume looks like, so that zero can be treated as a failure.
Decide whether the backlog is cleared in one pass or in stages, and who signs that off.
Work out what was said to whom while the job was reporting success.

Safeguard

The check reads. It deletes nothing and it changes nothing about the job. What to do with eleven months of records that should not exist is a legal and commercial decision, not an engineering one, and it stays with you.

What you get

The date the output stopped being plausible, the evidence behind it, and a check you can keep running afterwards so that the next time the answer is zero, something says so.

Start with the audit

Which of yours would this find?

Pick the process you'd least like to have quietly stopped, and tell me how you'd currently find out. If there isn't an answer to that, it is the one to check first.

Show me what isn't running How the audit works

Five days, fixed fee. You get a written findings document.