The Architected Self 01
Why Personal Data Architecture Matters
*#architected_self, Post 1 of 10*
---
The Accumulation Problem
Over the course of a professional life — in my case, five decades spanning naval service, cybersecurity engineering, and legal practice — the volume of digital artifacts one accumulates is not merely large. It is structurally incoherent. Contracts, orders, medical records, financial statements, research notes, correspondence, audio recordings, scanned documents, software artifacts: each arrives through a different channel, in a different format, with a different urgency, and lands somewhere on a storage medium that was designed to hold files, not to understand them.
The problem is not storage. Storage is cheap, reliable, and effectively unlimited for any individual’s lifetime of records. The problem is architecture: the absence of any principled structure governing how information is organized, related, and retrieved. Without architecture, accumulation becomes accretion — the geological layering of undifferentiated sediment that preserves everything and illuminates nothing.
For most of my professional life, I managed this problem the way most professionals do: with folders. Folders nested inside folders, arranged by intuition and circumstance, named according to the conventions of the moment and quietly abandoned when those conventions shifted. The result was a file system, and archives of files systems from previous computers, that was technically searchable but epistemically opaque — one that could tell me where a file was stored but could not tell me what it meant, how it related to other records, or whether I had captured everything relevant to a given question.
When Hierarchy Fails
The folder is not a bad tool. It is an insufficient one. A folder provides location but not relationship. It answers the question “where is this?” but not “what is this connected to?” or “what type of thing is this?” or “when did this matter?” A well-named folder is a label on a box; it tells you what the box contains but nothing about the box’s relationship to the other boxes around it, or to the house in which the boxes are stacked.
The failure mode of a folder hierarchy is predictable. Initially, the structure feels coherent. Documents go where they belong. Subfolders multiply reasonably. The system is manageable. But folder hierarchies are, by their nature, exclusive and positional: a document can only be in one place. When a document belongs to multiple categories — a medical invoice that is simultaneously a financial record, a provider interaction, and evidence of a specific date-bound event — the folder system forces a choice that is, at some level, false. You put the document somewhere and accept that retrieval will depend on remembering which false choice you made.
Over time, the hierarchy calcifies. Conventions established under earlier circumstances resist revision. New categories are wedged into old structures. The top-level folders that made sense in 2015 persist in 2025 as a kind of archaeological stratigraphy, each layer reflecting a different period’s assumptions. Search becomes the practical substitute for structure — you stop navigating and start guessing keywords, hoping the document was named what you think it was named and that the search engine surfaces it.
This is not a failure of discipline. It is a failure of model. The folder hierarchy is the wrong data structure for the problem.
The Stakes
Why does this matter? For some professionals, the consequences are modest: a misplaced receipt, a lost draft, a citation that takes twenty minutes to locate. But for those whose records carry legal, financial, or clinical weight, the stakes of structural failure are more serious.
As an attorney, I understand that records have evidentiary value — and that evidentiary value depends not just on content but on provenance, completeness, and context. A record that cannot be located is, for practical purposes, a record that does not exist. A record that exists but cannot be contextually situated — that cannot be related to the actors, transactions, and events it documents — is a record whose meaning must be reconstructed from scratch each time it is consulted. The cost of that reconstruction compounds silently over years.
As someone who has managed the financial, legal, medical, and operational affairs of a household with the complexity of a small enterprise, I have found that the difference between a record system and an information architecture is the difference between a system that preserves *cognitive sovereignty* — the owner’s sustained capacity to locate, understand, and act on their own information without intermediary — and one that its owner must continuously serve: feeding it, maintaining it, coaxing it to yield what it contains.
The computational dimension adds a further stake. Large language models have become genuine research and synthesis partners — but they are only as useful as the context they receive. A model fed a folder listing or a pile of scanned documents will produce output that reflects the poverty of that input. A model given structured, architectural context — a system that encodes not just what exists but how elements relate, what roles they serve, and why they were created — produces qualitatively different work. The investment in personal data architecture pays dividends not only in human retrieval but in machine comprehension. I will return to this point at length later in the series; for now it is sufficient to note that the audience for a well-designed personal information system is no longer only human.
felixOrg as Living Laboratory
The system I call felixOrg began not as a designed architecture but as an attempt to impose order on accumulation that had grown unmanageable. Over time, through cycles of failure and revision, it evolved into something more deliberate: a personal information enterprise with a defined taxonomy, a *dispositive database* (a database whose record governs — the term is borrowed from legal drafting, where a dispositive clause is one that creates or extinguishes rights rather than merely describing them), a structural architecture model, and two AI agents operating against that model in defined roles.
The primary data store is DEVONthink Pro, a macOS application that combines a document database with powerful full-text search, flexible tagging, and a replication feature that allows documents to appear in multiple organizational contexts without duplication. The structural model is maintained in ArchiMate using the open-source Archi tool — a modeling language originally developed for enterprise architecture that maps with surprising fidelity onto personal information systems. Two AI agents operate within this architecture. Plato — running on Google’s Gemini — serves as strategic architect, operating against the full model and providing research, synthesis, and structural analysis. Cato — running on Claude Code — serves as tactical implementer, executing against specific model nodes and managing the operational mechanics of system maintenance.
This is not an AI-augmented system in the superficial sense of using a chat interface to draft emails. It is an architecture in which the AI agents have defined roles, defined scope, and a shared structural context they can read and reason about. The distinction matters, and I will examine it directly in a later post.
felixOrg is the living example that threads through this entire series. I will use it to illustrate each principle — not because my implementation is the only valid one, but because abstraction without instance is advocacy dressed as analysis. The system has specific decisions embedded in it, and those decisions are worth examining, including the ones that turned out to be wrong.
What This Series Does
This series does not argue that everyone should build what I have built. That would miss the point. The argument is narrower and more durable: that deliberate information architecture — whatever its specific form — preserves cognitive sovereignty and produces compounding returns over the lifetime of a professional practice, and that the alternative is not neutrality but progressive degradation.
Each post examines one layer of that architecture: the taxonomy governing classification, the database that stores and retrieves, the structural model encoding relationships and context, and the way that architecture now enables qualitatively better engagement with AI systems. By the end, I hope to have provided not a blueprint but a vocabulary — a set of concepts and distinctions that any technically literate practitioner can apply to their own information environment, regardless of the specific tools they use.
The first and most fundamental of those distinctions is the one between *types* of data — because before any database can be configured, before any tag can be applied, before any model element can be created, one must understand what kind of thing one is looking at.
*The next post examines the three fundamental categories of personal data — temporal, structural, and knowledge items — and explains why this ontological distinction is the necessary first step before any tooling decision is made.*