The detector

Half the plan got deleted and four things survived — and of those, exactly one was newly built: the detector.

The other three were existing things tidied up: index always-injected with bodies on demand, appending unprocessed at session end, weekly human-gated consolidation. Only the detector was a part that hadn’t existed.

Why this one and nothing else

There’s one reason the previous machine could stay dead for months. Producing nothing had no consequence.

If the distiller doesn’t run, the instinct file just doesn’t appear — and sessions run fine without it. A failure with no cost persists, and a persistent failure eventually looks like the normal state.

So the detector’s job is to create a consequence. Do nothing and a notification arrives.

The detector false-positived first

It fired an alarm almost immediately. Its criterion was “last consolidation more than ten days ago” — but during those ten days capture had been working fine.

Consolidation being late and learning having stopped are not the same condition. Consolidation is tidying; information keeps arriving whether or not it happens. One criterion couldn’t separate the two.

So it got a second: the number of memories updated in the last seven days.

Consolidation late	Capture	Verdict
Yes	zero	⚠ Stalled
Yes	alive	ℹ Mild suggestion
No	—	Silent

Both axes have to be bad before it alarms. If capture is alive, it downgrades.

The lesson: the detector’s false positive was a metric problem, not a detector problem. “Time since last consolidation” was chosen because it’s easy to measure — and it’s a case where the easy-to-measure value isn’t the one you wanted. I wanted “has learning stopped”; I was measuring “has tidying happened.”

A detector that cries wolf stops being read after a single false alarm. That can be worse than being dead — a dead thing eventually gets caught, while an ignored one keeps running and stays useless.

The first full run changed nothing

The first time it ran end to end: zero index mismatches, zero missed captures. Nothing to fix, so it updated the marker and stopped.

If continuous capture is working, consolidation coming back as a no-op is the correct outcome.

Had I not written that down in advance, I would have read it as “the loop does nothing” and built something else. Which is exactly the trap this project fell into the first time — reading “nothing happened” as a malfunction and adding parts to fix it.

So writing down the no-op as an expected result is part of the design. Fail to record what success looks like and you will misread success as failure.