Back to work
Systems Design · AI-Native · Personal OS

EOS

An Execution Operating System designed from the inside out — built by and for someone who thinks in missions, not tasks; in sprints, not calendars; in energy, not willpower. A personal productivity infrastructure for an ADHD brain that has to ship real work.

Role: Designer, builder, operator Stack: HTML/CSS/JS · Notion · Claude Code Status: v1 feature complete · June 2026 Type: Personal infrastructure · AI-native workflow
Most productivity systems are designed for people who already know what they should be doing. EOS is designed for the harder problem: maintaining clarity and execution under the cognitive conditions that actually exist.

The Problem

Standard productivity systems — GTD, OKRs, Notion task databases, project management tools — are built around a set of assumptions: that the person using them has consistent executive function, that they can maintain the discipline to update systems regularly, and that task completion is the primary unit of work. For a substantial portion of people — including many of the most creative and high-output ones — none of these assumptions hold reliably.

Living with ADHD means that the cognitive overhead of maintaining a productivity system can consume more energy than the system saves. It also means that "What should I be working on right now, given my actual energy level, and what is the single most important thing?" is a question that needs to be answered quickly, clearly, and repeatedly — without requiring a system to be in perfect shape before it can answer.

I designed EOS to answer that question. Not as a task manager. As an operating system — a coherent infrastructure that holds the state of execution across missions, sprints, health, and context, and surfaces the right thing to act on now.

What I Built

EOS Mission Control dashboard — priority mission M001 Deploy Portfolio (EV 89, Sprint Day 5) with Blocker, Opportunity, and Decision panels; Today's Top 3 tasks; Command Panel shortcuts for Portfolio, Solace, Community Ride, and Job Search; EOS score 34/100
Mission Control — the single truth surface. Sprint Day 5, M001 Deploy Portfolio active.

Mission Control — the single truth surface

The primary interface is Mission Control: a real-time dashboard that shows the three most important things to do today, the active mission currently in focus, recent activity, health indicators, and the current sprint's mission stack. Everything visible is a decision — what to show here, at this time, is a product decision about what information a person needs to act well.

The design principle: one screen should give a complete picture of "where am I, what matters most, and what is the state of my execution?" A person coming back to work after a break should need to look at exactly one place.

Mission structure — not tasks, not projects

EOS organizes work as Missions — goal-oriented work packages with an Execution Value (EV) score, a progress arc, and a focus state. Missions sit above tasks (which are ephemeral) and below the overall system (which is strategic). The EV score is a composite measure that reflects both the mission's importance and its current momentum — a mission that is important but stalled surfaces differently than one that is important and moving.

The sprint view shows four active missions simultaneously, each with an EV score that allows instant priority sorting: M001 Deploy Portfolio (EV89), M002 LinkedIn Posts (EV74), M003 Solace Guide (EV73), M004 Fit'sMe Case Study (EV62). The person doesn't have to decide what's most important — the system holds that decision, updated continuously.

Health as a first-class input

The Health panel — Sleep, HRV, Energy, Steps — is not a wellness feature bolted onto a productivity tool. It is an execution input. A person's cognitive capacity on any given day is a direct function of their biometric state. A system that plans ambitious work for a day when sleep was 5 hours and HRV is suppressed is planning against reality. EOS surfaces health data alongside mission data so that the executive function available and the demands being placed on it are always visible together.

Three-layer architecture

EOS is built across three layers that each serve a different function:

  • Mission Control dashboard (HTML/CSS/JS) — the execution surface, read-optimized, the face of the system at work.
  • Notion — the operational editing layer, where missions, tasks, and context are created and maintained. Five databases under an EOS Hub: Missions, Sprints, Inbox, Wins, and Context.
  • Claude Code — the sync bridge, pulling the state of Notion into the dashboard and into a persistent EOS_STATE object that other systems (including MARVIS) can read.

The three-layer architecture keeps each layer doing what it does best: Notion for structured editing, Claude Code for intelligent sync and state management, and the dashboard for clean, distraction-free execution.

Mission Control HTML / CSS / JS Execution surface read-optimised · distraction-free state push Claude Code Intelligent sync bridge reads Notion → builds EOS_STATE feeds dashboard + MARVIS read / write Notion Operational editing layer Missions · Sprints · Inbox Wins · Context always visible always current always editable

Focus Mode

The "Enter Focus Mode →" CTA on the active mission is not a feature — it is the whole design intent compressed into a button. EOS is not about tracking work; it is about enabling the transition from "aware of what needs doing" to "actually doing it." Focus Mode removes the dashboard, narrows the interface to the single active mission, and creates the conditions for deep work to begin.

Key Decisions

Zero-friction output routing

One of the two governing design principles of EOS: the system always knows where to save something. There is no moment where execution pauses to decide "where does this go?" Wins go to Wins. Tasks go to Inbox for triage. Notes go to Context. The routing is baked into the architecture, not delegated to the user's judgment in the moment. This matters most precisely when executive function is strained — which is when the system needs to be most reliable.

EV scores as continuous priority

Standard priority systems require the person to manually reprioritize as circumstances change. EV scores in EOS are computed continuously — incorporating mission importance, current progress, time pressure, and energy state — so that the priority stack is always current without requiring deliberate maintenance. This is the AI-native insight: intelligence in the system reduces the cognitive overhead of using the system.

Drift detection as a discipline

The second governing principle: after multi-system sessions (when Claude Code, Notion, and the dashboard have all been active), EOS audits connected systems for drift — divergence between what one layer thinks is true and what another layer reflects. This is a safety mechanism against the most common failure mode of AI-assisted systems: quiet inconsistency that compounds invisibly until it becomes visible as a major error.

Architecture frozen at v1 completion

On June 29, 2026, EOS reached v1 feature completeness and the architecture was frozen. The governance principle: no changes unless a change removes friction, simplifies the system, or unlocks execution. This is a deliberate constraint against the most common productivity-system failure — the system that is always being refined and never being used. EOS v1 is the operating system. It exists to be operated.

Outcome

In daily use since June 2026 — managing job search, 4 active product tracks (Solace, NuvAI, MARVIS, Voice Agent Behavior Lab), and this portfolio build simultaneously. A running, AI-native execution infrastructure that operates coherently without a dedicated operations person. The system is its own primary operator.

For any team hiring a systems-thinking designer with AI-native fluency: EOS is not a case study about a client's problem. It is a demonstration of what happens when the same design rigor I apply to client work is applied to the problem of staying in execution under the conditions that actually exist. It works. It is running. It is the infrastructure I used to build everything else in this portfolio.