alidoes.ai

All writing

Post-mortem

Why was the check green while ten records were missing?

The health check asked one question: does the shared folder exist? It did. Ten governed records were gone anyway. This is the post-mortem of a green light that proved almost nothing.

Key findings

  • A registry reported green while ten records were absent: its health check verified only that a shared folder existed.
  • Existence checks prove the container, not the contents. This one was worse than no check, because it paid out calm it never earned.
  • The fix is bidirectional parity: every ledger row must have its record, every record its ledger row, and the timelines must agree — so absence turns red and gets named.

The registry reported green because its health check asked one question: does the shared folder exist? It did. Ten governed records were missing, and the check could not see them.

Existence checks are how monitoring lies to you. They prove the container is there and say nothing about the contents. This one was worse than no check at all: no check leaves you nervous, which is at least honest. A green existence check pays out calm it never earned.

How does a green light hide ten missing records?

The registry is a ledger, a plain list naming every governed record the system holds. Governed means the system has promised to track it, check it, and account for it. One row per record. The health check over all this was written the way most health checks get written: look for the shared folder that holds the records, and if the folder is present, report green.

Read that as two claims. Green was understood to mean "every governed item is accounted for." What the check actually proved was "a folder with the expected name exists." The gap between those two sentences turned out to be ten records wide.

Nothing looked wrong and nothing warned. The records were simply absent, and absence is the one condition an existence check is structurally blind to. You cannot notice a missing thing by inspecting the container that was supposed to hold it. You have to go looking for each thing by name.

I would like to hand you the forensic detail of how the ten went missing. I can't: details are generalized to protect the people and systems involved. What the incident's ledger row states plainly is the part that transfers. Ten records absent. Status green. Cause: the check verified only that a shared folder existed.

Existence check vs bidirectional parity check What green actually proved, before and after BEFORE · one-way existence check check asks: folder exists? → answer: yes → status: GREEN 10 records missing never examined AFTER · bidirectional parity every ledger row → its record + every record → its ledger row + timelines agree → 10 missing records = RED, each named absence is detectable The folder question is now one input, not the whole test.
The same registry under two checks. The existence check proves a folder is present and reports green with ten records missing; bidirectional parity proves every governed item is accounted for, so absence turns red and gets named. Diagram source: this page; maps 1:1 to the record-to-ledger and timeline parity check this post describes.

What does a check that can actually see absence look like?

It runs in both directions. That is the recorded fix: bidirectional record-to-ledger parity. Parity is the boring word for a strong claim — two lists that must match, item for item.

Direction one: every row in the ledger must have its record. That catches this incident's failure. A record that vanishes now turns its ledger row into a red flag with its name on it.

Direction two: every record must have its row in the ledger. That catches the quieter cousin — a record that exists but was never brought under governance, invisible to every report built on the ledger.

One direction alone is just an existence check with better aim. Both directions together mean neither list can drift from the other in silence.

The ledger row records one more guard: timeline parity. The history the ledger claims and the history the records carry have to tell the same story, so a record cannot quietly acquire a past the ledger never saw.

After the change, the folder question still gets asked. It is just no longer the whole test. "The folder is there" became one input to a check whose passing condition is the sentence green had been pretending to mean all along: every governed item accounted for, by name. Ten missing records now mean a red that lists all ten.

Why do existence checks survive so long in real systems?

Because they are cheap to write, they pass on day one, and green trains you to stop looking. Every monitoring stack accumulates them. The file exists. The endpoint returns 200. The table is not empty. The job wrote a log line. Each of these proves a container. None of them proves contents.

Here is the one-minute test I now run against my own checks: name a failure this check would stay green through. If "the contents are gone" is on that list, you own an existence check, whatever its dashboard label says.

This post-mortem is one slice of a larger discipline, the reason my whole setup exists: how I know the AI is right. You cannot build a system that never fails. You can refuse to let it fail silently, and an existence check is a silent-failure generator with a green light on top.

So, the question I would ask about your stack: what would stay green tonight if ten of your records quietly walked away?

Method & data

Method: one incident from the live system's assurance ledger: a registry health check that reported green while ten governed records were absent, and the bidirectional record-to-ledger and timeline parity that replaced it
Data: patterns and methods only; no names, dollar figures, addresses, case identifiers, or confidential content · Last checked: 2026-08-14

How this was made

AI-drafted, adversarially checked, human-directed. My AI assistant wrote this from the system's own records — the assurance ledger row that recorded this incident: the green-while-absent failure, the count of ten, and the parity fix that closed it. A separate AI session then tried to break every claim against those records, and automated privacy and readability gates ran before publish. I direct this pipeline, own every boundary in it, and audit published pages on a rolling basis — if you find an error, tell me and it goes in the corrections log, dated, never silent.

I'm Ali — I run real life-and-work admin on AI agents, then check their work in the open. More at /about.

Published under my standards. Found an error? Tell me — corrections go in the corrections log, dated, never silent.

Cite this

@online{ali2026greencheck,
  author = {Ali},
  title  = {Why was the check green while ten records were missing?},
  date   = {2026-08-14},
  url    = {https://alidoes.ai/green-check-missing-records/}
}

Caught something I got wrong? Send it directly. Confirmed corrections go in the corrections log.