Personal Operating System v1
What ten weeks of arguing for autonomy, recovery, friction and local-first actually produces
My life improved when I stopped optimizing for convenience and started optimizing for recovery.
That’s the confessional version. The operational version: I stopped asking “what’s the easiest tool for this?” and started asking “what happens when this breaks, and what do I need to undo it?”
Those two questions produce different stacks. Different rituals. Different refusals. Ten weeks of writing this arc from different angles brought me back to the same answer each time. Autonomy, recovery, friction and local-first aren’t four separate arguments. They’re one argument, stated four ways. What follows is what that looks like assembled into something you can actually copy: the stack I run, the rituals that make it real and the refusals I’ve stopped negotiating around.
THE ARGUMENT, COMPRESSED
Recovery-First Automation started with the irreversible click. The automation you can’t take back. The principle it produced: design for undo before you design for speed. If you can’t undo it, you must slow it down. That’s not a philosophical position. It’s a spec requirement.
Friction Is a Vulnerability added the corollary: friction doesn’t block unsafe workarounds. It reroutes toward them. When a process requires a workaround to complete, the workaround is your real policy. You’re not describing a tool failing. You’re describing a gap between the official workflow and the one people actually run.
Local-First Is Reliability Engineering and The Local Logbook made the same point from two angles: you cannot rely on evidence you can’t produce without asking someone else’s permission. Your tools should work when the network doesn’t. Your logs should be readable when your vendor is degraded.
The Shadow Automation Layer closed the loop. Shadow automation exists because the official path was too slow. The response isn’t to ban the tools. It’s to govern blast radius and require a write receipt before anything runs unsupervised.
These aren’t ten arguments. They’re one. And it doesn’t resolve cleanly; it compounds.
THE STACK
What I actually run:
Notes and working documents: Notion on local Markdown files, synced via Dropbox as a delivery mechanism but not a dependency. If Dropbox is down, I open the file directly. My editor is my application. Nothing authoritative lives only in the browser.
Structured logs: SQLite. One database per project, one append-only log table. Daily rotation, 30-day local retention, cold storage after that. Before any action that changes system state, I write the action locally. The remote API call happens after the local write, not before. If the remote call fails, I still have the record of the attempt. Receipts Everywhere defined what makes a receipt worth trusting: it’s hard to modify without detection and producible on demand without asking anyone’s permission. That definition shapes the log format.
Automation: Nothing ships without three questions answered at build time: what is this allowed to touch, how many records can it change in a single run, and where does it write its log. The third question is a hard gate. An automation without a local write receipt doesn’t run.
Coordination: No Control Plane established the design rule for anything running across multiple systems: no single coordinator that becomes a bottleneck and a single point of failure. The same rule applies to personal workflows. I don’t have a master system that everything else reports to. I have a logbook and a set of independent tools that each write locally and sync when connectivity is available.
Alerts: One path in, one path to disable. The Operator’s Cognitive Budget established that cognitive overhead is a finite resource and alert stacks steal it steadily. I audit the alert stack every quarter and remove one. The goal isn’t fewer alerts in theory. It’s fewer interruptions that resolve to nothing.
This stack isn’t elegant. It’s deliberate. The design constraint isn’t “easiest to add.” It’s “what breaks first, and what does that cost me when it does?”
THE RITUALS
Three practices that keep this concrete instead of theoretical.
The morning scan. Before opening any SaaS dashboard, I read yesterday’s local log. Three minutes. I’m looking for anything that ran overnight and left an unexpected state. Not a deep audit. A check. The habit compounds: after several months of reading the record daily, anomalies are visible before they become incidents. The pattern is familiar. The outlier stands out. Running Gemma locally in Ollama helps me streamline this.
The pre-build checklist. Before writing any automation, I answer three questions in writing: scope, rate limit and log destination. Not because checklists are magic. Because writing them forces specificity. “It’ll summarize the reports” isn’t a scope. “Reads from /reports, writes to /summaries, touches no other directories, processes a maximum of 50 files per run” is a scope. The distance between those two descriptions is the blast radius. Getting specific up front is cheaper than the postmortem.
The quarterly dependency audit. I list every tool I rely on and ask one question: if this were unavailable for 72 hours starting now, what stops? Tools I can’t answer that question for get replaced or backed up before I need them. I’m not trying to eliminate cloud dependencies. I’m trying to know exactly which ones I’ve accepted and what each failure looks like in practice. Most dependencies are fine. Unknown dependencies are the ones that become incidents.
None of these are clever. That’s the point. Operational habits don’t need to be clever. They need to run without requiring a decision each time.
THE REFUSALS
These are operating constraints, not aspirations.
I won’t build automation without an undo path. If the action can’t be reversed, the automation has to include a checkpoint: a preview step, a confirmation prompt or a maximum-records cap before it runs. Recovery-First Automation named this directly. If you can’t undo it, you must slow it down. That’s a line item in every automation spec I write.
I won’t accept “we’ll follow up once the vendor restores access” as an incident close. That sentence means the evidence lives somewhere I can’t reach when I need it most. If an incident review ends there, the first entry in the next log is the remediation plan.
I won’t store authoritative state only in a system I don’t control. Cloud sync is useful; cloud as the only copy is a dependency I no longer accept without a documented fallback. The failure modes aren’t exotic. Local-First Is Reliability Engineering named the shapes: account lockout, service degradation, provider discontinuation. Each is a different version of the same problem.
I won’t route around friction silently. When I notice I’m working around something, I name it. The workaround either gets fixed or gets documented as an intentional policy. No silent exceptions. Friction Is a Vulnerability was clear: unmapped workarounds are the actual policy. Map them or fix them.
Privacy Is a Luxury Good called out that the ability to be unreachable is now a status signal. I’ve applied that argument operationally. Producing your own records, running your own toolchain, undoing your own mistakes: these are forms of independence that compound. They require refusing certain dependencies before the failure arrives, not after.
The past ten weeks made one argument ten ways. Reliability isn’t built in the incident. It’s built in the choices you make before anything is failing yet: the tool you back up before it locks you out, the automation you slow down before it runs unchecked, the log you write locally before you need it in a review where the vendor’s system is yellow.
None of this has to be copied wholesale. Take what fits your failure modes. Leave the rest. But find the refusal that would have prevented your last real incident and make it non-negotiable.
Pick one guardrail you will never violate again.
Resources
Recovery-First Automation: Undo Is the Feature: Arc Week 3. The case for designing undo before speed. Every automation spec in this piece runs from that principle.
Friction Is a Vulnerability: Arc Week 5. Friction doesn’t block workarounds; it reroutes toward them. The refusals section is an application of this argument.
Local-First Is Reliability Engineering: Arc Week 7. The engineering case for keeping authoritative state on your own device. Not ideology; failure-mode design.
The Local Logbook: Evidence That Doesn’t Need Permission: Arc Week 8. Append-only, locally controlled records as the prerequisite for any claim about what happened.
The Shadow Automation Layer: Arc Week 9. Govern outcomes and blast radius, not tools. The three-question pre-build checklist originates here.
Receipts Everywhere: Trust Without Central Trust: Arc Week 2. The receipt model that shapes the SQLite log format described in this piece.
No Control Plane: The Playbook: Arc Week 1. The coordination design rule: no single point of failure, no single coordinator. Applies to toolchains and workflows as much as distributed systems.
The Operator’s Cognitive Budget: Arc Week 4. Attention is finite; alert stacks steal it steadily. The quarterly alert audit is a direct application.
Privacy Is a Luxury Good: Arc Week 6. The observation that independence is now a status signal; the refusals section is its operational translation.