Isaac Correa · Madrid

Your company already has rules. Nobody ever wrote them down.

There is a moment in almost every automation project that nobody puts in the brochure. It happens in week one, it has nothing to do with technology, and it is usually the most valuable thing that will happen all quarter.

You ask two people the same question — when does an order need a second approval? — and you get two different answers. Both people are competent. Both have been doing the job for years. Both are certain. And the company has been running on that disagreement for as long as anyone can remember, absorbing it the way a body absorbs a limp.

Nobody was hiding anything. The rule simply lived in people’s heads, where rules do not have to agree with each other.

Why this surfaces now and not before

Software has been eating business processes for thirty years without forcing this reckoning, because software was always told exactly what to do. A form either has an approval field or it does not. The ambiguity stayed comfortably upstream, in the humans deciding which form to open.

Ask a system to decide, and the ambiguity has nowhere left to hide. Not because the technology is smarter, but because you now have to state the rule out loud to a thing that cannot read a room.

The unglamorous inventory

So the work starts somewhere nobody expects: making a list.

Which things exist — orders, customers, invoices, shipments — and which system tells the truth about each one. That last part sounds like bookkeeping and is not. The same order lives in three systems in most companies, and the three do not match. Until you name which one is authoritative, every clever thing you build downstream inherits the argument.

Then the rules. Not new policy — the policy people already follow, written so that something other than a person can evaluate it. A discount past a certain depth stops being the sales rep’s call. An account in arrears waits for someone senior before anything leaves the warehouse.

Then, and only then, the interesting part.

The part that decides whether it is safe

Every action a system can take is tagged with two facts: whether it can be walked back, and whose signature it needs.

Drafting a reply costs nothing and can be thrown away. Moving money is final the moment it happens. Once that distinction is written down rather than assumed, you can hand a system genuine independence over the reversible half of the work without ever having the frightening conversation about the other half.

This is the step that turns a security review from a confrontation into a reading. You are not asking anyone to trust a piece of software’s judgment. You are showing them a table of permissions that the business itself signed off, and pointing out that the software cannot go around it.

What the company gets even if the project stops

Here is the case for doing the inventory regardless of what you think about AI.

At the end of it, a company that had its operating logic distributed across a few dozen heads has it written in one place. It survives someone leaving. It can be argued with, corrected and versioned. New people can read it instead of absorbing it slowly over their first year.

That has been valuable since long before anyone used the word agent, and it will still be valuable when the current generation of tools is embarrassing to look at.

The rest — the automation, the agents, the part that demos well — sits on top of it. It is real, and it works, and it is not the foundation. The foundation is the boring list.

The full method behind this is published as a technical report with a DOI rather than a brochure: how we build a company’s ontology, deposited at 10.5281/zenodo.22647735.

Isaac Correa, Madrid. ORCID 0009-0003-0657-4419.

Read more

Which actions can be undone — the list to write before anything is handed to software.

Press kit — bios you can paste, photographs, and every fact with its source.

The timeline — every date with the place you can check it.

Photographs — the pictures that exist of him, free to reuse with attribution.

What selling taught me — three hundred commissions, and the lesson underneath.
How I work on a product — the order I trust, and two months screen by screen.

Everything published elsewhere — the papers with a DOI, the letters and the articles, each with what it is.
How we build a company’s ontology — the method, published with a DOI.
From a seven-dollar dashboard to Hellomatik — the whole story with its dates.
The questions people ask, answered — short answers, each with a source.
The machine of the future — on what the next tool is.
Hellomatik and Kodalogic — what each company does.