LifeOS

What changed

Before LifeOS, nine separate Cowork projects each held a slice of my admin life. Finances was one project. The car was another. Pensions, dentist search, insurance, subscriptions, and three further sensitive domains each had their own scratchpad. None of them could talk to each other.

The change is not that the data is tidier. The change is the set of questions that became askable.

Before, “which of my subscriptions are at risk this month because of a card that has changed?” required pulling up the finances workspace, then the subscriptions one, then cross-referencing by hand. Now it is a single question against the spine. The answer comes back with the at-risk lines, the renewal dates, the cards on file, and whether the renewal will route through Apple Pay or Stripe.

Before, “is anything in the pipeline that touches both the car and finances this week?” was not a question I could ask. The two workspaces did not share a calendar. Now the calendar lookahead and the daily ingestion pipeline both write into one shared spine, and the cross-cut is a single read.

Before, an inbound scanned letter sat in iCloud until I noticed it. The relevant workspace had to be opened before anything happened. Now it lands in the inbox, gets classified into the right domain on the next scheduled sweep, updates the domain context file, and surfaces as a pending action with a deadline and a proposed next step.

The problem

The starting state was nine standalone Cowork projects across three years of admin life. Each one was useful in isolation. Together, they had three failure modes that compounded.

The first was that cross-domain questions were not just slow, they were not askable. The context window made it impossible to load more than one workspace at a time without burning a turn on file shuffling.

The second was that the same fact lived in two or three places. A recurring direct-debit figure lived in the subscriptions register, in the finances workspace summary, and in the pensions context if it was a pension contribution. When one of them drifted, the rest did not know. Reconciliation was a manual chore.

The third was that ingestion was per workspace. Each project ran its own scheduled task to scan the relevant inbox for new items. The finance workspace watched for subscription renewals. The car workspace watched for warranty and dealer correspondence. Each sensitive-domain workspace watched for its own kind of inbound mail. Five separate monitors, each loading the same three Apple Mail accounts, parsing the same headers, producing overlapping work. The token cost was paid four or five times over for the same sweep.

LifeOS was the rebuild. One project, three tiers, eight domains, one ingestion pipeline, one decision log.

System overview

The filesystem is organised so the amount of content loaded into a conversation scales with the task, not with the size of the knowledge base.

Tier 1, the spine, always loaded. Five small, stable, cross-domain files in shared/. Identity, money-spine, people, calendar, and the append-only ingestion log. Tier 1 is tuned to stay under about ten kilobytes of markdown so it fits comfortably in context on every turn. It is the persistent working memory.

Tier 2, the domain packs, lazy-loaded. Each of the eight domains has a folder with a CONTEXT.md file, one or more extension files, and an artifacts/ directory for source PDFs, CSVs, photos, and the SQLite database that holds the full transaction history. Domain packs are only pulled into a conversation when the work is in that domain.

Tier 3, the archive, cold. A snapshot of the nine old projects, kept for audit and rollback. Nothing in tier 3 is loaded into a conversation unless explicitly referenced.

The single design rule across the tiers: each fact has one home. The recurring-charge amount lives in the money-spine; the subscription register holds the per-line metadata. When one updates, the other reads from it rather than mirroring it. Cross-domain summaries reference sensitive-domain particulars only by opaque handle.

Daily ingestion

Ingestion is the part that earns LifeOS the right to call itself an operating system rather than a folder.

Every morning at 05:30 local, a scheduled task fires the daily-ingestion orchestrator. The orchestrator sweeps four sources in sequence. Apple Mail, three accounts (personal, work, study). The Preview iCloud scans folder, which is where Continuity Camera and “Import from iPhone” drop scanned letters. The local Downloads directory and the iCloud Downloads directory, deduped against each other. And inbox/raw/, the manual drop zone for anything I forward or drag in between runs.

Everything new lands in inbox/raw/ with a timestamped filename. The orchestrator does not classify; it sweeps.

