Isaac Correa · Madrid

The vocabulary I work in

A handful of words do most of the work in what I write, and every one of them already means something else to somebody. So here is what each one means when I use it — and what it does not mean, which is often the part that clears things up. The definitions come out of the method I published with a DOI; nothing here is invented for the page.

Isaac Correa, co-founder of Hellomatik, in Madrid
Isaac Correa, co-founder of Hellomatik, in Madrid.

Ontology

The written-down map of what a company knows and how it decides: its data, its rules, its actions and who may approve what. I use the word in its plain sense — a list of the things that exist in a business and how they relate — not the philosophical one. The point of writing it down is that agents can then act on it.

What it is not. It is not a database schema. A schema says what shape a customer record has; an ontology says what a customer is here, which of the three systems is believed about it, and what may be done to it and by whom.

Rule

A condition the business already applies, written in one line, evaluated the same way every time, with its exceptions written next to it rather than remembered by whoever invented them. A credit limit is a rule. So is which system wins when two disagree about where an order is.

What it is not. It is not a workflow step. A rule is true or false regardless of who is asking and in what order; a workflow is a sequence. Rules that only exist inside a workflow disappear the moment somebody works around the workflow.

Exception

A case the rule does not reach, kept beside the rule itself as another row rather than in the head of whoever allowed it. It carries the same columns the rule carries — where it applies, which limit it displaces, how wide it runs, whose name is on it — and one more that a rule does not need: the day it expires. That column is usually empty, which is how a business ends up enforcing two policies without having decided to.

What it is not. It is not a manual approval bolted onto a process. An approval hands the decision to somebody looking at a screen that does not show them what they are overriding, and the only record it leaves is a sequence of clicks. A row sits in a table, so it can be listed and counted, and it falls due on the date it carries. There is more about it in one of the letters.

An exception as a step in a workflow, and the same exception as a row in the rule table Two panels. On the left the exception is the third step of a workflow: the order arrives, the rule is checked, the case is routed to a person, the order ships. On the right the same exception is one row in the rule’s own table, with its fields listed underneath it: condition, limit, reach, authorised by, and the date it ends on. A step in the workflow Whoever clicks cannot see what is being overridden. the order arrives the rule is checked the exception routed to a person the order ships To count how often it happened you would have to reconstruct it from a sequence of clicks. A row in the rule’s own table Same table as the rule, same fields. the exception one row ITS FIELDS condition what it covers limit what it replaces reach how far it goes authorised by a name ends on a date The bottom one is the column usually left empty.
The same exception, drawn as a click and drawn as a record. Only the one on the right can be listed, and only the one on the right expires by itself.

Action

Something the system may actually do in the world: send the quote, release the order, raise the credit hold. Actions are the part that carries risk, which is why I write them out one by one instead of leaving it to a model to work out, in the moment, which of them it is allowed to perform.

What it is not. It is not a suggestion. If the system only proposes and a person always confirms, the work is still being done by the person.

Permission

Who may approve what, recorded as data rather than as a screen. The test I apply is whether you can answer “who decided that?” with a name and a date, straight from the record, without an archaeological dig through logs.

What it is not. It is not a role in a user table. Roles say who can log in where. A permission in this sense says who may authorise a specific action on a specific thing, and leaves a trace when they do.

Agent

A program that answers, watches and executes on top of the map, inside limits that the business approved in advance. With an agent I am less interested in what it can do than in what it is not allowed to do, and in where that limit is written.

What it is not. It is not a chatbot with tools bolted on. If its limits live in its prompt, the next instruction can override them.

Boundary

The limit on what may happen, kept in the data rather than in the instructions. This is the one I come back to most often: if you can read it, check it and change it without redeploying anything, it holds; if it lives inside an instruction, it can be overridden.

What it is not. It is not a guardrail added at the end. If the limit was decided after the capability, the capability ran without it for a while.

A limit written in an instruction, and the same limit written in the data Two panels. On the left, the limit lives inside the instruction given to the agent: the line is dashed and the action crosses it. On the right, the limit lives in the data the agent must consult: the line is solid, the action stops, and the record names who set the limit and when it last changed. Written in the instruction You can ask a machine to ignore an instruction. Agent prompt says: “never above the limit” the limit the action goes through The limit is stored nowhere else, and the crossing leaves no record. Written in the data The agent has to go and look, every time. Agent the table holds the limit the limit the action stops here the record names who set it and when it last changed The record above is the limit, so changing it is a change to data.
The same limit, in the two places it can live. The one on the right can be read and changed without touching any code; the one on the left cannot.

The first week

What I do before writing any software: asking the people who already run the company what the rule actually is, and writing down the answers verbatim, including the ones that contradict each other. Those contradictions are what I am there to write down.

What it is not. It is not a requirements-gathering phase. Requirements describe what somebody wants built; this describes what is already true and nobody has written down.

Why bother defining them

Because the hard part, in the companies I have worked with, has not been the software. Two competent people in the same company will define customer differently, and both are right about their own department. Everything I do rests on getting that written down before anything is automated on top of it — which is the first week, and the reason it takes an afternoon with two departments in a room rather than a morning with an engineer.

None of this is theory I would like to be true. The report I published lists what is running on it: four systems in production. One of them applies twenty-four rules over a warehouse and live ERP data. Another recalculates twenty-nine thousand customers every night, over fourteen million sales lines. The vocabulary above is what had to be written down before any of that could act on its own.

If you want the long version, the method is here, the order I work in is here, and everything I have published is listed here. Which of these actions a company can safely hand over is a separate list, and it is the one that decides how much an agent may do.