← Back to demo

Systems · The desk

A command center for one person

Every morning used to start with six tabs and a feeling. Now it starts with one screen that knows what ran overnight, what broke, and what is waiting on me — and nothing else.

The Command Center, runningFour intake sources flow into the vault of plain-text notes. Six scheduled jobs run against it; one falls back to a backup source and is then reported as a failure. The Command Center screen shows decisions due, the overnight runs and the failure. A person approves; the only way back into the vault is that approval. Sample data.SAMPLE DATA · ILLUSTRATIVE COUNTSMailClippingsVideoWork notesINTAKEThe vault5,120 notesPLAIN TEXT · ONE HOME EACHSCHEDULED JOBSInbox drainNightly mirrorGraph rebuildHealth checkFeed scanShare draftCOMMAND CENTER · 06:40FAILED · 1Graph rebuild ran on its backupsource — output fresh, input staleDECISIONS DUE · 3Approve three share drafts›Review a routing miss›Renew a certificate›OVERNIGHT · 14 RANSuccesses take one line. Failures take the top.Reads everything · writes nothing without meMeTHE JUDGMENT CALLTHE ONLY WAY BACK IN: AN APPROVAL
Command Center diagram
Fig. 01 — The Command Center, running. Sample data: one job falls back quietly, then gets reported loudly. Reads everything; writes nothing back without me.

What was failing

The second brain worked. That was the problem. Dozens of scheduled jobs were filing, refreshing and summarising overnight, and each one left its evidence in a different place — a report here, a log there, a dashboard somewhere else. Checking that the machine had done its job had quietly become a job.

Worse, the failures that mattered were the quiet ones. A job that falls back to an old source and succeeds looks exactly like a job that worked.

Sample night: fourteen scheduled runs between 10 pm and 6 am. One falls back to an old source at about 1 am and looks fine; the morning report marks it failed.SAMPLE DATA · THE SAME INVENTED NIGHT10p11p12a1a2a3a4a5a6afell back · looked fine6:00 report: 1 failed
Fig. 02 — The night before the screen. Sample data: one run falls back at 1 am and is only called a failure in the morning.

What I built

A small web app that runs on my own laptop and reads the vault directly. No cloud service, no database of its own, no second copy of anything. It shows three things, in this order: what needs a decision today, what ran overnight and whether it was fresh, and what failed.

The rule it is built on is the vault's own: failures loud, successes silent. A job that ran cleanly takes up one line. A job that failed, or that succeeded on stale inputs, takes up the top of the screen until I deal with it.

What changed

Mornings start in one place. The question stopped being "did everything run?" and became "what do I have to decide?", which is the only question that was ever mine to answer. The quiet failures are the work still in progress: the jobs that feed it are being taught, one at a time, to report which source they actually used, so the screen can show that instead of whether the output looks recent.

What you can inspect

The running diagram above — sample data, acting out the one failure the app exists to catch — and the principles it runs on, which are written up with the rest of the system on the second brain architecture page. The app itself reads real personal and work data, so it is not shown here.

What isn’t proven

There is no screenshot of the real app on this page on purpose. The figure is a diagram with invented counts, not the software. A version of the app itself that runs on invented data — so it can be clicked through in a meeting — is the next step, and this page will say so when it exists.

It is also built for one person. Whether the same pattern holds for a team, where "what needs a decision" has several owners, is a question I have not tested.