Isaac Correa · Madrid

How Hellomatik started

The first version of the idea was a system that answered restaurant phone calls. What it turned into was a way of writing down how a company decides. This page is the route between those two things, in the order it happened.

A voice

I had spent two years building Looker Studio dashboards for other people’s businesses. A dashboard shows numbers and leaves the reading to whoever opens it. The next thing to try was letting someone ask instead of read, and restaurants were the first case, because a restaurant’s phone rings all day with questions that have exact answers and nobody in the building is free to pick it up.

What you get from that is a voice on top of a database. It repeats what is in the record accurately. Ask it something the record does not contain — whether the kitchen serves late on a public holiday, whether a dish has nuts in it — and it produces a plausible answer in the same even tone it uses for the things it does know.

I shipped it before I had any way of telling its right answers from its wrong ones, which is a bad order to do things in and the reason the rest of this page exists.

The cheap fixes, and where they stop

There are two well-known answers to that. Let the system look things up instead of recalling them, so the answer comes from the record rather than the model. And let it say it does not know instead of filling the gap. I used both. They reduce how often it invents, and they are worth doing, but neither one decides anything.

The first thing they do not decide is which record. A business with a booking system, a point of sale and a spreadsheet has three answers to “is that table free”, and they disagree. Looking it up is only a procedure once somebody has decided, in writing, which of the three is believed about that particular field, and in the businesses I sat with that decision was not the same for every field.

The second is that a good part of what the phone gets asked is not in any record at all. Can this table be held for twenty minutes without a card. Can that customer order again with an invoice still unpaid. Can the party of twelve book on a Friday. Those have exact answers, the business applies them consistently, and they are not written anywhere — they are conditions somebody decided once and everyone learned. Looking them up is not possible, because there is nothing to look up.

None of this is new. Deciding which system is authoritative for which data is an old discipline with its own literature, its own vendors and its own well-documented ways of failing: master data management, data governance, more recently data contracts. Those programmes have driven system-to-system integration for years, not only human reporting, so the machine-readable part is not the new bit either. What was different in my case was the size of company. That work is normally bought by organisations large enough to run a programme around it, and in the small and mid-size businesses I sat with the same decisions existed nowhere at all — not in a tool, not in a document. They were held by whoever had been there longest.

A brain

So before the software there is a document: which system is authoritative for each thing, what conditions the business already applies, which exceptions are live and when they expire, and who may approve what. Not a summary of the business, but the specific decisions it makes without noticing it is making them.

One piece of it — two departments settling what they each mean by “customer” — takes an afternoon in a room, and in my experience it does not end with a clean answer. Both definitions are usually right about their own department.

A company has hundreds of terms like that, so the honest version is that the document is never finished. What the first weeks produce is not the whole company written down: it is the part needed by whatever is being automated first, which is a much smaller thing and is the only reason the work is startable at all. The rest stays where it was, and gets written when something needs to act on it. Anyone who tells you the whole map takes a few weeks is quoting the afternoon and hoping you multiply badly.

That cost falls on the company rather than on me: it puts people in a meeting arguing about something they had been quietly disagreeing about for years, and the count of live exceptions comes out higher than expected. It also does not settle who is allowed to change the rule once it is written, which is the failure mode the older discipline is full of and which I do not consider solved.

Hands

Answering correctly and being allowed to act are separate problems, and the second one is the reason the document has to exist rather than be a good habit.

A system that answers can be wrong and cost somebody a morning. A system that sends the quote, releases the order or raises the credit hold can be wrong in a way that cannot be taken back. So before software is allowed to act, somebody has to have written down what it may do, which of those things can be undone, and who has to approve the rest. That list is part of the same few weeks, and in my experience it is the part people have thought about least before starting.

It also decides where the limit lives. A limit written into a prompt is a request to the model. A limit written as data is not self-enforcing either — something still has to check the row before acting, and that check is code somebody has to write. What changes is that the limit can be read by someone who did not write the prompt, audited after the fact, and changed without redeploying.

What the document turned out to be

By this point the document had four parts. I did not arrive at them by design; each is what was left over from a problem further up this page, and I am laying them out in that order so the derivation can be checked rather than taken.

The voice needed to know which system is believed about each thing, so the first part is the data: what exists in the business, and which record is authoritative for each field of it. The questions with no record behind them — the twenty-minute hold, the party of twelve, the customer with an invoice outstanding — needed the conditions the business already applies, written down with their exceptions and the dates those stop being true, so the second part is the rules. Letting it act needed the list of what it may actually do and which of those things can be undone, so the third part is the actions. And because some of those cannot be undone, the fourth part is who may approve what.

Data, rules, actions, permissions. The word for that is ontology, used the way information systems have used it for decades rather than the way philosophy does — I define it, and what it is not, on another page. It is an unfashionable term and I keep it because the alternatives mislead: “knowledge base” suggests pages for a human to read, and “configuration” suggests settings for a program that already exists. This is neither. It is a company stating its own decisions in a form that something other than a person can act on.

The version I ended up with is written out in full in the report, called “How we build a company’s ontology”. What it mostly contains is the order to ask things in and the mistakes that make you redo the first week.

What it looks like at production size

The method is published in full as a technical report with a DOI. It declares its limits, and the figures there are the closest thing to a size on this page. Four systems in production at the time of writing; the report describes two of them in any detail. One is B2B, recalculating 29,000 customers every night over 14 million sales lines. The other is logistics: 24 rules applied against live ERP and warehouse data, across 30 million operations and 460,000 locations.

Those are counts of what the systems run over, not of what they improved, and the report is my own deposit rather than an audit by anyone else. So they are a description of size and nothing more.

The checkable part

Very little of what I have written above can be verified from outside. Hellomatik’s first client was a large clinic, and I am not naming it or its city, so that is not a case study and I am not going to present it as one — it is a fact about my working life that you would have to take on trust, which is the same footing as most of this page. The report is deposited with a DOI, which is an address rather than a review: it fixes the argument in one place with a date on it so it can be disagreed with in detail.

The company is a matter of public record. Hellomatik was incorporated in Madrid on 28 July 2025. My appointment as joint administrator went into the Spanish commercial register and was published in the BORME on 4 August 2025, sheet M-861159, with the Agencia Estatal BOE as the source. That proves a company exists and when — nothing about whether any of the above works.

Before it existed there were two months of screens, one panel at a time, each one kept only if I could say which decision it was there to support. The order I work in is on another page.

Read more

How we build a company’s ontology — the method this ends at, published in full with a DOI.
The vocabulary, defined one word at a time — what ontology, rule, action and permission mean here, and what they are not.
From a seven-dollar dashboard to Hellomatik — the whole story with its dates.
The Looker Studio years — the two years of dashboards this came out of.
Which actions can be undone — the list that has to exist before software may act.