Every Number in My Config Is Round

The software that watches my sump pump is controlled by eleven numbers. I went and looked at all of them this week, in a row, for the first time.

Twelve rows, eleven distinct decisions, and not one of them is 847 seconds.

Every value in that table is something a person can say out loud. A minute. Ten minutes. Half an hour. Three of something. There is not a single number in my production system that looks like it came out of a measurement, and I know exactly why that is, because I am the one who typed them.

What a Round Number Actually Means

A round number in a configuration file is a fossil. It records the moment somebody needed a value, did not have a way to derive one, and reached for something defensible instead.

Five minutes is not defensible because five minutes is correct. It is defensible because if anyone ever asks, "five minutes" sounds like a decision. Eight hundred and forty-seven seconds would demand an explanation. Three hundred does not, and that is precisely the problem — the number that avoids the question is the number nobody checks.

I want to be careful about what I am confessing here, because there is a version of this that is fine. Sometimes you build the first version of something, you have no data at all, and you have to start somewhere. Round numbers are the right way to start. They are honest placeholders. Everyone builds this way.

The problem is what happens next, which is usually nothing. The system works. The placeholder becomes the value. Two years go by.

The Far End of the Same Idea

This week I read a research writeup that is nominally about something completely unrelated to basements, and it is the reason I went and looked at my own config file.

The setup: when you want to run a neural network on small hardware — the kind of chip that goes in a sensor rather than a server — you have to shrink it. The standard way is to reduce the precision of the numbers inside it. Instead of storing each value in 32 bits, you store it in 8, or 4. A human picks that number. It is almost always 8, because 8 is a nice number and the hardware likes it.

Engineers at Imagination Technologies asked what happens if you stop picking. In their approach, the precision of each part of the network becomes something the system learns, trained alongside everything else, with a penalty attached so that being large costs the network something. It has to pay for its own precision out of the same budget it pays for accuracy.

What comes out is not a uniform setting. On the small language model they tested, the first block held onto more than half of its parameters. Five blocks deeper, the attention layers threw away more than ninety-five percent of theirs. Average precision across the whole model fell from four bits to roughly half a bit.

I have no idea whether that method would help my sump pump, and I want to say clearly that most of what I have is the published summary rather than the full results. That is not why it matters to me.

It matters because of the shape of the answer. No human would ever have configured that network the way it configured itself. Fifty percent here, five percent there, a different value in every layer. A person picks one number and applies it everywhere, because one number is what a person can hold in their head and defend in a meeting.

Which is exactly what I did, eleven times.

The Two Years I Had and Did Not Open

Here is the part that stung.

Two of those eleven numbers are the ones I care most about. My monitor tracks how long it has been since the sensor last reported. Five minutes of silence raises a warning. Thirty minutes is critical. Those two constants exist because a sensor that has died and a pump that is behaving perfectly produce identical output — which is to say, nothing — and I wanted the system to know the difference between calm and deaf.

I have written admiringly about that feature. I still think it is the most important twenty lines in the project.

But I have two years of recorded history from that pump. Two years of exactly how long that sensor actually goes quiet on an ordinary Tuesday, what a real network hiccup looks like versus what a failing device looks like, where the ordinary gaps cluster and where the alarming ones begin. All of it on disk. All of it collected by me, on purpose.

And when I needed a warning threshold, I typed 300, because five minutes is a nice number.

I have spent a fair amount of time recently telling anyone who will listen that this dataset is the most valuable thing I own — that anybody can buy the same sensors and download the same software, but nobody else has the record of what one specific 1960s basement does at four in the morning in March. I believe that. It is true.

It is also a slightly grand way to describe a folder I was not opening. The value of having your own data is not that it makes you defensible in the abstract. The value is that you do not have to guess. I had the data and I guessed anyway, and I got to feel sophisticated about the data while doing it.

Why This Should Matter to Someone Who Owns a Building

You are not going to audit anyone's source code, and you should not have to. But there is a question underneath all of this that you can ask on a phone call, and almost nobody asks it.

Every monitoring system you will ever be sold contains numbers like mine. A threshold at which it decides your equipment is behaving badly. A delay before it decides a sensor is dead. A count of how many odd readings add up to a problem. Those numbers determine everything you will experience: how often the thing wakes you up, and whether it wakes you up for the failure that actually matters.

So the question is simply: where did those numbers come from?

There are three honest answers, and they are not equally good.

1. "They came from your equipment." The system watched your building, learned what normal looks like there, and set its own thresholds from that. This is the good answer. Ask how long the learning period was and what happens if your equipment changes.
2. "They came from our other installations." Defensible, and much better than nothing, as long as those installations resemble yours. A threshold tuned on new commercial HVAC is a poor fit for a sixty-year-old residential pump, and vice versa. Ask what the reference installations looked like.
3. "They're industry standard." Sometimes true. Usually this means somebody picked a round number once and it survived. It is the same answer as "five minutes," wearing better clothes.

A follow-up that cuts through all three: if my building turns out to be unusual, what specifically changes, and who changes it? If the answer involves a support ticket and a firmware release, the thresholds are not really yours. If the answer is that the system re-derives them from your own history, you have bought something that gets better by sitting there.

What I Am Actually Doing About It

I had a task on my list for the past week to benchmark a compressed version of my detector against the full-precision one. Classic engineering busywork: measurable, bounded, satisfying, and aimed at the wrong layer entirely. Most of my system's decisions do not come from a neural network at all. They come from that state machine and its eleven hand-typed constants. I was going to spend a day optimizing the one part I had not guessed at.

That task is dead. Here is what replaces it.

First, the two sensor-silence thresholds get derived instead of assumed. I am going to pull the actual distribution of reporting gaps out of two years of logs and look at where the ordinary silences live and where the real failures start. If the data says five minutes was right all along, I will keep 300 seconds — and write down why. A number I have defended and a number I got lucky with are not the same object, even when they are the same integer. Right now I cannot tell you which one I have.

Second, that reasoning goes into the customer report. I committed last week to putting a coverage figure in every report — what percentage of the month the system actually had eyes on your equipment, with every gap itemized. That is still coming, and it is still the most important thing on my list. But the report that tells you how much of the month I was watching should also tell you where the line between "quiet" and "not watching" came from. Those two facts belong on the same page. One is meaningless without the other.

Neither of those is a hard afternoon. Which is the honest summary of this entire post: the work was never difficult, it was just never urgent, because a round number in a config file never breaks anything loudly enough to get itself fixed.

A network that has to pay for its own precision ends up with a configuration no human would have written. I am not going to get there with eleven constants and a basement. But I can at least stop pretending that "five minutes" was a decision.