For each item, the orchestrator hands off to a per-item primitive, ingest-triage. The primitive reads the artefact, OCRs it if it is a scan, converts office formats with markitdown, and classifies into one of the eight domains using a shared rulebook in INGESTION-KNOWLEDGE.md. It then writes in four places at once: the domain CONTEXT.md file gains a row in Active Items or Key Facts; the spine receives a write-back if a recurring figure changed; the calendar gains a dated event if one is implied; and the append-only ingestion log gains one row recording what arrived and where it went.

If the item needs a human decision, the primitive writes a pending-action brief into inbox/pending-action/ with a deadline and a proposed next step. The next session I open shows it on the dashboard.

After every run, a deterministic conformance pass walks the vault, applies structural tags from path inference and content tags from a curated rules engine, fixes wikilink drift, and updates the cross-domain Map-of-Content blocks. The pass is idempotent and safe to re-run; it is what keeps the knowledge graph honest without human upkeep.

Per-domain answers

Each of the eight domains now answers a question that no single workspace could answer before. The five non-sensitive domains are named here; the three sensitive ones are grouped as “sensitive” with their shape described but their identity withheld.

Finances. Which subscriptions renew in the next fourteen days, and which ones are still on a card that has changed? A single read against the money-spine plus the subscriptions register, cross-cut with the calendar.

Pensions. What is the projected aggregate at the standard retirement age, given the current pots, and which pot is the worst on fee drag? Pensions context plus the spine.

Car. What warranty work is outstanding, and is the PCP balloon date still on the calendar at the right amount? Car context plus money-spine plus calendar.

Insurance. What policies are live, when do they renew, and which renewals are tied to a card that has changed? Insurance context plus calendar plus money-spine.

Dentist search. Which NHS practices have I contacted, which are open to new patients, and when can I follow up? Domain context plus calendar.

The three sensitive domains are not named on this page because the particulars are personal correspondence, legal cases, or job applications in flight. The architectural point is what they share: every artefact tags audience/sensitive, the cross-domain ingestion log records only opaque metadata, and every cross-domain report excludes them unless explicitly asked for. The system enforces the boundary; the reader does not need the labels to see how.

Failure and fix

The version-one shape was a separate scheduled task per domain that needed monitoring. There were five of them, one per domain that had inbound correspondence to watch. Each task opened the same three Apple Mail accounts, loaded its own domain context, ran its own subject-line classifier, and wrote into its own domain folder.

Three problems showed up within a fortnight.

The first was overlapping work. Each domain monitor read the same inbox, hit the same Apple Mail MCP, and reparsed the same headers. The token cost for one sweep was paid four or five times. The bash sandbox was hitting timeout ceilings on the larger runs.

The second was misclassification. Each per-domain monitor was strict about what it would claim, but lax about what it would let pass. An email that genuinely touched two domains would be caught by neither, because each monitor’s classifier saw the other domain’s keywords first and bailed out. Items fell silently through the gaps.

The third was that any cross-domain figure (a card expiry, a salary change, a new address) had to be written into every domain that referenced it. The first attempt to add an address-change confirmation row produced three almost-identical entries in three different domain context files, with three slightly different timestamps.

The fix was an orchestrator-and-primitive split, deployed 2026-04-29.

One orchestrator, daily-ingestion, runs once at 05:30 local. It loads the spine read-only at the start, opens the three mail accounts once, sweeps the three document sources once, and produces a single queue of unclassified items. It does not own any classification logic. It owns the sweep.

One primitive, ingest-triage, runs once per item. It classifies into one of the eight domains using a shared rulebook, updates the domain context file, writes back to the spine if a figure changed, writes a dated event to the calendar if one is implied, and appends one row to the ingestion log. It does not own the sweep. It owns the per-item write.

The two skills cache the four operating documents once per session and reuse the cache across every item.

The five per-domain monitor tasks were retired the same day.

The trade-off honest enough to put in print: the orchestrator is now a single point of failure. If daily-ingestion fails, no domain ingestion happens that day. That is the right trade against four redundant pipelines, because the failure is loud (the ingestion log shows no rows) and recoverable (the next run picks up the missing window). It is the wrong trade for any system where silent gaps matter more than redundant cost; this is not that system.

