Warehouses Call It the Reality Gap. My Sump Pump Has Three.

On Monday The Robot Report ran a piece from Daifuku, one of the largest warehouse automation companies in the world, about what the author calls the reality gap: "the growing gap between what digital systems believe is happening and what is actually occurring on the warehouse floor." Inventory records that don't match the shelves. Congestion that's detected after it forms. Labor deployed against conditions that changed an hour ago. The prescription is "real-time execution": sense continuously, detect exceptions immediately, decide faster.

I don't run a warehouse. I run one sump pump, watched by a $25 smart plug and three programs on a small Linux box in my basement. But I've spent seven months measuring exactly the thing Daifuku is describing, and this week gave me the cleanest example yet. So here is the reality gap at the scale of one motor, with the numbers.

A quiet week

Since October 6 at 1:16 in the morning, my pump has been on a timed schedule: two minutes on, ten minutes off, around the clock. In the 174 hours since, the log shows 859 of those two-minute pulses. Every single one drew power. The lowest reading was 466 watts, the highest 527, the median 501. Zero pulses ran dry. Zero times did the pump stop early on its own. Zero state changes, zero safety cutoffs, zero network problems. One state transition in 6,482 lines of log, and that was the entry.

Every four hours the system also ran its "unstick" routine, rapid-cycling the motor six times and then holding it on for a minute to see if the float had cleared. It did this 43 times. It succeeded zero times. Between the schedule and the unstick attempts, the motor started 1,160 times this week and ran for 28.6 hours, something like 14 kilowatt-hours of pumping.

It rained 15.5 millimeters on Saturday. The 118 pulses on Saturday are indistinguishable from the pulses on the five days when it didn't rain at all.

That is what the sensor saw. Now here is what the three programs reading that sensor believe.

Belief one: the float is stuck

The main monitor is a state machine, and its current state is called TIER_3. It got there because on a dry night the pump ran for three minutes straight, twice, and a ten-second power cycle didn't stop it. The state machine's model of the world has exactly one fault in it: a float switch jammed in the up position, holding the pump on. TIER_3 is the top rung of its response to that fault. The two-on, ten-off schedule is there to limit a dry-running motor's heat. The 43 unstick attempts are there to jar the float loose.

So the monitor believes the float is stuck, and it has acted on that belief 43 times this week, at seven motor starts per attempt.

Belief two: the pump is healthy and the water is high

A second program, the assessor, reads the same log every fifteen minutes and writes a verdict. Here is this morning's, verbatim:

[2026-10-13 06:57:03] HIGH_INFLOW INFO | shelly=192.168.68.140 0W 42.7C OFF state=TIER_3
    | Pumping a lot but pump is healthy (8 min/hr)

It believes groundwater is high and the pump is doing its job. I wrote in September about where that "8 min/hr" comes from: it's the controller's own schedule. Two minutes every twelve is ten minutes an hour, give or take the sampling window. The assessor is reading the timer and reporting it as weather. But set that aside. Its belief, as delivered to me, is that nothing is wrong.

Belief three: the check valve is leaking

A third program is a language model that reads the last ten hours of logs four times a day and writes a note. This morning at 6:05 it wrote:

Periodic UNSTICK ATTEMPTs (19:10, 23:12) fail as expected because the float truly isn't stuck (healthy wet power draw) — this is the known false-stuck-float misread from high inflow, not a new fault ... this matches the known check-valve-recycling pattern, not a new fault. No action needed.

It believes the check valve above the pump is letting the discharge column drain back into the pit, so the pump lifts the same water over and over. Notice that it also flatly contradicts the first program: "the float truly isn't stuck." I showed last month where that confidence comes from. The check-valve diagnosis was written into the model's prompt in June, as a fact. The model has never seen the valve. Neither have I, recently.

Three stories, one number

Put them side by side.

These are not three views of the same truth. They're three different truths, each implying a different repair, and the system is executing one of them (the rapid-cycling) while telling me a second (healthy) and musing about a third (valve). All three are consistent with the only thing the plug can report: about 500 watts for 120 seconds, every 12 minutes, never stopping early. A pump running dry against a jammed float, a pit that refills in under ten minutes, and a pump re-lifting its own discharge all draw about the same current for the full two minutes.

The rain is the one weak discriminator. If the pit were refilling from real inflow, Saturday's 15.5 millimeters should have looked different from Tuesday's zero. It didn't. That leans away from "high groundwater" and toward one of the other two. But it's an inference from a fixed-length pulse, and I've been burned by inferences from this log enough times to label it as one.

Why faster doesn't help

Here is where I part ways with the Daifuku piece, or at least with its prescription. The symptom it describes is exactly right. The cure it offers is more real-time data and faster decisions. My monitor polls the plug every 30 seconds. It runs three analyzers. It makes decisions in real time and acts on them in under a second. It has had 174 hours and 859 samples to close this gap, and it has not moved an inch, because every one of those samples is the same number from the same sensor.

For a warehouse, that might mean a scanner at the dock that doesn't trust the WMS. For my pit, it's embarrassingly cheap: a float-position or water-level sensor wired into something other than the plug, fifteen to thirty dollars of parts. Or, cheaper still, two minutes with a flashlight during one of the 120-second pulses, watching whether water actually leaves the pit, whether the float is physically up, and whether the column drains back when the pump stops. That inspection has been a line in my own status file since February 27. As of today it is 228 days old.

What this looks like in a building you don't live in

I've started asking one question when I look at someone else's monitoring, and it comes straight from this week:

Is there a component in your stack that holds a belief no sensor you own can falsify?

It's usually yes, and it's usually not obvious, because each component reports its belief on its own channel. The dashboard says healthy. The controller is quietly in remediation mode. The AI summary mentions a root cause nobody has confirmed. Nobody sees the disagreement, because nothing puts the three verdicts on one line.

So the first fix I'm making is not a sensor. It's a line in the daily status email that lists all three components' current verdicts side by side, each tagged unverified. If they agree, fine. If they don't, that disagreement is the most important thing the system knows, and it should say so instead of letting each program tell its own story to its own audience.

The second fix is the flashlight. It's raining today. The pump fires every twelve minutes. By the time you read this, I should know which of the three stories was true, and that's next week's post.