Myles MellorCommercial, digital & marketing operator
← Systems

A read-only window over the whole operation

A static dashboard assembled from the workspace and run only on my own machine — one pane over projects, ideas, memory and more, with a chat tab that answers from my own material. It can read everything and change nothing.

I built a dashboard that pulls the whole operator system into one view. The design choices that matter: it's read-only by construction (it can't alter what it shows), it's regenerated from source rather than kept as a second copy to drift, and it runs only on my machine — because what it displays is real client and personal material. I'm describing it rather than showing it, for exactly that reason.

Running a portfolio of projects, a stack of custom tools, a memory layer, a learning system and a backlog of ideas produces a lot of state. The natural failure is losing track of it — what's active, what's stalled, what's been parked, what changed this week. So I built a dashboard: a single pane that pulls all of it into one place. Building it was the easy part. The three constraints I built it under are what's worth explaining.

It reads; it never writes

The dashboard is assembled from a set of small read-only adapters — one each for projects, ideas, the memory layer, daily notes, the skills matrix, git activity, and so on. Each one only reads from the workspace. There is no path back: the dashboard cannot edit, delete, or write anything to the system it's watching.

That's deliberate. A dashboard that can also act on what it shows is a dashboard that can corrupt the thing you rely on it to report honestly. Keeping it strictly read-only means I can trust it as a mirror — and it means a bug in the dashboard can never damage the underlying work. The power it deliberately doesn't have is the point.

It's regenerated, not a second copy

The workspace files are the single source of truth. The dashboard is a derived view, rebuilt on demand from those files — never a parallel copy I have to keep in sync. This matters more than it sounds: the most common way a dashboard starts lying is that it becomes a separate store that quietly drifts from reality. If the only way to change what the dashboard says is to change the underlying work, it can't drift. It's static HTML plus a small local server — no database, no framework, nothing to fall out of step.

It runs only on my machine

This is the constraint that shapes everything else. The dashboard is a window over real, sensitive material — live client work, personal finance, the memory of how I operate. So it runs only on localhost, is marked not to be indexed, and is never hosted or deployed. I can show how it's wired; what's on the screen stays on the machine.

That constraint is also why this page is a description rather than a screenshot. Everywhere else on this site I show real product screenshots — but a real shot of this dashboard would put client names and private material on a public page. So the honest move is to show you the architecture and the reasoning, and keep the glass facing inward. The diagram above is doing the job the screenshot would, without the cost.

The one piece that does more than display

There's a single exception to "read-only": a chat tab that lets me ask the workspace questions in plain English and get answers grounded in my own material, with citations back to the source file. Even that only reads — it retrieves and summarises, it doesn't change anything. It's the same retrieval layer described in how memory works, surfaced where I actually look.

Put together, it's a cockpit, not a control panel: it tells me the true state of the operation at a glance, it can't break what it monitors, and what it knows never leaves the room.