Everything That Concluded Was Deleted

In late August I spent four days investigating a database estate I am not going to describe. Collectors ran against it, evidence came back, and a pile of analysis documents grew on top of the evidence. Verdicts, theories, deliverables, recommendation memos, session handoffs restating the findings.

On the fifth day I deleted every one of them. Thirty-three files. Everything that concluded something about the estate went. Everything that measured something stayed. It took about four minutes and it was the most useful thing I did all week.

The commit message says why, and I still think it is the best sentence I wrote that month: the case is being rebuilt from the bottom up.

What Had Gone Wrong

The brief that every agent read at the start of a session had a thesis in it. It told the agent what the conclusion was and that only the evidence for it was missing. I had written that thesis on day one, from a hunch, and by day four the ledger was full of entries that cited only other entries. A finding would cite a theory document. The theory document would cite the finding. A deliverable would restate both. Three documents, one origin, and the origin was me guessing before the collectors had run.

I have seen this pattern in a decision log and in a test suite. This was the third organ, and the one with the most expensive consequences. A wrong conclusion about a production estate turns into a wrong recommendation to real people.

The Reset

The new brief has no thesis in it, deliberately. It says so in its first paragraph.

What it has instead is an evidence contract. Every single fact reported carries four things: a number, a citation, a confidence, and a source. The two are independent, and where a number came from never sets how sure you are of it. A number from the vendor's documentation is not more true than a number from a query because it came from the vendor. A number from a query is not more true because I ran it. Confidence comes from whether the thing was checked, and how, and that is a separate column from where it came from.

If you cannot verify something, write "not verified" next to it. "I didn't check" beats a guess.

Saying a thing is not there needs the same proof as saying it is. A truncated result set and an empty one look identical and mean opposite things. Nobody had written that down before the reset, and at least one early finding said nothing was there when the list had simply been cut off.

What Survived and How

The ledger had 117 entries. Ninety-four were kept. Twenty-three were removed, and the rules for removal are in the commit: entries that cited only other entries, entries taken from a derived index rather than a raw capture, entries that were a guess or built on a guess, and entries that were a verdict sentence with no number in them.

The entries that stayed were kept word for word. Not rewritten, not cleaned up. Rewriting ninety-four entries to strip their framing would have been one more pass of interpretation, and interpretation was the thing being removed.

One entry carried a note about a capture that came from outside. It said the capture was weaker than the repo's own and should not be cited as if it were one. That note was removed too, because it was a judgment about the supplier, not about the artifact. The artifact is what it is. Who handed it over does not change what it contains.

Fault Language

One more rule from the new brief, and it is the one I would carry into any investigation of a system that humans operate.

Fault language attaches to platform ownership and tooling, never to users. If an analyst built a data mart in a personal schema, they did it because no approved place existed. The absent capability is the finding. The analyst is the evidence.

I have watched a lot of technical audits turn into a list of people who did the wrong thing. Every one of those people was doing their job with the tools they had. The chain is the finding, and the chain is owned by whoever owns the platform, which in this case included me.

The Rule Outward

The other half of the reset was about what the agents were allowed to say to the internet.

An agent researching a product will happily paste your schema names into a web search to get better results. So the brief says: send nothing outward. No schema name, table name, index name, authorization identifier, subsystem name, member count, or measured figure from this estate goes into a search query or a fetched URL. Ask the vendor's documentation what the product does. Never describe this estate to it.

And the collector that runs the queries is a collector, not an analyzer. It sends SQL, records results, records failures, and stops. It checks its query catalog at startup and refuses to run at all if any file contains anything that could write, lock, or change state. Every statement goes out with uncommitted-read isolation so nothing is locked. Every value comes back as text so nothing is lost to numeric conversion. Interpretation happens somewhere else, by something that cannot touch the estate.

What I Learned About Myself

I wrote the day-one thesis because I was confident. I was confident because I have been around this kind of system for twenty years and I recognized the shape. I was not wrong about the shape. I was wrong to let the shape become the brief. Once it was the brief, every agent that read it went looking for evidence of it, and every document they wrote cited the last one. By day four I had a beautifully consistent case that had never been tested against the possibility that I was wrong.

Four days of analysis is not much to lose. Four days of analysis that everyone downstream would have trusted is a lot to keep.

The measurements are still there. They were always the only part worth keeping.

-- Justin Higgins. Software Engineer, Midwest. Deleted every conclusion on day five and kept every number.


Companion pieces: The Decision Log Ate the Project - the same disease in a different organ. Twelve Days of Green Tests - the anchor you did not author.

Reactions, disagreements, war stories: jchigg2000.dev@gmail.com