Your Dashboard Is Lying to You...

I spent seven years building dashboards professionally. At Shopify from 2016 I worked as a business intelligence analyst and data analyst, with Shopify’s merchants, operations teams, Revenue Operations Intelligence, and the broader data science community.

In that time, my output was mainly in the form of dashboards, graphs and reports. This was in the pre-LLM era too, so data was untidy, unclean and distributed across different data warehouses. I got pretty good at dashboard building. The logical structure of sql and python was fascinating to my brain, forged as it had been in the academic world of post-structuralist philosophy. To be able to make declarative statements was really a novelty, and with dashboards it seemed as if I was finally able to make truthy claims about reality while having a secret chuckle. I started to understand code as an epistemological tool (though the Greeks would find that an oxymoron). And the thing I learned, slowly and then all at once, is that almost every dashboard I built was an epistemological mistake dressed up as insight.

The Problem Has a Name

In 2018, historian Jerry Muller published The Tyranny of Metrics, a careful, damning account of what happens when organisations confuse measurement with understanding. His central argument is not that metrics are bad. It is that metrics do a specific and limited thing, and instead of being satisfied with that, we have instead systematically asked them to do something else: to replace judgment, to substitute for knowledge, to produce accountability through quantification, and this even in contexts where quantification quietly destroys the thing it was meant to track.

Muller was writing about schools and hospitals and police forces. But his argument runs directly through every Business Intelligence dashboard I ever built.

The phenomenon has a related formulation in economics, usually called Goodhart's Law: when a measure becomes a target, it ceases to be a good measure. The moment you optimise for the metric, the metric stops measuring what it was supposed to. Conversion rate climbs because the checkout flow got dark-pattern nudges, not because customers got better reasons to buy. Average session duration rises because the navigation got confusing, not because the content got richer. The number looks good. The underlying reality has moved in the opposite direction.

What nobody talks about enough is the role the dashboard plays in this process.

It is not a passive recorder. It is an active participant.

Instrumental Reason and the View from Nowhere

The dashboards I built for seven years at Shopify were almost entirely governed by what philosophers call instrumental reason: the logic of means and ends, of efficiency and optimisation, of how do we get more of the thing we are already trying to get. The questions that shaped the builds were operational: What can we act on? What do we need to watch? What should trigger a response?

These are not bad questions. But they are narrow ones, and they produce a particular kind of dashboard; one whose deepest assumption is that the organisation already knows what it is trying to do, already understands what its data means, and just needs a faster, cleaner view of it.

In practice, this assumption was almost never true. Donna Haraway, writing about scientific objectivity, coined the phrase the view from nowhere to describe the rhetorical posture of claiming to see without a perspective , it is the colonial fantasy of a neutral, unlocated observer who reports what is simply and objectively there, a god’s eye view, in other registers. Dashboard design has its own version of this fantasy. The interface presents itself as a window: clean, transparent, unmediated. Data in, display out. The numbers speak for themselves.

But numbers do not speak for themselves. They speak through the schema that structured the database, the KPIs that were chosen over others, the time periods that were selected, the thresholds that define normal. Theodore Porter, in Trust in Numbers points out that quantification is not a technology of objectivity, it is a technology of distrust. Organisations reach for numbers when they cannot agree on qualitative judgments, when they need a form of authority that appears to bypass interpretation. The dashboard, on this reading, is not a neutral reporting surface. It is a political settlement disguised as a display

I saw this constantly. Stakeholders would arrive with a request for a dashboard and leave having negotiated, without quite realising it, a set of philosophical commitments about what the business was for, what counted as success, which teams' contributions were legible and which were not, and how their impact could be measured. The dashboard did not report on those commitments. It encoded them. And once they were encoded in a dashboard, the numbers immediately influenced behaviour, they became very difficult to question, because questioning the numbers meant questioning objectivity, and questioning objectivity in a business context is almost always a losing position.

James Scott, writing about state bureaucracies in Seeing Like a State, calls this process making legible. States simplify complex realities into forms they can administer: maps, censuses, land registries, and those simplifications are never neutral. They destroy local knowledge in the act of standardising it. They make some things visible and others invisible, and the things made invisible are usually the ones that do not fit the administrative categories. Business intelligence does the same thing at smaller scale. The dashboard makes the business legible to itself. What it renders invisible in that process is rarely examined.

The Specific Failure Mode I Kept Encountering

There is a particular kind of request I encountered so often it eventually stopped surprising me, though it never stopped being interesting. A team would come with a question about customer behaviour, about the impact of a product decision, ot about what was driving a trend. And the question was usually genuine. The problem was that the data frequently could not give them what they were asking for.

The question was real; but the number that would answer it did not exist, or could not be reliably constructed from what was available, or would produce a figure that looked precise but carried a false perspective; a tidy metric that would be more misleading than informative.

