Sedona

Problem

Assistant apps ask permission for everything and remember nothing. I wanted the opposite: a system that owns my schedule as its own data, acts on it without being babysat, and can be trusted to do that because the safety model is engineered, not promised.

That last part is the real problem. Letting an AI system operate on your actual life, every day, is a trust question, and trust questions have engineering answers.

What I built

A personal assistant running on a VPS with exactly one user: me. It holds the schedule as first-class data rather than syncing someone else’s calendar, names every hour from wake to sleep, and runs the day on a job schedule: a research brief and a morning brief pushed to my phone, block-by-block notifications through the day, a re-plan of the remaining day at 16:00, and a 21:00 plan for tomorrow that first runs drift analysis over the prior seven days to see how plans and reality have been diverging. Nightly encrypted backups and a weekly full test run round out twelve scheduled jobs on three always-on services.

Four ways in and out: a button on my phone for inbound requests, a private web app reachable only over my own network, push notifications outbound, and a read-only calendar feed. The stack is deliberately boring: no framework, no database, no build step. The git repository is the datastore, and the nightly push is the off-site copy.

How it works

The design principle: act and log, don’t ask and wait. The system does its job and records everything; undo is the safety mechanism, not a permission prompt. That only works because of what sits underneath it:

Every mutation is guarded. All writes pass through a single mutex and land in a change log. Nothing edits state silently, and anything can be walked back.

Sensitive domains are read-only by rule. Financial data is readable, never writable, permanently. Not a setting. A design law.

The system proves itself before and after every change. A regression suite of 23 sections and 451 assertions runs before a build session starts and again before that session reports its work. If the suite is not green, the session has no standing to claim success.

Even the design rules are held accountable. At one point two locked design laws turned out to be mathematically unsatisfiable together on a real phone screen. The resolution was a written amendment to the design document, not a quiet violation. A system you trust is one whose rules are either followed or formally changed, never fudged.

Results and impact

Sedona runs my actual days. The briefs arrive, the blocks fire, the evening plan lands after the drift analysis has had its say. It has become the operational backbone the rest of my projects plug into.

For anyone evaluating what I build professionally, this is the deepest answer: infrastructure, not scripts. Scheduled, guarded, tested, and measured. The same discipline shown in my client-facing SEO systems, applied to the highest-stakes user I have: myself. Instrument the system, then let the numbers decide.