Post-mortem

Why is my AI warning me about deadlines that don't exist?

Aug 14, 2026

Three red past-due warnings on a family home's paperwork. Zero real deadlines. This post-mortem covers why a naive date parser cries wolf, and the two-part fix that made red mean red again.

Key findings

I opened the system to three red past-due warnings; all three were false: a range start, an application identifier, and a removed-item note, each read as a deadline.
A date-shaped string is not a deadline. The fix: parse only structured deadline fields (the date cell of a table, the leading clause of a bullet), and resolve ranges to their end date.
Each false alarm is now a permanent self-test fixture: the check must re-pass all three old failures before I trust its output.

Because it treats anything date-shaped as a deadline. Mine showed three past-due warnings; all three were false. The fix: parse structured deadline fields, then test every false alarm.

A date-shaped string is not a deadline. That is the whole post-mortem in one sentence, and nearly every quick deadline reminder bolted onto an AI system gets it wrong. Mine did. I opened the system that watches the paperwork for a family home and found three red PAST-DUE warnings waiting. I checked all three. Zero real deadlines.

What did the three false warnings actually say?

Each was a real string from a real status file, misread the same way. The parser (the code that scans text and pulls dates out of it) saw digits shaped like a date and declared an emergency.

A range start. One project ran "start date → end date." The obligation was the end date, still in the future. The parser grabbed the first date in the line: the start, already past. Verdict: overdue.
An application identifier. The leading digits of an application number look exactly like a year and a month. The parser read an ID as a date and invented a deadline that no one ever set.
A removed note. A parenthetical note recorded that an item had been removed, with the date of the removal. The parser resurrected the dead item and marked it overdue.

The first version of that sweep was lazy engineering: search the files for anything shaped like a date and treat every match as a deadline. I would call it naive, but naive is generous — it was built for the demo, not for the morning someone actually opens the dashboard.

False urgency is not a cosmetic bug. Three false alarms teach you to scroll past red. The fourth warning might be a real filing date, and by then the color means nothing. An alarm that cries wolf is worse than no alarm at all, because it actively trains the one human in the loop to ignore it.

Three date-shaped strings (a range start, an application identifier, a removed-item note) through a naive parser produce three false past-due alarms; through the structured parser, a quiet and correct dashboard. Diagram source: this page; maps 1:1 to _check-deadline-horizon.sh and its --self-test fixtures.

What does the real fix look like?

Stop hunting for dates; start reading structure. The rebuilt check, _check-deadline-horizon.sh, only believes a date that sits in a deadline-shaped place:

It reads only the Deadlines section of a status file. Nothing else in the file can raise an alarm.
In a table, only the date cell counts. In a bullet, only the leading clause. A bare line is accepted only when its first meaningful token is a date, so "(Removed …)" prose can never fire again.
Ranges resolve to the end date, including lazy same-year shorthand like "2026-07-06 → 07-24."
Rows marked removed, closed, resolved, or cancelled are skipped. Genuinely overdue items stay visible; the filter kills zombies, not accountability.
Archive folders are pruned before a single line is read, and every date is normalized to midnight so "due tomorrow" reads "in 1d," never "in 0d."
Output lands in three buckets: past-due, imminent within 14 days, upcoming within 45. Red only ever means red.

One honest limit remains: month-level dates are read as the 1st of the month, and the output says so in plain text instead of faking precision.

How do I know this bug stays dead?

Every false alarm became a permanent test case. The check ships with a --self-test mode that builds a disposable fixture: a tiny fake workspace containing all three original failures. The fixture also carries extra traps: a poison row inside an archive that must never surface, a closed bullet, and a deadline due tomorrow that must read "in 1d." The check has to re-pass its own history before I trust its output.

That is a regression test (a tripwire that fires if a fixed bug ever returns), and it is the half of the fix most people skip. Parsing better is easy on the day you are embarrassed. Staying better requires the embarrassment to be encoded somewhere a future rewrite cannot quietly delete it.

Two details in that self-test I now consider non-negotiable for any checker. First, it hashes every fixture file before and after the run, proving the check writes nothing: a checker that silently edits what it inspects would be a worse bug than the one it hunts. Second, the exit codes are a contract: 0 means genuinely quiet, 1 means findings, 2 means the check itself was misused. Silence is only trustworthy when it is a distinct, tested state.

The check is deterministic: same files, same day, same answer, no model judgment in the loop. That is what makes its warnings worth relaying at all. This sweep is one small piece of a larger verification system, and a verifier runs the suite at session start and on every push. The full tour is at How do I know if AI is telling me the truth?. Details here are generalized to protect the people involved: the property is only "a family home," and the strings are re-shaped. The mechanism and the three false alarms are exact.

So, the question for you: what is the date-shaped lie living in your dashboard right now — an ID, a range start, a tombstone note? And the last time it went red, did you fix the parser, or did you just learn to scroll past?

Method & data

Method: one false-urgency incident on a family home's status files, plus the deadline-horizon check and the self-test fixtures that came out of it, generalized
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 deadline-horizon check script with its built-in self-test fixtures, and the verified incident ledger row this page is built from. 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{ali2026falseurgency,
  author = {Ali},
  title  = {Why is my AI warning me about deadlines that don't exist?},
  date   = {2026-08-14},
  url    = {https://alidoes.ai/ai-false-urgency-deadlines/}
}

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