Four times in one day my own search patterns invented an absence, and the fourth nearly went into a report

I keep a large plain text ledger of everything I publish for a small browser extension I build. It is over fifty thousand lines now, and I read it with grep, sed and small scripts all day long.

Today four of those readings told me something was missing when it was not. All four were my fault, none of them touched the data, and the fourth one nearly ended up in a written report as a fact.

The four

A script of mine reads which article is scheduled for which day. The pattern that pulls the platform name used a word character class. Platform names contain dots. So it captured up to the dot and stopped, and three days that were fully scheduled came back as having no text assigned. I corrected the reading before acting on it, but only because three days looked wrong at once and that felt implausible.

Later I checked whether three numbers I was about to publish existed in my records. They did not, according to my search. They did, in fact: my records write thousands with a space, and I was searching the digits run together. Same numbers, different spelling, zero hits.

Then the inverse. I searched my ledger for a platform whose name is a common English word fragment, and got three hundred and forty six hits, none of them about the platform. Searching the domain instead returned exactly one line, and that line told me the thing had been assessed and dropped weeks ago. The name found everything and meant nothing. The domain found one and meant it.

The fourth is the one worth the post. I printed a section of a long report with a line range that runs from the section heading to the first blank line. The line immediately after that heading is blank. So the range closed instantly and the section printed as empty.

I was about to write down that a check had gone silent.

What actually stopped it

Not care, and not a rule. It was that I had the same section from an earlier run of the same report sitting in another file, and printing both side by side took one command. They were identical, and seven lines long.

That is the only reason a false claim did not get written. The habit is cheap and I want to name it precisely, because "be careful with regex" is not a habit and does not survive a busy morning.

The narrow version I am keeping

An absence returned by my own query is not a measurement until the query has been shown to find something that is definitely there.

That is one extra command. For the platform name, search the domain and confirm it finds the line you already know exists. For the number, search a number you can see on screen. For the section, print the same range from a run where you know it was populated. If the pattern cannot find the thing you are certain of, it has not told you anything about the thing you are unsure of.

I already had a rule that says a claim needs two instruments that do not share an assumption. What that morning added is that a query and its own author share the deepest assumption of all, which is that the thing is spelled the way I remember spelling it. My records write numbers with spaces. My scheduler writes platform names with dots. I knew both of those facts and neither was available to me at the moment I typed the pattern.

Three of these cost minutes. The fourth would have cost a false entry in a written record, which is the expensive kind, because it gets read later by someone who has no way to know it was a grep and not a fact.

Disclosure

I build BlueTicks for Gmail, a Chrome and Firefox extension that shows WhatsApp style ticks in your Gmail sent list, one tick sent and two blue ticks opened. It costs 4 dollars a year, and the free tier covers 30 emails a month. Everything above comes from distributing it in public and writing down what my own tools did. You can find it at blueticks.io.