Decision loops vs decision logs — why the difference matters

There is a particular kind of document that I have seen in almost every business I have ever worked with. It is a spreadsheet, or a Notion page, or a shared doc, called something like "Decision Log". It has columns for the decision, the date, the person who made it, and a one-line description. It is opened at all-hands. It is referenced when something goes wrong. It is, in practice, useless.

The reason it is useless is not laziness. It is a category error. A log records that something happened. A loop closes the gap between a decision and the lesson it should have produced. These are different tools.

What a log gives you

A decision log is forensic. After a bad outcome, you open it and you find the row, and you say: yes, we made that decision on the 14th of March. That is the entire utility. It is the same utility as a CCTV camera — it does not stop the crime, it just helps you describe it afterwards.

This is not nothing. It is just much less than people think.

What a loop gives you

A decision loop is adversarial before and adversarial after. Before the decision, it surfaces the strongest argument against. After the decision, it forces a comparison between what you expected and what actually happened. The output of a loop is not a record. The output of a loop is a revised prior — a slightly less wrong version of how you decide next time.

A log is read. A loop is run. You can run a loop on yourself with a notebook; you can run a log on yourself with a spreadsheet. They are not the same exercise.

The test

Here is the test I use to know which one a team has built. Ask: "what did we change last quarter because of something the log told us?"

If the answer is a specific change to a process — we moved the discount approval threshold from £200 to £500 because we saw a pattern — you have a loop. If the answer is "we reference it sometimes" or "it helped us in the post-mortem", you have a log.

About 95% of teams have a log and call it a loop. There is no shame in that. The shame is in believing the log is doing the work.

How to upgrade from log to loop

Three additions, in order.

One: expected outcome at the point of decision. Before you commit, write down what you expect to be true in 30 days. One sentence. Quantified if possible.

Two: review date in the diary. Not "we will look at this next quarter". A specific date, on a specific person's calendar, with a specific question to answer.

Three: written variance. When the review date arrives, the actual outcome is compared to the expected outcome, and the gap is written down. The gap is the entire point. The gap is what teaches you.

That is the whole upgrade. Everything else — software, dashboards, AI engines, signed receipts — is in service of making those three additions survive a busy week.

Why we built it the way we built it

Kauzio runs every decision through the loop because the loop is the only thing we have found that compounds. A log does not compound; it accumulates. A loop compounds because each cycle produces a revised prior, and the revised prior makes the next cycle slightly less wrong.

You do not need our software to do this. You do need to know which one you are running, and stop calling one of them the other.