Sessions Scoring Under 0.6 Pile Up Forever Without One Rule

Sessions in the archive pipeline get sorted by classification confidence. Above 0.9 they auto-stamp. From 0.6 to 0.89 the classification is applied but flagged for review. Below 0.6 they go straight to a reconciliation queue. Low-confidence classification, a parser that choked on an odd export, a session tagged to the wrong epic: every one of those needs a human eyeball at some point. Our first instinct was the obvious one: build the queue, route the uncertain items there, and don’t consider anything done until it hits zero.

That instinct is wrong. We only found out because we asked a second model to design the reconciliation layer before we built it, and it talked us out of our own plan.

The design that looked responsible

Queue-zero sounds like discipline. You don’t let unresolved things pile up, you clear them, and the system stays honest. We were already picturing the file: Reconciliation_Queue.md in the archive, every ambiguous classification landing there, and a rule that said the pipeline isn’t trustworthy until that file is empty.

The problem is that we run the archive pipeline, the classification layer, and the actual business on the same clock, with nobody else free to own any one of them. A queue that has to hit zero before you trust the system competes with everything else you’re supposed to be doing. It doesn’t stay small. It becomes a second inbox, and unlike email, nobody else is going to triage it for you.

What the second model said instead

We asked for a review of the whole conversation-archive architecture: seven decisions, five open questions. Buried in there was the reconciliation queue question, framed as a binary. Either gate on queue-zero, or let queues self-decay on inactivity.

The answer was blunt. In a single-user system, if you haven’t reviewed a low-confidence classification or a minor parser failure within seven days, it probably doesn’t matter. Gating work behind queue-zero will paralyze you. Accepting entries as compost means the queue grows forever and becomes cognitive drag. Self-decay keeps the queue showing only what’s recent and potentially relevant, and lets the rest fall into the archive.

That reframes what the queue is for. It’s a spotlight on what’s unresolved and recent, not a ledger of everything unresolved. Once something ages out, it stops being a task and becomes history. Nobody has to close it, because closing was never the point.

What no decay would have done to the tiers

We had built the same trap once before without naming it. Without decay, every session that ever scored under 0.6 sits in that bottom tier forever, waiting on us. Across weeks of running several provider archives through the pipeline, that number does not stay small.

Self-decay changes the shape of the failure mode. Instead of an ever-growing list you’re supposed to feel guilty about, you get a rolling window. A classification that has sat for seven days without anyone touching it wasn’t important enough to touch. It ages into the archive, un-triaged, and that’s fine. The record still exists. We just stopped being the bottleneck it was waiting on.

The same logic showed up in memory

The review didn’t stop at the reconciliation queue. It hit the same tension in agent memory: patterns should graduate into archive docs when they solidify, and anything untouched for 90 days should expire into cold storage rather than sit there rotting in the active file. Same shape, different layer. A system that never lets anything decay accumulates weight until you can’t move.

Every queue eventually asks you to define “done,” and if “done” means empty, you’ve built something you can’t sustain. Decay is what lets the system keep working without turning into a second job of clearing its own backlog.

We still haven’t hit queue-zero on the reconciliation file. We’re not supposed to. Our rule now is that a low-confidence item gets seven days of attention and then ages into the archive, so what we look at is what is recent and still relevant.

dxdev LESSON · paste into your AI coding agent
LESSON: A review queue that must hit zero to be trusted becomes a second job; letting it decay on inactivity keeps it a spotlight instead of a debt
SOURCE: dxdev.com/blog/the-reconciliation-queue-trap
WHAT HAPPENED: A pipeline routed low-confidence classifications and odd failures to a reconciliation queue, with an implicit rule that the system wasn't trustworthy until that queue reached zero. Run alongside the actual business by too few people to sustain it, that design competes with everything else and grows into a second inbox nobody else is available to triage. An external design review reframed the choice as binary, gate on queue-zero or let queues self-decay on inactivity, and recommended decay: anything untouched after a fixed window of about seven days ages out into the archive un-triaged rather than sitting as a permanent obligation, on the reasoning that in a small enough system, if nobody has touched something in that window, it probably did not matter enough to need touching. The same shape, graduate into permanent documentation when a pattern solidifies, expire into cold storage after a fixed period of inactivity otherwise, applied equally to agent memory.
THE RULE: Any queue whose definition of done is empty, maintained by too few people to sustainably clear it, will eventually become the bottleneck rather than the safeguard; letting unclaimed items decay after a fixed window of inactivity turns a growing debt into a rolling spotlight on what is actually recent and worth attention.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
      1. Any review or reconciliation queue whose system-level trust or completeness is defined as the queue reaching zero, maintained by a team too small to sustainably clear it.
      2. Any accumulating list of flagged items, low-confidence records, or exceptions with no automatic decay or expiry after a period of inactivity, so it can only ever grow.
      3. Any queue being treated as a permanent ledger of everything ever unresolved rather than a bounded, recent view of what might still need attention.
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.