The Problem
I run a large personal ecosystem — scheduled AI briefings, automation containers, a knowledge vault, an execution system, several deployed sites. It was well documented and architecturally sound. It was also, I discovered, structurally unable to notice its own failures.
A four-domain audit surfaced what had been quietly true for months:
- Three of five scheduled briefings were silently dead — the daily one for roughly three months
- Two automation containers had been down for three days, with no restart policy and no notification
- Disk was consuming about 5 GB per day toward critical, undiagnosed
- Constitutional documents had been contradicting live reality for weeks
- The one health-checking routine was structurally incapable of seeing any of the above
The failure mode is worth naming precisely, because it generalises: every component was individually healthy and reporting nowhere. There was no surface where the system as a whole spoke to its operator. Adding another dashboard would have added a sixteenth thing to check. The gap wasn't monitoring. It was orientation.
The Real Constraint
The hard constraint wasn't technical. It was attention.
I'm ADHD-diagnosed and a TBI survivor. A tool that demands vigilance to be useful is a tool I will abandon inside two weeks — and I have the graveyard of abandoned productivity apps to prove it. So the design brief wasn't "surface all system state." It was harder:
"Design for the worst morning, not the best."
That single constraint generated almost every subsequent decision. It ruled out completeness, ruled out configuration, ruled out anything that rewards frequent checking, and ruled out the entire visual language of urgency that monitoring tools default to.
Five Decisions That Did the Work
1. It observes, it doesn't own
Compass holds zero primary data. Every fact it displays lives somewhere else and is read, never authored. The test I held it to: delete Compass tonight and lose nothing. This is what makes it safe to depend on — it can never become another system requiring backup, migration, or care.
2. Trust is the feature
Every datum carries its age. Every inference carries its confidence. And critically, "the monitor itself is down" is a first-class state — not an error, not a blank screen. A monitoring tool that can't report its own failure is exactly the tool that just failed me for three months. Compass is built to admit when it doesn't know.
3. A hard three-item cap, and one next move
The interface refuses to show more than three things needing attention, and surfaces exactly one recommended next action per day. Not a prioritised list — a single move. Lists defer the decision back to the reader; on a bad morning, that deferral is where the tool loses.
4. Silence is a deliverable
"Nothing needs you" is a proud success state, designed with the same care as any alert — not an empty state, not a placeholder. Most tools treat quiet as absence of content. Here it's the product working. The notification budget is roughly zero to two pushes per week, by design.
5. Anti-shame defaults
No streaks. No completion percentages. No red walls. Failure cards carry cause, repair, and a one-tap consent-gated fix — never a scold. A system that makes you feel bad for the state it's reporting is a system you'll stop opening, and a monitoring tool you don't open is worse than none.
The Mark Carries the Thesis
The identity brief was "a quiet instrument, not a demanding app." The mark is a compass rose reduced to its minimum honest form:
- The ring is a 300° arc with a deliberate opening — the system is never "done," only oriented. It also reads as a progress ring at rest: calm, not counting.
- The needle is the whole product thesis in one shape. The north blade is solid — what matters now. The south blade is outlined — context you can safely ignore. Signal versus safe-to-ignore, drawn.
- The pivot dot is you. Everything rotates around a fixed centre.
It's single-colour and inherits currentColor, so nav bar, favicon, dark mode and embeds are all the same asset. Zero variants to maintain — which is itself an ADHD-first decision.
Chromatic Silence
The base interface is near-monochrome and saturated colour is reserved exclusively for status semantics, so colour always means something. When everything can be coloured, colour stops carrying information — that's how monitoring dashboards become wallpaper.
Status appears as small dots and thin bars, never flooded card backgrounds. A wall of red is panic, not information.
The accent — an amber called north-500 — was chosen over the obvious blue or teal for three converging reasons: it reads as warm daylight, it stays distinguishable from the semantic green/red pair for colour-blind safety, and warm-on-ink survives iOS Night Shift without turning to mud. One amber element per screen, maximum.
Type is the system stack, deliberately: zero download cost for an offline-first app, and a native feel — Compass should read as part of the phone, not as a website. Four sizes only. Weight does hierarchy; size does structure.
One Correction Worth Recording
The first specification assumed the system font stack would inherit iOS Dynamic Type, giving accessible text scaling for free. It doesn't — Dynamic Type does not propagate into PWA web content. A design review caught it before build.
Compass therefore ships its own text-size control as a root rem multiplier, with all type authored in rem against the four-role scale so hierarchy survives scaling. It's a small fix that would have been an accessibility failure shipped silently — and for an audience of one who needs it, a fatal one.
Architecture
Two new components, everything else reused:
- A collector — one hourly script that reads signals which already exist (health JSON, tooling snapshots, file heartbeats, container, scheduler, git and disk state), checks each against a declared cadence contract, runs deterministic failure diagnosis, and pushes a single authenticated state object. Personal state never touches a public URL.
- A surface — a static, fully offline-capable installable PWA. Four screens, two levels deep.
The intelligence layer is deliberately two-tier: deterministic first, AI second. Heartbeats are arithmetic on file timestamps, not model calls. AI annotates facts; it never is the facts. And the scheduler runs locally rather than in the cloud — specifically because the cloud scheduler is the thing that failed silently for three months. The failure taught the architecture.
Recurring cost: approximately zero.
Status — Honestly
Phase 1 is shipped and live. The collector runs, the PWA is installed on my phone, and the two-minute morning loop is real. It is in daily use by its intended user.
Phase 0 — repairing the failures the audit found — is partially complete; the disk trend remains open. Phase 2 (the opportunity engine and blind-spot narratives) is specified and unbuilt. Phase 3 exists only as a condition: build it only if Phases 1 and 2 become habit.
The success criteria I'll judge it against at six months are deliberately falsifiable: zero silent failures lasting more than 48 hours, at least one acted-on insight per week, under fifteen minutes of maintenance per month, and what I called the Prove-It test — seven days away, one screen, fully re-oriented.
What This Project Taught Me
Designing for your own constraint is the sharpest brief there is. There was no persona to hide behind and no research to interpret — if a decision was wrong, I'd feel it the following morning. Anti-shame defaults, the three-item cap and silence-as-success weren't chosen from a pattern library; they were chosen because the alternatives had already failed me personally.
The most valuable thing an observability tool can do is admit ignorance. The whole project exists because a health-checker couldn't see its own blind spot. Building "I don't know" as a first-class state — rather than a gap — is the design decision I'd carry into any product handling uncertainty, which now means most products with AI in them.
And restraint is harder to design than capability. Every screen was an argument against adding something.
How It Was Made
Compass was designed and built AI-assisted throughout, working with Claude across audit, specification and implementation — and reviewed by adversarial agent passes that caught real errors, including the Dynamic Type failure above.
The product direction, the constraints, the design principles and every judgment call are mine. I'm noting the method explicitly because it's how I work now, and because a case study about trust that was vague about its own provenance would be a poor advertisement for the principle.