Build Log #02: From a single-file dashboard to a working program-improvement system

The short version: I asked a colleague for a real problem to point my build system at, and what came back looked finished and could not be used. Working out why cost me my definition of the word done.

A couple of weeks ago I asked a former colleague to lend me a problem. I wanted to point PRISM, the assembly line of AI tools I build with, at something I had not invented myself and was not starting from scratch on, because a system that only works on your own tidy ideas has not really been tested. They had a program-improvement tool with its own dashboard, built with AI, that had grown into one enormous read-only file. It could not write or capture anything, which is exactly what my colleague was eventually hoping to add.

I want to be fair to that file, because it was not junk. It had years of hard-won operational knowledge in it: goals, performance measures, recurring work, diagnostic tools, site information, and password-protected views for different audiences. Next to the pile of documents and spreadsheets it replaced, it was a real step forward, and you could see what the team had been reaching for.

You could also see where it stopped. Every audience needed its own view, and any change meant going back to the AI and rebuilding the whole file. The passwords kept screens apart, but there were no real accounts behind them, no permissions, and no records that knew about each other. It could show you everything the team knew. It could not take a concern and move it through assignment, action, evidence, review, and completion. It was a very good picture of the work, and the work still had nowhere to go.

So I did not rebuild it. I read it. The file was the best record I had of how that team actually talks: their language, who owns what, which tasks come around every month, what they report on, and where the real decisions get made. I used PRISM to turn that evidence into a fresh plan for the data, the permissions, the workflow, the interface, and the tests. Reusing the original code would have dragged its duplicated views, its password model, and one organization’s private data into everything built afterward.

That produced 2 applications on purpose. One is tailored to the original team, in their language and their visual identity. The other is a reusable edition with its own design system, light and dark themes, invented sample data, and nothing of the original team in it anywhere. Keeping them apart is what stops one organization’s assumptions from quietly becoming everybody’s defaults.

The reusable edition came out well, and it does the thing the dashboard could not. A team can set up sites and users, control who sees and changes each record, define goals and measures, document a finding, turn it into an improvement effort, assign an owner and a next action, attach evidence, submit the result for review, produce reports, export the data, and restore a backup. Those connections are the product. If a measure looks wrong on Monday, there is a path from noticing it to somebody owning it, and the path survives a reload and a restart. It passed its installation, access, workflow, reporting, export, saved-data, recovery, mobile, keyboard, and theme checks.

The tailored edition is where I got caught.

It had a real database. It had working actions. It could create cases, record diagnostic evidence, generate reports, and keep an audit history. I called it complete, and I was wrong, and it took using it like a program manager to see why.

Several screens showed you information without giving you any way to carry on from there. You could find a coaching record and have nowhere on that screen to act on it. One status label looked exactly like a button while the real control sat out on the surrounding row, and clicking the real one updated a different part of the page without moving your attention to it, so on a smaller screen a successful action looked like nothing at all had happened.

The tests had been telling me it was fine, and they were not lying. They were answering a different question. Some of them sent information straight to the application behind the interface, which proves the database can receive it. It does not prove that a program manager can find the record, understand what to do next, do it with the controls actually on the screen, and see the result still there tomorrow. On top of that, test data and review data shared the same space, so every run filled the app with fictional records, and the main dashboard loaded nearly every record it had and did it again after every save.

Here is what I had actually done. I had treated 3 different achievements as if they were one: the database supports the work, the interface exposes some of that, and a person can finish the work. Only the third one means anything to the person using it. A database can hold a goal without anyone being able to assign, update, review, close, or reopen it. An app can save feedback without the team having anywhere to decide what happens because of it. Neither gap shows up in a database diagram, and neither shows up in a test that skips the interface.

So the standard changed. The checklist that decides whether a build is done, the acceptance criteria, now has to describe the whole life of every important record: who creates it, who changes it, what proof it needs, how it closes and reopens, what survives a refresh, and what happens when 2 people change it at once. The automated browser test then has to complete that work through the same controls a real person would use. Test data stays out of the space where demonstration and daily work live.

That is a change to PRISM, not just to this build. PRISM gave the work a disciplined path from discovery through verification, and this build showed that a disciplined path is only as good as its definition of finished.

The full Hub solves more than most people need at once, so I pulled one complete workflow out of it into something smaller: a Program Needs Assessment Starter. It runs a ready-made assessment or one you write yourself, saves work in progress, ranks the strongest concerns, turns one concern into an assigned next action, and keeps finished assessments for review. It runs in a browser with no account and no hosted database.

An intake form can collect answers and stop. This one has to help somebody decide what deserves attention and record what will happen about it. That handoff, from finding to action, is the part of the bigger Hub you can use today.

Open the Program Needs Assessment Starter:

Extract the ZIP, open index.html, and start with the ready-made questions or write your own.

The tailored edition still needs correcting before it can be anyone’s day-to-day system. The honest result of this build is a verified reusable foundation, a harder standard for what PRISM has to prove, and a small tool that solves one piece of the original problem completely.

These screens use fictional data and show the assessment moving from saved work to transparent priorities and one assigned action.

The starter saves an assessment in progress in the browser. No account or hosted database is required.

Each priority shows the answer, its importance, the score out of five, and a plain explanation of why it moved forward.

The selected concern becomes one named action with an owner, due date, and completion proof.

What are you calling done right now that nobody has actually tried to finish? Hit reply and tell me. I read every reply.