When I said this, something specific happened. The disappointment was not directed at me, exactly. I mean it wasn’t as if I was on an entirely male team, having a boss who sent me Jordan Peterson clips arguing that women were more satisfied in ‘traditional roles’, because that would never happen at such a forward-thinking company as Shopify, right? In a largely male-dominated space, this type of interaction sometimes had a particular texture to it: a quiet scepticism about whether the epistemic constraint I was naming was real or whether it was a failure of will or technical imagination. It sometimes as though the person suspected that another analyst, let’s say to their mind, a better one, could make the data do something different. As if data had capabilities that I was failing to unlock. They wanted datapoints to affirm their conception of reality, rather than accepting that data was constrained by limits that were simply there because the data was itself, a construct, a simplification of complex processes, a flattening.

And sometimes, having explained that the number would be inaccurate or misleading, I was asked to surface it anyway. Not because anyone doubted my analysis, but because the organisation needed something to put in the slide. The dashboard would be built. The caveat would be noted. And then the caveat would be forgotten, because caveats do not survive the journey from analyst to meeting room.

This is a different failure mode from Goodhart's Law, though it sits alongside it. It is not the metric being gamed. It is the metric being created for a question it cannot answer, under conditions where no one with the authority to say "this number should not exist" was in the room. The dashboard did not distort reality by being optimised. It distorted it by being trusted with more than it could carry.

The deeper issue, the one I did not have adequate language for at the time, was that no one had examined the epistemological question upstream of the data. Not: what do the numbers say? But: what does it mean to understand this problem? What kind of knowledge is even possible here, for whom, and to what end? Bowker and Star, in Sorting Things Out, argue that classification systems, the schemas and taxonomies that organise data, are not technical decisions but ethical ones. They decide what is counted and what is not, whose activities are made visible and whose are rendered as noise. And let’s be clear, in the context of business intelligence, the logic underlying the structure of the database is extractive capitalism, usually with the veneer of self-importance of this, or that careerist stakeholder trying to “make commerce better for everyone”, or was it, “keep the shareholders happy”? I can never remember, but it was definitely one or the other of those.

Building a dashboard without addressing epistemological and ethical questions does not avoid them. It just answers them by default, invisibly, in whatever way the available data and the loudest stakeholders happen to push. And the norms of what ‘counts’ become even more calcified as a consequence.

Struck by the maxim I think I extracted from the work of N.Katherine Hayles, that “we create tools and they create us”, I had never actually thought about what it might be like to create a different kind of dashboard, until now.

A Little Background on What I Built Instead

For the past month, like many other chronically online and semi-technical folks, I have been working with OpenClaw, a wrapper for an autonomous agent system that is model agnostic, but also significantly constructed on local opensource models.

In this work, I have been building an operational dashboard for a multi-agent AI system; a suite of specialised AI models that surface research, book notes, scheduling, as well as marketing and analysis across three different brands. The system runs continuously. It makes decisions. It holds beliefs about what is happening and acts on them. Managing it requires a control surface that can keep a human operator meaningfully in the loop without overwhelming them with raw output.

The dashboard I built; Mission Control is a fully custom interface: hand-coded, locally hosted, built from the ground up rather than assembled from generic components.

Visually, and on a whim, it draws on the aesthetic language of Studio Ghibli: the dappled light, organic shapes, and palette of plum and sage a panacea to eyes needing soothing from the clinical colour schemes of enterprise software. That choice was not decorative. It was the first philosophical commitment the build required, and I will come back to it.

Mission Control has four main pages. Each page has a tagline. Those taglines are where this piece is actually going.

The Tagline Is a Tool

The colour scheme and the attempt at Studio Ghibli energy are invitations to dwell, to browse, to enjoy, to loiter even, basic as the code is. The space is an invitation to reflect, rather than a space to extract specific numeric information with maximum efficiency.

The Calendar page tagline does not say Scheduled Cron Jobs. It says: Time does not pass, it reveals. The Ops page tagline does not say System Status. It says: We create tools and they create us.

These are not slogans. They are not a brand voice applied to a dashboard, or the bastardisation of profound thoughts to the crude mercantilist logic of a dashboard. They are designed constraints on thought, and a constraint, properly built, is not a limitation. It is a technology of attention.

Here is what that means in practice. When you open a page called Calendar, you are primed to audit the successful run of scheduled jobs.. Did the system run as it should? What is the next system operation in line?

The question is one of accuracy and reliability and system health. When you open a page stating that Time does not pass, it reveals, you are primed to think about the data in the context of its environment, both temporal and binary. Which stage is the system at, what processes are helped or enabled by these scheduled operations, what processes are contingent on them? Which gesture towards systems are that no longer so central? The data on the page is identical in both cases. The interrogation is completely different.

This is the move from a window to a lens. A window aims for transparency it promises that what you see is just what is there, unmediated, unfiltered. A lens admits its own curvature. It tells you, in advance, how it will shape what you see. The tagline is the specification of that curvature. It does not conceal a point of view. It names one.

