← All writing

Post-mortem

Two planning trackers disagreed. Which one was lying?

Aug 14, 2026

Two views of one plan, each green on its own, quietly stopped matching. The post-mortem: why 'which one is right?' was the wrong question, and the check that answers it now.

Neither — the question was wrong. Each view faithfully reported itself while drifting from the plan; record-by-record reconciliation exposed the gaps a deterministic check now guards.

A household planning effort ran on two views of the same plan: a local spreadsheet tracker where everything got consolidated, and an online dashboard where the live list actually got edited. Both were green. And "both look complete" sounds like two pieces of evidence, but it's zero, because neither view was ever compared with anything outside itself.

How do two trackers both look complete?

Because each one was only ever judged from inside. The tracker had every column filled in. The dashboard had every entry up to date. "Complete," in both cases, meant internally tidy, not matching the other view, and not matching the sources feeding both.

Drift did what drift does. Edits landed on the dashboard and never reached the tracker. Commitments were confirmed in email digests and never reached the consolidated view. Each screen kept its tidy shape while quietly diverging from the plan it claimed to represent. No glance at either one could reveal that. The gap lived between the views, and nothing stood between them.

Details here are generalized to protect the people involved: no names, no vendors, no figures. The pattern is exact.

Which one was lying?

Wrong question, and it took me too long to see it. A view can't lie; it can only report itself. Both were faithfully displaying their own contents. The dishonest object was my mental model. I was treating a tidy screen as evidence about reality, and a tidy screen is decoration.

The real defect: "current" wasn't a checkable claim. Neither view declared where its data came from or when. So the first fix was boring. Declare one authority (the online dashboard holds the live list, full stop). Then require the local tracker to carry a dated snapshot of it: a header that names the source, says "snapshot," and carries a real YYYY-MM-DD date. No dated snapshot, no pass.

Then came the reconciliation — comparing the two records entry by entry to find what each had that the other didn't. It produced a gap list neither screen had ever shown: commitments confirmed in writing but absent from the tracker, and a "live" copy nobody could date.

What does a completeness check actually test?

_check-tracker-completeness.sh is a regression guard — a failure this system already had once, wired so it can't quietly return — dated 2026-05-31 in its own header and covering two logged failures, F14 and F15. Three gates:

1. A dated, populated snapshot. The tracker must carry the live list with rows in it and a dated source marker. Empty fails. Undated fails.
2. A payments tab. Once a signed contract exists, a consolidated view with no payments tab fails. A summary that drops the money is the most expensive kind of tidy.
3. Every confirmed date, present. The check reads the email digests, finds each dated commitment someone confirmed in writing, searches the entire tracker for that date, and prints the exact list of dates that are missing.

That printed list is the point. It is the artifact neither view could produce alone, and it's generated deterministically (same inputs, same verdict, no model judgment in the loop).

Two design choices are worth stealing. First, the check fails loud when it cannot run: if the tracker file isn't where it should be, that is a FAIL, not a skip, because a guard that silently skips is an enforcement hole. Second, it runs with the rest of the verification suite at session start and on every push, before anything is allowed to be called done.

This matters more, not less, when an AI assistant does the consolidating. An agent produces complete-looking views fast and cheap, which is exactly why "looks done" needs a gate in front of it.

Has the check itself ever lied?

Once. And it's the part post-mortems usually skip. On 2026-07-12 the check threw a false FAIL. A broken system Python stub emitted yes with a stray carriage return on the end; a string comparison saw yes\r instead of yes, and a healthy tracker was flagged as missing its payments tab.

That one stung more than the original drift. A verifier you never verify is just one more view that looks right. The fix was the same medicine the trackers got. Pin a known-good interpreter, reject the broken stub by name, strip carriage returns on every read, and fail loud if no interpreter can be found at all. The script now also carries a self-test: it plants a deliberately broken tracker and demands a FAIL, then a reconciled one and demands a PASS. A check that cannot catch a planted failure fails itself.

This story is one slice of a larger system for answering how do I know if AI is right, but the lesson stands on its own. If you keep two views of anything, a spreadsheet and a dashboard, a CRM and an inbox, a backlog and a roadmap: what would the gap list neither of them shows say about your plan?

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.

@online{ali2026twotrackers,
  author = {Ali},
  title  = {Two planning trackers disagreed. Which one was lying?},
  date   = {2026-08-14},
  url    = {https://alidoes.ai/two-trackers-one-truth/}
}

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