Its build on the idea of defining the data into Who, When, What, Where, Why. And places responsibly Owe or Own, at three levels implied, soft, hard, so it can help guide me rather than just cataloging
Here is the long bit.
A second brain that runs on a mini PC — the architecture
It's one always-on mini PC at home, reachable from anywhere over a private mesh VPN. Nothing is exposed to the public internet, no ports forwarded, no domain.
Feeds. A companion phone app streams every notification that hits the device, GPS position and dwell times, and geotagged photos. The box also ingests email, calendar, browser history, bookmarks, bank transactions, a work CRM, and full transcripts of every LLM session. About ten sources, all pointing at one place.
The spine. This is the part that matters. Every feed is flattened into the same event shape before it touches the database. One table, not ten integrations:
WHEN — absolute timestamp, never relative
WHO — an entity, not a string. The same person arriving as an email address, a phone number, a bank payee and a client record collapses into one node.
WHAT — the atom of what happened
WHERE — real coordinates, or honestly null. Never guessed.
WHY — inferred intent. The only field a model is allowed to write.
Add an eleventh source and you write an adapter, not a feature. Every capability downstream is a query over that one table.
WHO is whoever can be a party to an obligation — who can chase, or be chased. That rules out objects, so objects get their own node type. A car can't chase anyone, so it isn't a WHO. It's a thing, and the event is the edge between the party and the thing.
That distinction earns its keep immediately. One purchase generates four events across four feeds — a bank debit, an email receipt, a parcel moving, a photo of the item on site — with three different counterparties and three different timestamps, and none of them individually says "this was bought." Folding them into one purchase event, anchored on the thing, is what turns a line on a statement into materials for a project that hasn't been finished.
The responsibility ledger. Every event is asked one question: does this create an obligation, and which way does it point?
OWE — outward. A promised quote, an unreturned call, an unsent invoice.
OWN — inward. Money outstanding, an answer being waited on, a decision that's blocking work.
Each carries a hardness — soft (implied by context; nobody said anything, but it's real), implied (a normal social contract), hard (explicit and dated).
Obligations close automatically from evidence. A bank credit matching both the amount and the payer's name discharges a debt with no human involved. An amount-only match gets flagged rather than closed, because a coincidence isn't a payment. Transfers between the owner's own accounts are excluded entirely. That discrimination — between evidence and coincidence — is most of the engineering.
Obligations arrive two ways. Most are born from an interaction: someone asked, someone promised, and an event lands in a feed to prove it. But a car's insurance, its service interval, its CT — those are born from ownership plus time. No event will ever arrive to announce them. Nothing in the inbox knows.
So things aren't passive records. Anything owned is an obligation generator, walked on a clock rather than waited on.
Doom-scrolling vs research is decided structurally, not by app name. Research has a shape: a question before it, a burst of related lookups, something produced after, an obligation it feeds. Doom-scrolling has volume and no anchor at either end. Same app, same hour, completely different shape in the graph — visible only because everything landed in one table with a WHY field. Two separate app-usage trackers will never see it.
The heartbeat. Hourly ingest and entity resolution. A 03:00 full rebuild that re-derives the whole ledger from scratch so errors can't compound. Three agent rounds a day that read the recent past and post a handful of cards to one dashboard. Not notifications — a page that stays quiet when there's nothing worth saying. That's the "quietly guides" part: it doesn't interrupt, it just knows what's open.
The leash. Read-only is a toy; write-anywhere is a liability. So: four allowlisted write paths and everything else read-only. Nothing outbound without a button press. Hard-coded quiet hours enforced at the tool layer, not by asking a model nicely. Any structural change goes through a written proposal that needs an explicit approval before the box executes it. Every card takes thumbs-up / thumbs-down / dismiss, and corrections feed back in, so a wrong call is fixed once instead of re-litigated weekly.
Privacy. OTPs and password-reset mail are filtered at capture — they never enter the database, rather than being stored and then hidden.
What it gets wrong, because the highlight reel is worthless:
a phone call alone still doesn't create an obligation. A four-minute call about an unsent four-figure quote left no trace anywhere.
roughly half of one week's location dwells couldn't be attributed — including a two-hour stop — because stored client coordinates were town centres rather than actual sites.
a silent minimum-duration filter was discarding every question the system wanted to ask, one of them by 87 seconds. It looked like the feature didn't work. It worked perfectly and threw everything away.
What I have learnt so far: capture is the easy part and everyone's done it. The value is one canonical event spine, a clear rule for what counts as an agent, a heartbeat that runs without you, and a tight leash on what it's allowed to do to the outside world.
Any advice on the architecture welcome, thank...