Naming the point of view is what my seven years of Business Intelligence work almost never did. The dashboard presented itself as a window. The philosophical commitments what counts, who is legible, what failure looks like etc., were there, baked into every schema and KPI selection, but they were invisible. You could not interrogate them because you could not see them. The interface had laundered them into apparent neutrality.

Mission Control refuses that laundering. It is not a window onto the system. It is a lens through which the system is understood And the lens specifies its own curvature in advance.

What the Naming Actually Does

We could use the word ‘technologies’ to describe practices through which a person constitutes their relationship to their own knowledge; the disciplines, the examinations, the habits of reflection that produce not just behaviour but the subject who behaves. A dashboard can function as a technology of the self in precisely this sense. It does not just display information. It shapes the kind of person doing the looking.

The Ops page tagline The system's theory of itself is the clearest example of this in Mission Control. It frames the entire page as a record of the system's self-model: what it believes is happening, what it expects to happen, where its predictions are holding.

This framing changes how alerts function. When the Ops page surfaces a Theory/Reality Mismatch alert, you are not reading a bug report. You are reading a epistemological correction. As you build you wonder, why the sudden error? What changed? What was missing? The system's self-model has failed to predict a real-world event, or failed to recognise the network of its own operations. The operator's task shifts from fix the error to debug the model, which requires a different question entirely: what did the system believe was possible, and why was it wrong?

This is what a cognitive interrupt does when it is built into the surface rather than applied after the fact. It does not add a step to the workflow. It changes what the workflow is for.

Which is an abstract claim, and abstract claims about dashboards are exactly the problem this piece has been diagnosing. So let me try to say what it looks like concretely, and to do that, I need to briefly enter the technical register, because the point only becomes visible when the technical and the epistemological are in the same frame at once.

The system that Mission Control monitors is a pipeline of autonomous agents. It runs scheduled tasks, makes decisions, generates outputs, and holds an internal model of its own state; what it expects to happen, what it has done, where it believes it is in the sequence. When that internal model diverges from what is actually happening, Mission Control surfaces a Theory/Reality Mismatch alert on the Ops page.

Last week, a latency spike appeared under that alert. In a conventional BI context, this would have registered as a performance metric out of range; a number to be returned to its normal band, probably by scaling resources. The intervention would have been aimed at the symptom.

But under the Theory/Reality Mismatch frame, that response felt like a category error. The tagline had already shifted the question. You do not scale your way out of a false belief. The latency was not the problem; it was the signal that the system’s model of itself had failed to account for something; a load pattern it had treated as impossible, a dependency it had not modelled. The intervention addressed the assumption. The spike did not recur.

This is a small example. But its diminutiveness is the point. The cognitive interrupt did not require a separate audit, a retrospective, or a philosophical consultation. It was already there, in the framing of the page. The tagline had done its work before the alert appeared. And as the system changes, and the user changes as a result, so will the tagline.

The Aesthetic Is Also an Argument

The dominant aesthetic of operational dashboards is factory aesthetics: clean grids, neutral palettes, maximum data density, minimum friction, everything optimised for throughput. These are not innocent choices. They are the visual language of instrumental reason. They communicate, before a single data point loads, that the operator is here to run compliance checks, to verify that the system is performing within tolerance, to return aberrant metrics to their expected range.

The Ghibli visual language of Mission Control: dappled canopy layers, organic card shapes that glow upon hover, and a warm and slightly impractical colour palette, is rather anti-factory by design. It says: this system is a garden, not a factory. Maintenance here is cultivation, not optimisation.

Gardens require contemplation and interpretation in a way factories do not. A factory has a correct output. A garden has tendencies, patterns, seasonal logics, and spaces of reflection that both reward attention and also punish the mechanical application of fixed rules.

The aesthetic frames the operator's relationship to the system before they have read a single figure, and it frames things in a way that is directly opposed to the seven years of dashboard conventions I spent my career inside.

The visual language is a lens for the whole system.

The Loop You Cannot Step Outside Of

There is one more layer to this, and it is the one that the tyranny of metrics literature does not quite reach.

This is an intervention at the level of perception, at the moment when the operator looks at the surface and forms a question. The tagline is a designed constraint on that moment. And like all designed constraints, the question is not whether it shapes the person using it; it does, always, but whether that shaping was chosen deliberately or arrived by default.

Most dashboards arrive by default. They inherit their epistemology from the conventions of the genre, encode the assumptions of whoever held the most authority in the room when the schema was designed, launder those assumptions into apparent neutrality, and call the result objectivity. The philosophy is not absent. It is just invisible, which means it cannot be examined, which means it cannot be wrong.

That invisibility is not a technical limitation. It is a choice — one that gets made again every time a dashboard is built without asking what kind of knowledge it is actually capable of producing, for whom, and at whose expense.

Seven years of building dashboards the other way taught me what that cost looks like in practice. It looks like a metric trusted further than it can carry. It looks like a question the data cannot answer, asked anyway, because the organisation needed something to put in the slide. It looks like knowledge that never made it out of the analyst’s mouth because the interface had already settled the question in advance.

The alternative is not more rigorous data. It is more honest design.