Ask four systems in the same company what revenue was last quarter and you get four answers. All four are correct inside their own system. The meeting that was supposed to decide something opens by reconciling them instead.
That part is a data problem, and a data warehouse fixes it. We wrote about what that costs in a separate guide. Fixing it gets you to the starting line. Once everyone agrees the number is 4.12M, somebody still has to decide what to do, do it, and find out later whether it worked. Your reporting stack holds none of that.
// Insights 01What does a data warehouse actually cost?The first two parts of this series reconciled the records and charted the business. This part is about the voyage: who keeps watch, who decides, and who writes down what happened.
Decision intelligence is the name for the part after the number. Gartner published its first Magic Quadrant for the category in January 2026. This guide covers what it means in practice, and where it differs from the BI you already run.
Business intelligence is a pipeline that ends in a person. Source systems feed a model, the model feeds a dashboard, someone reads the dashboard. It was built for a time when getting the number was the hard part, and it solved that.
The expensive part starts after the number appears. Someone has to notice it moved, work out which of eleven possible causes is the real one, weigh a few imperfect options, pick one, hand it to a person with a deadline, and check three months later whether it worked. A dashboard holds none of that.
Behind every number on a dashboard stands a relay of people. Someone exports the ERP data, someone reconciles it with the planning spreadsheet, someone rebuilds the report. Then someone has to notice what it means, find the colleagues who know why, get a decision into the next meeting and hand it to the team that acts. On a ship these roles are defined and on watch around the clock. In most SMEs they are spread across eight people, and nobody is on watch.
Even a single source system only gives you one version of what was entered. It does not make the entry complete or current. Reliable decisions still depend on the discipline to capture the event, fill the relevant fields, and update them when the business changes. The cost of a missing field is usually delayed and diffuse: a forecast drifts, a question cannot be answered, or a meeting turns into reconstruction. The difficult question is not how to collect everything perfectly. It is where better capture will change an important decision enough to justify the effort.
Gartner defines it as a discipline that improves decision making by modelling how decisions get made and how their outcomes are evaluated over time. In plainer terms: the decision, not the report, is the thing you engineer.
A decision has parts. A dashboard has nowhere to put any of them, because a dashboard is a view of one or more tables.
The last one carries the weight. Ask your BI tool which decisions it influenced last quarter and whether they worked. It cannot answer. Nobody ever asked it to model a decision, so there is nowhere for the answer to live. Every quarter a company makes a few hundred consequential calls and keeps almost nothing from any of them.
Business intelligence produces a view. Decision intelligence produces a decision with a trace.
What changed, and why it crossed from noise into something worth attention.
The numbers it rests on, with definition, source and the moment they were true.
What could be done, scored against each other, including doing nothing.
The discount floor or safety stock that rules half the options out.
The person accountable, and the date they report back.
What this should change, stated in advance so it can be checked.
What actually happened.
MoLo takes its name from molo, the Italian word for a pier: a place where systems can come safely alongside. MoLo is the team behind it, the people who bring the data, systems, and decisions into dependable shape. Meridian is our decision intelligence platform for SMEs. Like a meridian on a chart, it gives the crew a fixed reference for where the business is, what has changed, and which course is worth considering. It can give direction, but the people responsible still decide whether to hold course, turn, or act.
Harbour · the crew ashoreBefore any voyage, the ship’s papers have to be in order: logbooks, cargo lists and port records that agree with each other. That was the first part of this series, reconciling scattered and conflicting records into one account of what happened.
The chart · the cartographerA crew also needs a chart. It shows the coastline, the depths and, just as importantly, the waters nobody has surveyed yet. That was the second part: shared definitions, operating context and an honest boundary around what is known.
The fix · the navigatorAt sea, no single instrument says where the ship is. The log gives speed and time, a bearing on a lighthouse gives one line, a depth sounding another. Where the lines cross, navigators draw a small triangle and place the ship inside it. Meridian does the same for your business: one current position, built from several sources, with its uncertainty shown.
The signal · the lookoutA good lookout does not report every wave, only what could change the course. A shoal ahead on the current heading is worth waking the captain for. Meridian’s Pulses work the same way: Warehouse A falls below safety stock in twelve days, and the evidence comes with the warning.
The course · the captainThe navigator lays out the options and the captain chooses. Hold course and hit the shoal, turn early, or take the long way round at a higher cost. Meridian scores each option against its constraints. The responsible person still gives the order.
The logbook · the watch officerThen the watch is written into the logbook: what was planned, what happened, what was learned. The shoal goes onto the chart. The next voyage starts from better records and a better map, which is how the three parts of this series fit together.
A stockout twelve days out, followed from the moment the data lands. Both tracks start with identical numbers from an identical warehouse. Scroll to run the clock.
Illustrative, not measured. The dates are the shape of the delay we see rather than an average of it.
Nothing on the top track is broken. The stock report was accurate on day zero and stayed accurate throughout. The customers were still let down on day twelve, and three weeks later nobody could say whether the expensive fix had been necessary.
Fair question, and the honest answer is that you could reach the same place with a good chat tool. The numbers would be right, because anyone building chat on company data seriously has a semantic layer behind it. You could ask why Warehouse A is low, ask again about the supplier, work through the options in conversation, and land on the same transfer.
// Insights 02The foundation: how a semantic layer describes the businessAll of it depends on you starting it. Somebody has to notice the coverage slipping, on a week when the line is short-staffed and two customers are already escalating. Then think of the first question, then the follow-up, then keep the thread going until a recommendation falls out. Then remember, three weeks later, to go back and check.
A chat tool answers whatever you point it at. Nobody can point at everything, every week.
A chat tool is an excellent navigator who only comes up to the bridge when called. Meridian keeps the watch.
That is the work Meridian takes on. It watches the parts of the business nobody is looking at this week, and it opens the conversation rather than waiting to be asked.
None of it removes you from the decision. You still choose, and you can turn any of it down. It removes the requirement that you be the one who starts, remembers and chases.
Noticing that something changed at all
Deciding which of eleven problems matters most this week
Asking the right follow-up questions to find the cause
Thinking up the options and weighing them against each other
Turning the conversation into an action somebody owns
Coming back weeks later to check the outcome
Noticing the answer needed data nobody ever captured
Meridian puts forward the next action. Not a chart that implies one. An action, with the person who owns it, the constraint it has to respect, and the date it gets reviewed. When that date arrives it checks what happened and records the result against what it expected. Recommendations that were turned down keep the reason they were turned down.
That list is the decision record from the title of this post.
On a ship this is the logbook. Nobody would sail without one, yet most companies make a few hundred consequential decisions a quarter and keep no log of any of them.
It is also what makes the next recommendation better than this one. A system that never learns which of its suggestions worked is guessing again every quarter.
Everything above describes a category. Meridian is our product: a decision intelligence platform for SMEs, built for companies that will never hire a six person data team and should not have to. It models the current state of your business, watches it, explains what changed, proposes what to do, and keeps the decision together with its evidence. MoLo is the team behind it, the people who encode what your company knows, implement the system, and test it before it goes live.
Meridian is designed to learn, and not only from its own recommendations. Every decision shows where the records are thin, where a definition is missing, or where context was never written down. Those gaps become the next sources MoLo connects and the next definitions and context we add to the semantic layer, while each logged outcome shows which signals and options held up. The records get fuller, the map gets sharper, and the range of decisions Meridian can support grows with them. From the first day it knows where its map ends: where the data is thin, it says so and asks instead of guessing.
The last surface is the one we find most interesting. A decision usually exposes something the business never wrote down. The real supplier lead time, sitting in an email thread. The reason a deal was lost, typed into a CRM note as three words. Meridian supports today's decision with what exists, then builds the structure that captures the rest properly. Our engineers test it before it goes live.
Your data stays in your environment or an agreed tenant, processing runs in European regions, and approved model endpoints are configured so providers retain nothing. For the companies we work with, that is the precondition for the conversation rather than a feature.
Stays in your environment or an agreed tenant. Source permissions stay authoritative.
Runs in European regions, on approved endpoints configured so providers retain nothing.
Can carry its source, its definition, the timestamp of the data and the reasoning behind it.
Needs your approval and passes a MoLo engineering quality gate before production.
Where its map ends, Meridian says so and asks. It does not guess.