I built the control tower first, not the features

For years I sat in the seat where the money had already been spent, the system was already live, and no one could prove whether it had worked.

I spent years in the auditor's chair

I was the top IT audit officer. What defines that seat is simple: you are always the one who arrives after the fact.

Something breaks. I go in. The job is to reconstruct what actually happened.

Most of the time it cannot be reconstructed. Not because the logs are missing, but because the record was edited by someone with an interest in it — or, far more often, because no one wrote anything down at the time.

An SOP says fifteen-minute response. The real average is thirty-seven minutes. Is that a violation? Maybe not — maybe the team was short-staffed, maybe the process was never realistic, maybe the SOP went stale years ago.

The problem is not which answer is correct. The problem is that afterwards, no one can prove which one it was.

Then AI made the same failure happen in milliseconds

After I moved to the United States I started writing code myself. With AI.

And I watched the disease I had studied for a decade from the auditor's chair replay at a hundred times the speed:

• I say A. The AI understands B.
• The AI implements B, writes the tests around B, and every test passes.
• The AI reports "done."
• And what I asked for was A.

The code is correct, the tests are green, the report is complete — three things perfectly consistent with each other, and all three drifted away from what I meant.

This is not a model being insufficiently smart. It is an inherent property of a probabilistic system. Move to a stronger model and it will only drift more convincingly.

Me saying "I was right" and me saying "I was wrong" cost exactly the same. The same is true of AI.

So I built the control tower before the features

Normal people build the features first and add audit and traceability later, once somebody demands them.

I did it the other way around.

Because there was no one around me who could catch my mistakes.

Of the people I know, I am the only one who writes code. No code review. No colleague next to me saying, "wait — I think you've gone sideways here." I immigrated to the United States; my friends work in restaurants, deal cards in casinos, or drive trucks.

Building three heavyweight systems alone, the biggest risk was never that I write slowly. It was that I would drift, all the way out, with nothing to tell me.

So I built the thing that would tell me.

• It remembers what I said.
• It compares that against what I actually did.
• When I say "it's finished," it asks me where the evidence is.
• It does not accept either side's self-report as acceptance.

Now it catches me.

A thing that drifts cannot govern a thing that drifts

For a while I tried running several AIs against each other — one builds, one reviews.

It doesn't work.

Not "works poorly." It fails structurally. Cybernetics has a law for this: for one system to control another, the variety of the controller must cover the variety of what it controls.

Adding a second AI just adds a second thing that drifts. You raise the probability of catching an error. You do not change the structure.

So the layer that actually governs has to be deterministic — not a smarter AI, but rules, state, authority and evidence that do not change on their own.

And that conclusion carries a counter-intuitive consequence:

The stronger the model, the less the layer underneath is allowed to be weak.

A stronger model proposes more complex work, touches more things, and sounds more credible doing it. Observability, constraint, authority and recovery have to rise with it, or the control relationship simply breaks.

This is not my opinion. It is a law.

Entropy is the road, not the enemy

The company is called Entrovia. *Entro* is entropy. *Via* is road.

Any organisation that is running produces entropy: people change, policies age, temporary fixes become permanent, and reality drifts a little further from the plan every week. Engineering is no different.

Entropy cannot be eliminated, and it should not be.

The danger was never entropy. The danger is entropy you cannot see, cannot locate, and cannot prove you closed.

So this system does not promise you will stop making mistakes. It promises that when you make one, it can be seen, located, corrected, and proven to have converged.

One last thing

I am not building this to make software faster.

I am building it so that the thing that exists only inside your head can actually get built — and so that what comes out is still the thing you meant.

With the best engineers standing beside you the whole way.

When you use it, I am standing there too.