A warning up front: this is a technical essay. No tips, no listicle, no sales pitch. I describe a way of recording work that is different from what most companies do, and I go deep because it only convinces once you see the mechanics. Take your time with it, or save it for when you have some.
Every company keeps a cash book. Nobody finds that strange. You do not record what your balance is, you record what happened: an invoice, a payment, a correction. The balance is not an input field, it is an outcome. And that is why you can look back at it. If the balance looks odd, you walk back through the entries until you see where it tipped.
Now your work. Where is the entry there?
Nowhere. What you have is a collection of fields holding the latest state. Status: in production. Delivery: expected. Project: running. Who set that field, when, and why, is gone. What it said last week, nobody remembers. And when you ask how it is possible that this project is running at a loss, the guessing starts.
We have been booking money as entries for six hundred years. Our work we book on a blackboard that we keep wiping clean.
This essay is about what happens when you make that reversal. I did not just think it up, I built it, as a running simulation of an interior fit-out factory, and I use that here as illustration.
A fact is something that happened
Start with the smallest part. A fact.
A fact is something that happened and therefore does not change any more. "Delivery arrived." "Saw error found." "Customer approves the drawing." "Anna finished the estimate, outcome: risk uncertain."
No status, no opinion, no field that someone updates later. An event, with a timestamp, with who did it, and with the data that belongs to it.
You put those facts one after another in a single list and you never remove anything from it. That is the whole storage layer.
Sounds too simple to lead anywhere, but it has a property that changes everything: anything else you want to know is derivable. What is in production? Count the facts. How busy is the schedule? Count the open requests. What was the state on 3 March at four o'clock? Count up to that point and stop.
You no longer build screens that contain the truth. You build views onto the same stack of facts.
And that also means: you can go back in time. Not as a feature, but because it cannot be any other way.
Rules are what follows from a fact
Facts on their own are an archive. What makes a company run are the rules between them.
A rule is a sentence of the form: if this fact appears, then that follows. If the drawing is approved, then a bill of materials has to be drawn up. If the bill of materials exists, then a purchase requirement appears per item. If a delivery comes in, then someone has to check it before it goes into stock.
That is exactly what sits in the heads of your people. It just is not written down anywhere, or it sits in a work instruction nobody reads, or it is buried in code nobody dares touch any more.
Put those rules somewhere separate, as data. Then you can read them, discuss them, draw them and change them without having to rebuild a system.
On top of that, every consequent fact remembers which facts caused it. That looks like a detail for programmers, but it is the reason you can ask "why" later without reconstructing anything.
What it also solves: the endless argument about what the process is. Once the rules are explicit, there is no discussion left about what is supposed to happen. Only about whether the rule is right. That is a far more productive conversation.
Asking a person to do work is also a fact
This is where systems like this often go wrong: they model only the machinery and not the people.
But a request to a person is just as much an event. "There is work for purchasing: place an order for edge banding." That fact does not create a task in a task list. It is the task. Someone picks it up, that is another fact. Someone completes it with an outcome, that is the third fact.
And then the most important discovery: that outcome is not a tick box.
"Done" is one possibility. "Not found" is another. "Quantity short." "Site not ready." "Cannot, because..." with free text after it.
If the warehouse worker does find the stuff after the search, he corrects his own observation, and that correction is again a fact that points back at the old one. The old fact stays. You are allowed to be wrong in this model, you just do not have to pretend it never happened.
This is the reason systems like this do get filled in and classic systems do not. You are not asking people to update an administration. You are asking them to report back on their work with the outcome that really occurred. The administration is the consequence.
The practical rule I apply here I call the registration ladder. If a machine can report it itself, let the machine report it. If it cannot, use a scan. If that is not possible either, derive it from other facts. And only when there really is no other way do you ask a person. Every step down that ladder costs reliability, so you use it as little as possible.
Gates: where streams come together
We draw most processes as a line. In reality they are tributaries coming together.
A module can only go into the paint shop once all parts have been measured. Production can only start once all items are in, not most of them. Installation can only happen once the transport is there and the site is free.
I call such points gates. A gate counts down.
And that is exactly the question you sit with as a director: where is it stuck, and what is it waiting for? With gates, that is no longer detective work.
The most interesting fact is the one that fails to appear
For me this is the heart of the whole model, and it is also the least intuitive part.
Everything so far is about things that happen. But most money disappears into things that do not happen. The delivery that fails to arrive. The customer who does not respond to the colour samples. The approval that sits there.
Being late is not an event. Nobody "does" late. Nothing happening is precisely the point.
So you have to turn the absence itself into a fact. It works like this: record the promise at the moment it is made. "The supplier has committed to deliver on Tuesday." That is something that happened, so it goes straight into the log. And put a watchdog on it that checks on Tuesday whether the promised fact is there.
If it is there, the watchdog stays quiet. If it is not, it turns that into a fact, with a reference to the promise that was not kept.
Count those two kinds for a year and you have a delivery reliability figure per supplier that nobody had to enter.
The same mechanism works anywhere something is promised. A handover date given to a customer. An approval you asked for. A task that sits untouched far too long. It is always the same shape: record the expectation, put a check moment on it, and turn the absence into a fact.
And if the promised thing does arrive after all, the watchdog closes the loop: met in the end, three days late. That too is a fact, and with it the problem burns out by itself instead of leaving a flag hanging that nobody ever removes.
What you get for free
If you build it this way, things come out of it that you would normally have to buy as a separate project.
Why questions. Every fact knows which facts caused it. So you can work back from a problem: the module does not fit, because the dimensions were off, because the drawing was never revised after the site survey, because the question about it sat for three weeks with someone who was off sick. That is not a reconstruction from emails. That is a chain that is already there.
Time travel. You can go back to any moment and see the whole organisation as it was then. Not only what happened, but also what people thought would happen at the time, because expectations are recorded too. That makes looking back honest. You judge a decision with the knowledge of the time, not the knowledge of now.
Post-calculation that adds up. If every completed task carries its hours and every machine its running time, then the real cost price is not an estimate after the fact but a sum. In my simulation roughly one in three projects runs at a loss while on paper they all made a profit. Not because of one disaster, but through a pile-up of small things that were recorded nowhere.
Dashboards without data entry. Lead times, absence, breakdowns, how often a commitment is met: it is all a count. Nobody has to update a report, because there is no reporting truth alongside the operational truth.
The tree: every path the rules allow
Once you have the rules as data, you can draw them. And then something happens that I had not seen coming myself.
All the rules together form one tree. At the bottom the enquiry, at the top the closed project, and in between every path the rules allow. Not just the tidy path. Also the saw error that goes back into the line. Also the customer who changes their mind. Also the supplier who never gets in touch.
That is a surprisingly powerful image to look at together. People see it immediately: here are all our exceptions, and this is the route this project took. They also see the loops, the places where work comes back. Rework is not an exception in a factory, it is part of the shape.
And you see where it is busy. Add today's runners as little lights, and the tree tells you where in the process your company stands right now.
Where AI belongs, and where it does not
Now the question everyone starts with, even though it really comes last.
With a model like this you can point precisely at what a rule can do. Determining that a delivery is late, a rule can do that. Sending a reminder, bundling orders for the same supplier, preparing an invoice at a milestone: all rules. That does not need to be AI, and it should not be AI either, because a rule is predictable, cheap and explainable.
Where does it stop? At the situations where the possibilities are endless and the trade-off is situational.
The supplier has stopped responding to anything, the contract has a penalty clause, the alternative is three times as expensive and the customer already had to wait once last week. What do you do? There is no rule for that, and you are never going to write one, because there are too many variants.
That is the place for AI. Not as a layer over everything, but as the rule for the unforeseen. At the moment the chain jams and no rule at all fits, the AI works out an approach. Not an answer from a dropdown, but a small plan: three or four steps, each with a department attached and with conditions. Only inform the customer if the express route fails, for instance.
That plan becomes a fact, with the reasoning attached. And then the nicest part happens: it executes itself through the ordinary work queue. Every step becomes real work for a real department, with a real outcome. No separate AI system next to the process, but work in the same stream, only thought up by someone else.
Two things make this tidy instead of scary.
First, the boundary. An AI may propose, not commit. Spending money, promising a date to a customer, accepting extra work: that stays a human approval. That boundary is not a policy rule in a handbook, it sits in the model as a mandatory pair of facts: first requested, then granted.
Second, the repetition. If the same approach works twice, it is no longer an exception. The system then proposes taking it on as a fixed rule. The unforeseen simply becomes process, and you can read back when that rule came into being and why.
Agents as capacity, with a mandate
One step further. If the work sits in a work queue and every task has a defined outcome, what is stopping you from having part of that work done by an agent?
Not everything. Someone still has to take the measurements on site and fit a cabinet. But ordering, invoicing, chasing, scheduling: that is digital, rule-bound and checkable work.
In my simulation agents pick up roughly a sixth of all tasks that way. They work fast, they do not fall ill, and when the queue builds up the system switches another one on. That last point is a difference you cannot paper over: human capacity is a fixed quantity, agent capacity is not.
More important than the speed is what they do afterwards. They check their own work. If they find something, they fix it themselves, and that is a fact you can count. And if they run into a judgement that is not theirs to make, they hand the task back to a person, with a reason.
That gives you a figure I have never seen in any company: what share of our work is delegable, how often does the delegation catch its own mistake, and how often does a person have to step in after all.
And once you have that, you can also steer on intent. You type a sentence: make sure the projects at risk of running late get priority this week. That is a fact from you. The AI turns it into a plan, the plan becomes work, the work gets done, and you get back whether it succeeded. You did not write a procedure. You expressed an intent in a system that knows what work is.
I built it to find out whether it holds up
Talking about process models is easy. So I built a factory.
Not a presentation, a working simulation of an interior fit-out company: forty-three people, eleven machines, suppliers who deliver late or never get in touch, customers who change colour when production is already running, sick notes, the summer shutdown, saw errors, extra work agreed verbally that only surfaces at the post-calculation. A year of running produces tens of thousands of facts, all tied together.
What I wanted to know was whether the model holds up when you stuff reality into it. Four times I added a whole layer: machines with changeover times and test pieces, people with leave and ramp-up time, customers who change their minds, money and post-calculation. Not once did I have to touch the architecture. Only the rules grew.
For me that is the real proof. Not that it looks nice, but that adding complexity never turned into a rebuild.
What else it can be used for
I built this as a factory because a factory is concrete. But there is nothing factory-specific in the model.
What you need is this: work with a lead time, several people handing something over to each other, commitments to the outside world, and things that go wrong. That is a mechanical contractor, a builder, an office with case files, a care pathway, a council issuing permits, a software team. Anywhere something has to get from A to B and passes through hands on the way.
What it gives you there is always the same list. You know what really happened, and why. You see where it is standing still and what it is waiting for. You watch your own promises instead of your customers pointing them out to you. You know what a job really cost. And you can give a grounded answer to the question of which work you can hand to a machine and which work is judgement.
What it is not
Let me be honest about the other side, otherwise this reads like a brochure.
This is not a software package you install. The core is thinking work: writing down your own rules. That is exactly the part companies would rather skip, because it is uncomfortable. You find out that three departments have a different idea of the same process. That is not a bug in the method, that is the payoff, but it does not feel that way in the first week.
Nor is it an excuse to want to register everything. If you ask people to tick off every action, you have not built a model but a time clock. The registration ladder is there for a reason.
And it is not free. A log that keeps everything gets big, exceptions keep existing, and the first version of your rules will be wrong. That is fine, because changing rules is cheap in this model. But do not count on a system that is finished. Count on a system that grows with you.
The lead goes to whoever dares to let go
Over the coming years a gap will open up between companies that grows wider than most people currently estimate. And it is not where everyone is looking.
It is not in which model you pick. Models get better every quarter and anyone can buy them. Whoever has the best assistant today has the same one as their competitor six months from now. There is no lead in that.
The lead is in whether a company is willing to let go of what it clings to. The package that swallowed three hundred thousand and became sacred because of it. The status field that has had the same name for twelve years while nobody knows any more who sets it. The colleague who has it all in his head and retires in four years. And above all: the conviction that our process is too special to write down.
That letting go is not a technical step, it is an uncomfortable one. What you give up is the vagueness, and vagueness is comfortable. As long as the process sits in people's heads, everyone can be right. The moment it is on the table, it turns out that three departments meant something different, and that there is work nobody ever assigned.
But whoever does it gets something you cannot buy. You can only seriously hand work to a machine once it is fixed what that work is, when it is finished and how you check it. That holds for an agent just as hard as for a new employee. Delegating is not a matter of trust, it is a matter of definition.
And it compounds. Every exception you record makes the model sharper, every sharper rule makes the next piece delegable, and every delegation gives your people time for the work that needs judgement. A company that has run that loop for two years is not one you catch up with by buying a better model. You would have to catch up with its whole way of looking.
So anyone who wants to use AI seriously has to dare to give something up first. That is the price, and that is exactly why most will not do it.
In closing
The reason this works is not the technology. It is the reversal.
As long as you only keep the current state, you have to invent everything you want to know all over again: reports, status meetings, someone who happens to still remember. The moment you record what happened, every answer is a count.
You do not have to believe in it. You already do it with your money.
The only question is why you still keep your work, which is far more expensive than your balance, on a blackboard.
Want to see the simulation running? I am happy to show it: you scrub through the year yourself, open a project and see where it went wrong. Get in touch.