alidoes.ai

All writing

Post-mortem

Why did my AI treat an expired decision as live? My inbox merged two years into one thread

My email client decided two conversations from different years were one thread. The AI that read it inherited the lie: an expired decision came back labeled live.

Key findings

  • Email threading is a data-modeling decision someone else made for you. Mine glued unrelated conversations from different years into one thread.
  • The AI reading the glued thread inherited the lie: an expired decision looked live, because the thread's newest message spoke for every message inside it.
  • The fix is three separate fields: event_date, thread_id, and outcome_state. The false urgency disappeared; the record survived.

My email client glued conversations from different years into one thread. My AI trusted the thread's newest timestamp and resurrected an expired decision as live. The fix: three separate fields.

Details here are generalized to protect the people involved; the pattern is exact. And the pattern will find you, because your email client's threading is a data-modeling decision someone else made for you. You never chose it, you can't see it, and your AI inherits it whole.

One glued thread vs three separate fields One glued thread vs three separate fields WHAT THE EMAIL CLIENT DID Decision email earlier year · expired New, unrelated mail recent · different topic → → One glued thread newest message dates it → Expired decision looks LIVE false urgency, old filename THE THREE-FIELD FIX event_date when it really happened thread_id which conversation it is outcome_state EXPIRED · stated, not inferred No false urgency · the record survives · no field trusts the thread's newest date
The failure and the fix: the client glues an expired decision from an earlier year to new, unrelated mail, and the thread's newest date makes the expired decision look live. Separating event_date, thread_id, and outcome_state removes the false urgency and keeps the record. Diagram source: this page; maps 1:1 to the three-field fix recorded in the incident ledger row.

How does an email thread lie about time?

Threading is a heuristic (a rule of thumb, not a guarantee). Clients group messages by reply headers and subject-line similarity, and mostly that works. When it fails, it fails big. Mine joined two conversations that had nothing to do with each other, from different years, into one thread. I call it the time-trap thread.

The grouping mistake became a time mistake through one mechanism: inboxes sort threads by their newest message. Once the old conversation was glued to the new one, the whole object wore a fresh timestamp. A decision that had been made, closed, and left to expire in an earlier year floated to the top of the inbox looking current. It was still sitting under its old filename, which made it read as a live document instead of a fossil.

I'll make the critical judgment plain: threading by subject similarity is a bad default for anything that has to reason about time. It optimizes for tidy reading, and it quietly rewrites when things happened in order to get it.

Why did my AI believe the time-trap thread?

Because I handed the thread over as context (the material the model reads before it acts), and the thread was already lying. The AI read it top to bottom, saw an old decision sitting beside recent mail under a fresh date, and reported the decision as live and urgent. Every individual fact it stated really was in the thread. That is exactly what made it convincing.

This was not a hallucination (a confident, made-up answer). The model invented nothing. It faithfully summarized a corrupted container. Had I skimmed the same glued thread, I would have reached the same wrong conclusion — the AI just got there faster and stated it with more confidence. The failure lived upstream of the model, in a data-modeling choice I never made.

Most "the AI got it wrong" stories stop at the model. This one can't. You cannot prompt your way out of corrupted context; you have to fix the data. That is the same lesson, from a different direction, as the rest of my verification setup: treat what the AI reads as an input to check, not a given.

What does the three-field fix look like?

Pull apart the three things the thread had collapsed into one, and record each in its own field:

The incident ledger records the result in one line: "Separating event date, thread identity, and outcome state removed false urgency without losing the record." That row is the receipt this page is built from, and it names both halves of the win. The urgency was fake, and it's gone. The record was real, and it stayed.

Note the restraint in the fix. I didn't fight the provider's grouping or migrate to a different client. The glued thread stays glued in the mail client; it just no longer gets to speak for time or state, because those now live in fields the threading can't touch.

Where else does this trap hide?

Anywhere a container aggregates items: a chat channel, a shared folder, a running doc with updates appended at the bottom. The moment your AI reads the container as one object, the newest item starts speaking for the oldest. Any schema (the structure that says which fields exist) that collapses time, identity, and state into "the thread" will eventually manufacture urgency out of nothing. Or it will bury something that is genuinely urgent, which is worse.

So the question I'd put to your setup: which container does your AI read as a single object, and what happens the first time its newest item speaks for its oldest one?

Method & data

Method: one generalized inbox incident from the system's ledger: an email provider joined unrelated conversations from different years, an expired decision surfaced as live under an old filename, and separating event date, thread identity, and outcome state fixed 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 incident ledger row that logs the glued thread, the expired-decision misread, and the three-field fix. 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{ali2026timetrap,
  author = {Ali},
  title  = {Why did my AI treat an expired decision as live? My inbox merged two years into one thread},
  date   = {2026-08-14},
  url    = {https://alidoes.ai/email-thread-time-trap/}
}

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