22 October 2026
I gave my home dashboard a feature to tell me what its data meant. Then I stopped trusting it, and started wondering how much other software that applies to.
I deleted a feature from my home dashboard recently. Not because it was broken, exactly. It worked perfectly well. I deleted it because I'd realised I didn't trust what it was telling me.
Which is slightly annoying, because I was quite proud of it.
The private console behind this site collects readings from around the house: temperature and humidity in every room, the weather outside, that sort of thing. A few weeks ago I decided it ought to do something more useful with all that data.
So whenever I changed something (moved a sensor, bled a radiator, opened a vent) I logged it. The console would then look at what happened afterwards, find comparable weather, and decide whether the change had made things better or worse.
It had coloured shading on the floor plan and a little verdict against each change. It felt like I'd finally moved on from collecting increasingly ridiculous quantities of data about my house to actually doing something intelligent with it.
Except the answers were rubbish.
The kitchen was where it became obvious. I'd made seven changes in sixteen days, and somewhere in the middle of them the heating came on for the winter.
The dashboard didn't know any of that mattered. Worse, I'd made every change answer the same question, had the room got "better"? But better how?
One of the changes was meant to reduce condensation. The room ended up slightly cooler, so my clever little scoring system marked it as worse. Except a slightly cooler room was partly the point.
That's when I realised I'd built something that was very good at giving me an answer and not particularly good at understanding the question.
So I took it out. The console still collects everything and shows it, with the weather outside alongside. What it no longer does is tell me what any of it means. When I want to know, I export the readings, work through them with an AI, and write down what we found, with a date on it.
The first real test came a few days later, when one of the loft sensors hit 87% humidity. The old me would have written a rule for that, and the rule would have told me I had a damp problem.
Talking it through, the question changed from "is 87% high?" to "is the loft holding more water than the air outside?" Mostly it wasn't. Along the way we worked out what a genuine warning sign would look like, and that's what I keep an eye on now.
I could probably have built enough rules to get there. Account for outside humidity. Add a lag, because rooms trail the weather by about a day. Treat each sensor differently depending on where it hangs. Record what sort of change I'd made. Add confidence scores.
But at some point I'd just be building an increasingly complicated machine to answer questions I hadn't asked yet, and that was the bit that changed my thinking.
I've spent a lot of my career building systems that do versions of the same thing: dashboards, RAG statuses, health scores, insight panels. They take messy underlying data, apply some logic to it, and give somebody a simpler answer.
And that was completely rational. If answering a new question meant finding an analyst, getting the data out, working through it and coming back a week later, of course you tried to anticipate the useful questions and build the answers into the product.
I'm increasingly less sure that's the right default.
Not always. My own licence reporting tool scores everyone on how much of their Microsoft 365 licence they actually use, and I think that one's right as it is: the question comes round at every renewal and barely changes. It's the questions nobody anticipated where a built-in answer starts to look shaky.
What's interesting about AI here is less that it can generate another dashboard, and more that the cost of asking a new question has collapsed.
Maybe the system doesn't need to decide what the data means every morning. Maybe its job is to keep good data, hold on to the context around it, show me what's happening, and let me ask the question when I actually have one.
Weirdly, that doesn't make the underlying system less important. Probably the opposite.
I've stopped putting effort into making the console interpret everything, and started putting it into making the information underneath better. Keep the readings, and keep them consistent. Record when something changed and, crucially, why I changed it: the change log survived as a diary, and it now asks what each change was aiming for. Put the outside conditions next to the inside ones. Make the raw data easy to get at.
And keep a few deliberately boring rules for the things where I genuinely don't want interpretation. If it's getting cold enough near the water tanks for freezing to be a possibility, I want an alarm. I don't want a conversation with an AI about it.
That's quite a different architecture from the one I started with.
None of this is because I suddenly trust AI to be right. It can be confidently wrong as well. I've seen plenty of that.
What I like is that the answer isn't frozen into the product.
I can ask why, tell it something's wrong, or change the question, and it can tell me there isn't enough evidence yet. And next week, with another week's data, I can ask again.
That's very different from a green box on a dashboard whose logic somebody wrote eighteen months ago.
Deleting something I'd spent time building felt a bit like going backwards. But the console is less clever now, and I think it's considerably more useful.
I suspect there's quite a lot of software that could do with the same treatment.