Why we measure entropy, not uptime

Uptime answers the wrong question

Every system we are ever asked to review reports uptime, and every one of them has had a quiet stretch where uptime was perfect and the output was worthless. A scheduler that returns the same roster it returned yesterday is up. A forecast that has quietly collapsed onto the mean is up. A matching engine that has stopped separating good matches from bad ones is up. Uptime is a promise about the process being alive; it is not evidence that the process is deciding anything.

We still report uptime. Ask us and you will get it, because somebody in your organisation is accountable for it. It is just not the number we put at the top of the page.

What we put at the top instead

Every run we hand you produces a receipt, and the receipt says how much uncertainty the run removed — the entropy figure. It is a measurement of the work, not of the machine: a run that considered every option and ended up no more certain than it started removed nothing, and the receipt says so plainly, on the same line as the time it took and what it cost.

That single change moves the conversation. “Did it run?” has one answer and no follow-up. “How much did this run actually settle?” is a question you can put to a series of runs, week over week, and get a trend from.

What you can observe

Three things, all on the receipt, none of which need us to be in the room:

• The figure falling across a run. A settling process removes uncertainty in big steps early and small ones later. Watching that curve flatten tells you when more compute stops buying you anything — which is the moment to stop paying for it.
• A bound narrowing. Alongside the figure, the receipt says how far the answer could still be from the best possible one, and which of three kinds of statement that is: exact, certified, or not computed. Those are different promises and we do not blur them.
• A run that removed nothing. The most useful receipt we produce. It is not a failure of the engine; it usually means the question was already decided, or the inputs did not contain the information the question needed.

What you can decide with it

We are not going to tell you what your threshold should be — that is a business judgement and it belongs to you. What the figure does is make the judgement possible at all:

• Stop a recurring run that has been removing nothing for a month, and spend the budget on the input that is missing instead.
• Accept an answer whose bound is already tighter than the decision needs, rather than paying for a longer run that cannot change what you do next.
• Escalate the runs where the bound says not computed, because that is the honest report of a case where nobody — us included — can tell you how close you are.

The honest limit: an entropy figure is not a service-level agreement, and it does not replace one. It tells you whether the work was worth doing. Whether the service was available is still a separate question with a separate answer.

Where this starts

If you have a recurring run whose value nobody can state in a number, that is the shape of problem this is for. Put the question to our consultant — he answers from our own published pages and names the section he took it from — or read how engagements work, which starts with a week-long diagnostic that ends in a written assessment.