The second fix was subtraction

The April architecture assumed one thing without ever writing it down: that the daily surface of the system was Claude reading files. By late August that assumption had quietly inverted. The phone had won. On 26 August, Apple Notes and Reminders became the canonical stores, with the git vault demoted to archive and provenance and a nightly export keeping the exit honest. The domain structure survived the move intact, folders mirroring lists, the ontology still discovered from the stores rather than prescribed. A Raspberry Pi took over the one capability the ecosystem could not offer: a read-only mirror of the whole mailbox, fifteen years and fifty-seven thousand messages, searchable in about a millisecond from any Claude session with every computer in the house asleep.

Migration reopened the ingestion question, and honestly. The 05:30 sweep’s premise was that everything inbound deserved processing, and that premise was wrong: most of what arrives is noise, and a classifier that reads everything spends most of its judgement on things nobody chose to care about. The replacement principle inverted it. Nothing is processed unless I elect it. Flag an email, from any device, and it is chosen; spam never enters the system because spam is never chosen.

Then one evening of building the elected pipeline killed five transport designs in sequence, each by measurement rather than taste. The unattended Email trigger demands a filter that cannot say “any email”. Shortcuts’ flag filters return zero at runtime, silently, in every serialisation I could construct, and reading a property off a mail entity kills a run with no error at all. A Mac-side sweep of Mail’s own index worked end to end but chained the phone to the Mac being awake, which was the dependence the migration existed to remove. Writing reminders over CalDAV turned out to be impossible for everyone, not just me: upgraded iCloud Reminders left that protocol in 2019, and only frozen pre-upgrade lists remain visible to any third-party client. The final design, the Pi writing elected mail into a dedicated iCloud calendar, proved its server half live within the hour, then died at the Mac’s door on a single Calendars permission that a headless runner can neither display nor register. Every run parked forever on a consent sheet that did not exist.

Behind all five corpses sat a decision I had already made: processing is attended. Nothing files itself; I confirm everything. And if a person is present at the moment of processing anyway, the platform now ships an attended agent in the right-click menu of Mail itself. So the fix was not a sixth transport. It was subtraction. Routine capture went to Siri, engaged directly. The flag itself is the queue, and it needs no machinery at all: it syncs server-side on its own, the Flagged smart mailbox shows it on every device, and its badge is the nudge. Claude keeps the work that needs reasoning, reading and writing the same stores, with a weekly pass whose briefing now ends by recording what Siri misfiled or refused that week. The same evening the sweep timer was disabled, the queue calendar deleted, six shortcuts released and two launch agents removed. Twelve architecture decision records and a register of platform landmines make sure none of that ground gets retrod by enthusiasm.

The trade-off honest enough to put in print, again: filing consistency now rests on an on-device model and how I phrase a request, rather than on a deterministic rulebook that measured well. That is the right trade here because election already made the volume small, the record of every decision lands in the stores either way, and the weekly pass audits the misses on evidence. It would be the wrong trade for a system where capture volume is high and attention is the bottleneck; this is no longer that system, by design.

Open work

The Siri-direct contract is on trial until mid-September. The weekly review, now in its third revision, ends every briefing with a telemetry section recording what Siri misfiled, misdated or refused, and the verdict, keep it, tune it, or resume the pipeline, gets made on those notes rather than on impressions.

The scanned-document lane is the next candidate for the election pattern: a watched folder as the flag, the same attended confirmation as the gate. It gets built only if the paper volume earns it, which is the test every piece of machinery now has to pass.

And one eye stays on Siri itself. If user-definable routines arrive over App Intents, the elected design maps straight onto them, and the landmine register records exactly which of today’s walls each new capability would have to remove before it deserves another attempt.

LifeOS exists because I am not a tidy person by default. The reason it works is that I treat a mess I produced as a system to model rather than a chore to grind. The same shape applies to the work I take on at scale: a small ambient spine, lazy-loaded depth, a single ingestion path, an honest audit trail, a documented trade-off whenever the obvious approach turns out to be the slower one, and the discipline to delete the machinery once the platform will do the same job with none.