North Star: one kernel, many instances
At a glance
- What it is: the stable reference every build decision points back to
- Status: Reference
- Rule: a new feature idea must name the Job, Principle, and kernel layer it serves, or it waits
The North Star
One private system of record running one personal operating system: a kernel of invariant rules, instantiated per domain (work, life) as configuration. It runs on infrastructure I own, captures automatically wherever possible, and costs near-zero effort to operate.
The operator has a demanding job and a full life outside it: home, relationships, travel, and health all competing for the same hours. A system that adds maintenance load will be abandoned by February, as the 2026 PRD was. Every design choice optimizes for “still running untouched in three weeks.”
For now, reliable tracking and sensemaking first. Capture what’s actually happening (metrics, statuses, history) and render it visible. The capacity layer is designed but deferred until real tracking data exists to calibrate it. Track → understand → then govern.
The kernel/instance model
There is one operating system. Its work instance simply has more mileage: it’s being extracted, made portable, and re-instantiated for life. An instance is the kernel plus configuration.
Kernel (invariant across instances)
- Structure layer (PARA): the lifecycle + graduation rules. Inbox is transient, 2-week rule, promote-or-archive; buckets defined by purpose, not content.
- Flow layer (GTD): the engine. Capture → clarify → organize → engage; routines as standards-enforcement.
- Capacity layer (from the PRD, deferred): ceilings as an attribute any entity can carry; sequencing constraints (one peak per period); signals → downshift (telemetry evaluated against rules, with degradation as the default response to overload). Design in Capacity layer; activation gated on tracking data.
- Record layer: entities with stable IDs, a locked state vocabulary, append-only history/snapshots, and a review cadence that keeps recorded state honest.
Each layer answers a question the others can’t: where things live, what moves, how much and when to stop, what happened. The kernel test: a new idea either extends one of these four answers (it’s config or a layer extension) or answers a genuinely fifth question (rare; notice when it happens).
Kernel primitives
Most of these concepts are borrowed from The PARA Method by Tiago Forte and the original GTD by David Allen
The layers all work on the same small set of building blocks. Every instance uses these, whatever the domain:
- Inbox: where things land before they are sorted. Nothing stays.
- Project: committed work with a finish line.
- Area: an ongoing responsibility with a standard to maintain. It has no finish line, and it holds the backlog of work not started yet.
- Routine: a repeatable cadence that keeps an Area’s standard met.
- Resource: reference material that supports Projects and Areas.
- Archive: anything done or no longer true.
- Status: one shared vocabulary for why something is or isn’t moving (
inbox,active,review,blocked,paused,done).
Instance configuration (per domain)
An instance is the kernel with its variables filled in for one domain. There are two today. Work is the older one, and it is where the kernel was extracted from. Life is being set up on the same kernel. They are different values for the same variables, not different systems.
| Variable | Work | Life |
|---|---|---|
| Areas | access management, platform, observability | home, health, finances, relationships, travel |
| Capacity rules | at most 3 active workstreams | burnout signals, weekly hour ceilings, one peak per quarter (parked) |
| Capture sources | session summaries, standup reports | sleep, activity, weight, screen time |
The 2026 PRD, reframed
The PRD failed structurally, not motivationally: it was written as a sibling system with its own taxonomy instead of in the primitives inhabited daily. Its modules dissolve into kernel primitives: certs and the hike are Projects; weight and savings are Area standards enforced by Routines. What remains after dissolution is its real contribution, promoted into the kernel: the capacity layer (ceilings, sequencing, signals→downshift). The PRD is now a historical source document, not a live spec.
Jobs
- Job A: “Remind me what I know.” Retrieval over the vault(s). Served by retrieval. Proceeding.
- Job B: “Show me what’s actually happening.” The current focus: metrics flowing automatically, statuses snapshotted with history, honest dashboards. Sensemaking before governance. This data also calibrates the capacity layer later.
- Job C: “Hold everything, forever, mine.” Markdown for knowledge; structured stores (SQLite/Postgres) for time-series and status history, equally self-hosted. Format follows the data’s shape; ownership is the invariant.
Principles
The order matters. When two principles pull in different directions, the higher one wins. For example, a phone app that syncs through someone else’s proprietary, opaque cloud would serve principle 5 and break principle 1, so it does not get built.
- Ownership & privacy first: all data on owned infrastructure; anything transmitting outward is explicit, enumerable, and scoped.
- Boring to operate: automation > motivation applies to the system itself. Prefer automatic capture, generated dashboards, alerts that find me. If a feature needs a new habit to stay alive, redesign it.
- Past knowledge must be findable: fast, precise, trusted.
- The system reflects reality, not aspiration: honest signals, actual statuses, gaps rendered as gaps. It shows what happened and stops there. A missed day is a gap in the chart, not a broken streak, and nothing is colored as good or bad (see FR-33).
- Available where I am: having the system on my phone makes it more useful. It is not a goal by itself, and it never justifies bending principles 1 to 4.
How things get in
There are three routes, listed from least effort to most. The system leans on the first one as much as it can.
- Devices log it for me: anything a device already measures, like sleep, activity, weight, and screen time. I opt in one source at a time, and the data lands only on hardware I own.
- I tap it in: the few things no device knows, like mood. It has to take ten seconds or less on my phone. If it takes longer, it is in the wrong route.
- I sit down and write it: notes, decisions, the story of what happened. Writing is never required just to keep a metric alive.
How things get shown
Markdown is for reading; state is for seeing. Job B outputs are generated visuals (heatmaps, trends, status boards), never hand-maintained. Grafana on the homelab is the natural end-state; generated in-vault dashboards are the accepted v1. Rules fire as alerts, not charts to remember to check.
Boundaries
- Not a publishing platform; not multi-user.
- Not an autonomous agent, for now: today it alerts and I decide. If it ever acts on its own, that is a new decision with its own spec, not something that creeps in.
- Not a methodology redesign: the kernel generalizes what already works. Extraction, not invention.
- Not a quantified-self platform: a metric is only tracked if it is on the tracked list (O-C); “interesting someday” is not a reason to measure something. Notes are the opposite: capture anything, and let the inbox rule (sort it or archive it within two weeks) keep it from piling up.
- Building it obeys its own rules:
- Foundation work: work that reduces future effort and risk.
- Ceiling-bound: it has an effort ceiling, not an output target, and it pauses when the rules say pause.
- Stop-anywhere: each phase can ship by itself.
Success criteria
- S1. Retrieval consulted daily because it’s faster than remembering.
- S2. 21-day autopilot: sleep/weight/activity flowing to the owned store and rendering with zero manual touches.
- S3. Subjective capture ≤10 s phone-first, used even in a hard week.
- S4. The downshift rule fires as an alert on real or drill data.
- S5. Status history survives file moves/deletes.
- S6. Outward data flows enumerable on one hand.
- S7. Still in daily use, and still boring, a year from now.
- S8. Enough weeks of honest tracking data exist to set budgets and costs from evidence, not guesses. This one gates capacity work.
Decision log
Settled
- One kernel / instances-as-config (The kernel/instance model)
- PRD dissolved, capacity layer promoted (The 2026 PRD, reframed)
- Track first, govern later: capacity deferred, not abandoned (The North Star)
- Three capture routes (How things get in)
- State is generated, never hand-maintained (How things get shown)
- Markdown for knowledge, stores for time-series/status
- Single-user
- Build-under-ceilings
Open
- O-A. Where exactly did the PRD die: capture, surfacing, or teeth? Tracking data will partially answer this.
- O-B. Quick-capture mechanism (Shortcut → drop file is the working plan; mobile app inherits later).
- O-C. The definitive tracked list: PRD signals + named habits. Blocks the first heatmap; 15 minutes of honesty.
- O-D. Capacity calibration (unit: hours vs. abstract slots; where the budget lives; real costs). Answered by the tracking data; revisit within ~a quarter.
The doc map lives on the OrionOs hub.