From the context an LLM is missing, to the data boundary behind Kioku.
The AI Doesn't Know Me
Kioku didn't start out as a project about "recording a life." I didn't read the history of lifelogging first and then pick one of its designs to build. Its origin was far more ordinary: I use LLMs every day, and none of them know who I am.
A model can help me write code, analyze an architecture, rework my résumé — and once it has tools, carry out real work on my behalf. But every time I open a new provider, I have to explain myself from scratch: which languages I use, what I do for a living, which projects I run, how I like code organized, which technical constraints can't be waved away.
Providers usually offer somewhere to put this, something like things about me. I can write it all in, and the problem looks solved. But once I started maintaining it seriously, I realized I was only building one more copy of the data about me.
My personal site already stores my work history, skills, projects and bio. The app that tailors my résumé needs the same data, so it imports another copy. The LLM provider keeps its own profile, and whatever I build next will ask for a profile of its own.
These systems aren't holding different data. They're holding different projections of the same person. The problem is that each projection gradually starts acting like the source.
Every Copy of Me Drifts
The moment data gets copied, drift follows.
I update a piece of work history — do I edit the personal site first, the résumé app, or the LLM profile? A project changes its stack; which system holds the correct version now? And when a preference the provider memorized goes stale, I may not even know an old fact is still shaping its answers.
At first I read this as a context problem. Maybe I needed a better system prompt, or a JSON file I could import into different models. Later I understood that this was just another way of copying.
Context is the shape data takes when some consumer uses it — it is not the data itself. A prompt, a RAG document, a résumé page and a site API can all be ways of consuming it, but none of them should own a separate source of truth.
It turned into a very familiar engineering problem: I was violating SSOT.
If They're All Clients, Where Should the Data Live?
Once the personal site, the LLM and the résumé app are all seen as clients, the shape of Kioku appears on its own.
The data about me has to exist independently of any one client. The personal site shouldn't own my career data; it only publishes part of it. The résumé app shouldn't import a copy and take custody of it forever; it should read an authorized version when it needs one. And an LLM certainly shouldn't be the source of truth — it can only read the context that fits the task in front of it.
In Kioku, PostgreSQL is the single source of truth. Kioku owns the schema, the migrations, the permissions and the API. The personal site reads publishable content through the public API, the admin console does the writing, and LLM clients retrieve knowledge and structured life data over MCP.
None of this abolishes duplication. Caches, search indexes, vectors and prompts still produce derived copies. The difference is that those copies now know they are copies: they can be rebuilt from the source, and they have no standing to redefine the facts.
What Actually Changed Is the Data Boundary
What I eventually realized is that the most important design decision in Kioku wasn't choosing PostgreSQL, and it wasn't adding MCP. What changed was the database boundary.
Large platforms today usually organize data like this:
one domain × many people
A health platform collects health data from many people, a music platform collects listening history from many people, a hiring platform collects careers from many people. Their domain boundaries are perfectly clear, but one person's data is sliced vertically and left inside separate companies.
Kioku rotates that ninety degrees:
one person × many domains
Career, knowledge, photos, music, health, travel and browsing history belong to a single person's data space. They may arrive from different products, but the product shouldn't remain the final boundary forever.
That doesn't mean stuffing everything into one universal table. Internally, Kioku still keeps domain semantics in schemas like career, content, media, health and life. Different data also carries different read rules: the site can publicly read posts and projects, while health and life data have no public view at all.
So this is how I'd describe it now:
the outer boundary follows the person; the inner boundaries follow the domains.
It Turns Out People Have Walked This Road
Only once I started reading did I find out that "a database for one person" is not a new idea.
Vannevar Bush proposed the Memex in 1945, imagining an external memory that could store and link a person's own material. In 2001, Gordon Bell, Jim Gemmell and Roger Lueder started MyLifeBits↗︎ at Microsoft Research: a SQL-based "personal database for everything." It held documents, mail, photos, web pages, recordings and sensor-captured life logs, and explored full-text search, annotation, linking and similarity.
Later, Personal Data Stores and Solid approached the same tension from another direction: data shouldn't be bound inside applications; applications should access storage the person chooses, once authorized. As of 2026, the W3C is still pushing Linked Web Storage↗︎ forward, trying to standardize secure, authorized application access to external storage.
There is also a more pragmatic engineering line. HPI↗︎ doesn't wait for the whole internet to agree on one protocol first; it uses export files and adapters to turn chat, music, browsing, location and health data into interfaces a personal program can query.
These projects aren't one continuous, unified product lineage, but they keep answering the same question: when a person's digital life spans many applications, can the data be reorganized around that person?
Why It Never Became the Internet's Default Architecture
The idea keeps reappearing, and it keeps stopping at research projects, open-source tools and a handful of self-hosting users. The obstacle was never disk space.
First, platforms have little incentive to hand over continuous, complete, machine-readable data. Even where an export exists, what you get is often a one-off archive rather than a stable incremental interface. Being able to retrieve your data doesn't mean you can reliably sync it.
Second, data from different sources is hard to unify automatically. The same place, contact or activity may share no identifier across systems; timestamps carry different timezone assumptions; two devices may record the same workout twice. Putting the files in one directory is easy. Making them one database in any semantic sense is much harder.
Third, centralization widens the blast radius. Scattered data is inconvenient to use, but aggregated health, location, career and browsing history becomes a concentrated loss the moment one authorization goes wrong. Personal data sovereignty can't only mean "everything is on my side" — it has to include least privilege, auditing, backups and recoverability.
Finally, an ordinary person shouldn't have to become a database administrator in order to own their own data. For a developer like me, one PostgreSQL per person is acceptable. If this model is going to serve more people, the realistic shape is a hosted pod, an encrypted personal space or a logically isolated data account — not a server everyone has to maintain.
AI Makes This Path Useful Again
For most of its history, a cross-domain personal database lacked a strong enough everyday consumer. Charting your health or searching old messages is useful, but not necessarily enough to make an entire ecosystem move its data boundaries.
Personal AI may be the first consumer that naturally needs all of it. An agent that helps me plan work, rework a résumé, review a project or make sense of how I've been living can't know only one domain. It has to reach across career, knowledge, preferences and history — while each task gets only the slice that task requires.
The external conditions are shifting too. The EU Data Act↗︎ already pushes connected products to give users the data they generate along with the metadata needed to interpret it, and the DMA is pushing large platforms toward timelier portability interfaces. Those rules won't create a personal database on their own, but they are turning "getting my data back" from a reverse-engineering exercise into a capability you can actually demand.
Still, AI only makes the demand stronger. It hasn't solved data governance for us.
An LLM cannot be the SSOT. A vector index doesn't preserve exact quantities, and a relationship the model infers is not a fact. An agent may suggest that two records could be related, but it shouldn't rewrite my work history because of one generation. Natural language makes data easier to use; provenance, permission and certainty still have to be expressed explicitly by the system.
Kioku Doesn't Try to Record Everything
Later MyLifeBits explored passive capture as complete as it could get. Today there are tools that record your screen continuously, log every keystroke and save every digital activity. Kioku deliberately doesn't treat completeness as the goal.
What I care about is which data deserves to be retrieved reliably in the future: the projects I've built, the knowledge I've written down, the photos I've taken, the music I've listened to, the places I've been, and health records that can still be interpreted correctly. Selectivity isn't a missing feature; it's part of the data model. Data with no clear purpose, provenance or retention reason doesn't earn permanent storage just because it "might be useful someday."
Publishing isn't a default outcome either. A personal site and a personal database can share one source, but their read surfaces have to differ. In Kioku, visibility isn't a WHERE clause every caller has to remember to add — it's a boundary drawn by database roles and views together.
That's also why I think of Kioku as personal data infrastructure rather than a lifelogging app. Recording is just one way into the system; what matters more is the structure the data exists in, how it is validated, who is allowed to read it, and whether it still belongs to me after the tools on top are replaced.
My Data Finally Has a Home
Kioku is still a system built for one person. It can't force every platform to expose a live interface, and it hasn't removed the cost of maintaining importers and data models. Turning it into a product for everyone would still mean solving hosting, key management, the authorization experience and standard interoperability.
But for me, the boundary that matters most is finally clear.
The next time I switch LLM providers, I won't have to migrate a version of "me" that the provider defined. When I rebuild my personal site, I won't have to reinvent the data model for careers, projects and photos. And if a new product needs my data, it should become one more authorized client — not a new source of truth.
Kioku isn't about helping AI remember more.
It's about giving the data about me, for the first time, the right place to belong.