```

zarkov 2989/tcp # ZARKOV Intelligent Agent Communication

```

In the early 1990s the Internet still had a phone book, and you could get a listing by asking politely. Programs found each other by port number then: mail lived at 25, the web — a promising newcomer — at 80, and if you were building something new, you wrote to the Internet Assigned Numbers Authority, described your protocol, and received a number of your own. No fee. No renewal. No lawyers. I asked, and I received port 2989, TCP *and* UDP, because I was thorough, for something I called ZARKOV Intelligent Agent Communication — named in honor of Dr. Zarkov of *Flash Gordon*, a scientist whose response to a planetary emergency was to build a rocket in his backyard and kidnap the nearest available polo player. He seemed the right patron saint for autonomous software.

Intelligent software agents were the coming thing then — autonomous programs that would roam the network on your behalf, fetching, negotiating, conferring with other agents in a busy machine society. The research literature was certain of it. I reserved them a room.

They never checked in. What arrived instead was the web, and then the web ate everything else. Today essentially all traffic shows up dressed as web traffic, encrypted, on port 443 — the digital equivalent of a city where every business, church, and government office operates out of the same shopping mall. Identifying a program by its port number now works about as well as identifying a caller by their area code: a habit from a world where numbers meant places.

The world is full of these orphaned registrations. The fax number still printed on the letterhead. The vanity plate outliving the car. The certificate declaring that a star — visible only from the southern hemisphere, in winter, with equipment you do not own — is named for your anniversary. Institutions maintain ledgers far longer than the world maintains the reasons for them. So my line rides along in `/etc/services`, shipped free with every operating system, a one-line homestead deed on land nobody farms.

Full disclosure: last year I stopped waiting and moved in myself. My document database — five decades of contracts, orders, research, and sheet music — runs on a small server on my desk, and I assigned it port 2989 deliberately, on the theory that if nobody was going to build on my land, I could at least park on it. The registration had become a vanity plate after all. I mounted it, fittingly, on the family car.

Then, this week, the punchline arrived thirty years late. While untangling a sync problem, my AI assistant — an actual intelligent agent, the genuine article — probed the machine, found something answering on 2989, and read my name off the ledger. It paused, in the way that software pauses. There it was: an intelligent agent, communicating, on the port reserved decades ago for Intelligent Agent Communication. The room I had furnished for the future finally received its guest.

I take two lessons. First, the future is slow, but it does eventually check the ledger. Second: register things. Politely, in writing, with your name spelled correctly. Most reservations expire worthless — but institutions are patient, storage is cheap, and every so often the address you zoned in 1993 turns out to be exactly where the future decides to live.

DEVONthink Forum: The Architected Self

Aeon Timeline Forum: Managing temporal data

---

The Framework Beyond felixOrg

The nine preceding posts have examined a specific system built by a specific person to manage a specific body of information. The architecture of felixOrg reflects choices made under particular constraints — a Mac-centric toolchain, a professional background spanning naval service, law, and cybersecurity engineering, a preference for local-first data sovereignty, and a decade of iterative refinement. None of those specifics is the point.

The point is the underlying framework: that information can be classified by fundamental nature before any tool is selected; that the resulting taxonomy can be operationalized into a principled ingestion pipeline; that a document repository and a structural model serve complementary functions that neither can perform alone; and that a continuously maintained architecture model enables a qualitatively different kind of engagement with AI systems than any collection of documents can provide.

These principles do not belong to felixOrg. They belong to anyone who accumulates information in a professional context — which is to say, they are portable. The remainder of this post tests that portability against two domains: a bounded research project and a small organizational dataset. It then introduces the one concept the framework has not yet named explicitly — the data lake — and closes with the synthesis that ten posts of argument have been building toward.

A Bounded Research Domain

Consider a practitioner building a complex legal case. The information environment is immediately recognizable: temporal items (filings dated to specific court deadlines, orders entered on specific dates, depositions taken on specific days, communications exchanged at specific times), structural items (parties, counsel, courts, judges, expert witnesses, organizations — entities that persist across the life of the case), and knowledge items (case law research, legal memoranda, strategic analysis, synthesized interpretations of disputed facts). The three-part taxonomy applies without modification. The items themselves differ; their fundamental natures do not.

The operational buckets follow naturally. `::temporal_bucket` receives dated filings, orders, and correspondence in chronological order — the evidentiary record that builds with each court event. `::actor_bucket` organizes the parties, their counsel, and the expert witnesses. `::org_bucket` holds the courts, agencies, and institutions involved. `::facility_bucket` holds the courthouses, law offices, and other physical venues where proceedings occur. `::structural_bucket` holds the standing configurations: the procedural posture of the case, the exhibit list, the discovery index. The ingestion discipline — Name, DTG, 2-3 word Description — applies to every document entering the system.

The ArchiMate model maps the case architecture. The goal layer holds the legal theory of the case and the relief sought. The business layer models the parties and their procedural roles, the counsel and their responsibilities, the processes of discovery and motion practice. The application layer maps the document management tools, the research platforms, the court filing systems. The technology layer is whatever hardware the practice runs on. The relations between these layers — which processes depend on which data objects, which actors are assigned to which roles, which deadlines trigger which processes — are the structural facts about the case that no individual document captures but that every experienced litigator carries in their head. The model makes them explicit, auditable, and shareable with AI agents who can then reason about the case as a system rather than as a document collection.

The historian, the scientist, the policy researcher: the taxonomy shifts in its specific vocabulary — archives instead of filings, experiments instead of depositions, primary sources instead of discovery — but the underlying structure is the same. Temporal items record what happened; structural items model who and what was involved; knowledge items synthesize what it means. The framework generalizes because the problem generalizes.

Small Organizations

A team of ten, a nonprofit managing a program portfolio, a research group maintaining a longitudinal study: the organizational application of the framework differs from the personal application primarily in the number of actors and the complexity of the role assignments. The taxonomy does not change. The ArchiMate model simply has more elements in the business layer.

The significant difference at the organizational scale is governance: the ingestion discipline, the controlled vocabulary, and the model maintenance process must be documented explicitly so that multiple people can apply them consistently. In a personal system, the conventions live partly in the architect’s head and partly in documentation; the architect is both the rule-maker and the only practitioner. In an organizational system, the conventions must be externalized completely, and the model must reflect decisions made by multiple people with different roles and different perspectives on what the system contains.

This externalization requirement is actually a forcing function for better architecture. A convention that cannot be written down clearly enough for a new team member to follow was probably not clear enough to be applied consistently in the first place. The organizational context forces the precision that the personal context permits to remain tacit.

The AI collaboration dimension also gains at organizational scale. An ArchiMate model maintained by a small team and shared with an AI agent provides that agent with organizational situational awareness that no briefing document can match: who does what, which processes depend on which tools, which goals motivate which work packages, and how the team’s capabilities relate to its constraints. The context economy — the management of what AI agents know and when they know it — becomes a genuine operational consideration rather than a personal preference.

The Data Lake

Every honest taxonomy needs a residual category — a place for items that resist clean classification. In felixOrg, this is not a theoretical construct; it is a named group that sits alongside the five buckets in the DEVONthink repository: `_data_lake`.

The term is borrowed from enterprise data management, where it refers to a repository of raw, unstructured data stored in native format until its eventual use. In the context of a personal or organizational information architecture, it serves a more specific purpose: `_data_lake` is the temporary holding area for items whose classification is not yet clear, whose provenance is uncertain, or whose volume exceeds what the ingestion pipeline can process without creating a backlog that defeats the taxonomy’s purpose. Its existence as a formal, named group — rather than a conceptual category — is significant: the data lake is part of the architecture by design, not an admission of defeat.

The data lake is not a failure. It is the taxonomy’s acknowledgment of its own limits — and of time’s limits on the person maintaining it. A large inheritance of legacy documents from a previous system, a raw discovery production before privilege review, a batch of scanned materials whose dates and subjects have not yet been verified: these are data lake items. They exist; they need to be preserved; their classification is deferred, not abandoned.

The discipline the data lake requires is the discipline of non-permanence. Items in the data lake have an implicit time to live: they should be reviewed, classified, and migrated into the taxonomy on a regular cadence. The lake is a buffer, not a destination. A data lake that grows without bound is a taxonomy that is collapsing — items are going in and not coming out, and the residual category is slowly consuming the system it was meant to protect. The signal that a data lake has become a problem is when it begins to be used as a retrieval source rather than a staging area.

Managed correctly, the data lake makes the taxonomy more honest: it provides a place for genuine ambiguity without corrupting the categories that are not ambiguous. The taxonomy is precise because the lake absorbs what the taxonomy cannot yet classify.

What Compounds Over Time

Post 1 argued that deliberate information architecture produces compounding returns. After nine posts of examination, the compound can be stated precisely.

*Reduced cognitive overhead* is the most immediate return, and the one that takes longest to materialize. In the first year of applying the framework, the ingestion discipline costs more time than it saves: every document must be classified, named, and tagged before it enters the repository. By the third year, the repository is large enough that the alternative — searching through an undifferentiated accumulation — is measurably more expensive than the discipline that avoids it. By the tenth year, the classification has become habitual, the repository has become reliable, and the cost of not having the system is unimaginable to anyone who has operated within it.

*Durable institutional memory* is the return that accumulates invisibly until it is suddenly needed. The context behind a decision made in 2019 is preserved not just as a document but as a modeled relationship between the actors who made it, the goal it served, and the process that implemented it. When that decision is questioned in 2029, the answer is not a reconstruction from partial memory but a traversal of a maintained model. This is the return that personal and organizational information architects consistently undervalue until the moment they need it.

*Enhanced AI-driven synthesis* is the return that is newest and whose full value remains to be discovered. The structural context provided by a maintained ArchiMate model transforms AI agents from powerful text processors into genuine situational collaborators — systems that can reason about the architecture of a problem rather than merely about the documents that describe it. As AI systems become more capable, the quality of the context they are given will increasingly determine the quality of the work they produce. Architectural context is a durable investment in that quality.

*Cognitive sovereignty* is the return that makes all the others meaningful. The framework is local-first, format-open, owner-controlled, and vendor-independent. The data belongs to the person who created it. The model belongs to the person who built it. The discipline belongs to the person who developed it. Nothing about the system requires a subscription, an account, or a third party’s continued operation. That independence is not an ideological preference; it is the architectural precondition for every other return the framework delivers.

The Architectural Habit

The framework described in this series is less about the specific tools than about the habits of mind those tools support. DEVONthink and ArchiMate are the tools felixOrg uses; other tools could serve the same functions for practitioners with different toolchains and different constraints. What does not vary across toolchains is the prior question that must be answered before any tool is configured: what kind of thing is this, and what does its nature require of the system that holds it?

That question — asked consistently, answered honestly, and acted on with discipline — is the architectural habit. It converts information management from a reactive, tool-driven practice into a principled, durable system that serves its owner across the full arc of a professional life. The tools will change; the questions will not. The taxonomy will evolve; the commitment to having one will not. The model will be updated; the discipline of maintaining a current structural representation will not.

Thinking architecturally about information is, in the end, thinking carefully about what information is and what it is for. The folder was never equal to that question. The architecture is.

*#architected_self, Post 9 of 10*

---

The Act of Naming

There is a particular kind of knowledge that professionals accumulate over years of practice: knowledge that is real, reliable, and entirely tacit. You know how the system works; you have never had to say so. The dependencies, the redundancies, the fragile points — they live in a mental model that functions well enough for daily operation and that no one, including you, could fully articulate if asked.

Building an ArchiMate model is an exercise in making tacit knowledge explicit. Every element must be named, typed, and placed in a layer. Every relationship between elements must be drawn, and the relationship type must be assigned: is this serving, realizing, triggering, composing, or something else? The question is not rhetorical. You cannot draw a relationship between two elements without deciding what kind of relationship it is. If you cannot decide, the modeling tool does not do it for you. The ignorance is exposed.

This is where the mirror effect emerges. The model does not just document what you know about the system. It reveals what you thought you knew but had never examined, what you assumed without verifying, and what you had never thought about at all. The three examples that follow are drawn from the felixOrg model. They are not exceptional findings; they are the ordinary yield of modeling done honestly.

Redundancy: The eBook Problem

The application layer of the felixOrg model includes a Data Archive and Search Service, realized by two application functions: Data Archive and Search Functionality, provided by DEVONthink, and File Tree Indexing Functionality, provided by NeoFinder. Mapping these realizations was straightforward. What was not anticipated was what else the File Tree Indexing Functionality connects to.

NeoFinder’s indexing function also realizes the eBook Library Service — because NeoFinder indexes the full filesystem, including the directory where the Calibre ebook library stores its files. This relationship, once drawn, forced a question that had never been asked explicitly: what is the authoritative home for ebooks in the felixOrg system? The model revealed three answers simultaneously, none of which was wrong, but whose coexistence was neither designed nor examined:

Ebooks exist in the Calibre library, managed by Calibre’s own database with metadata, formats, and a dedicated reading workflow. Some of those same titles also exist as files in the DEVONthink database, imported for full-text search and annotation. And some exist only on the filesystem, outside both managed systems, visible to NeoFinder but not to Calibre or DEVONthink. Three locations, three management regimes, no explicit policy governing which titles belong where or why.

The model did not reveal that this was a catastrophic failure — it is not. It revealed that it was an unexamined condition. Some of the redundancy serves a real purpose: DEVONthink’s search capabilities make certain titles more accessible for research than Calibre’s reading interface; Calibre’s metadata management makes the collection more navigable for reading than DEVONthink does. These are legitimate functional differences that justify maintaining both systems for different use cases. The filesystem-only titles, however, represent neither: they are items that fell through the gaps rather than items placed there by decision.

The act of modeling did not create the redundancy. It made the redundancy legible — visible as a condition with a structure that could be evaluated, partially addressed, and consciously accepted where it serves a function.

Hidden Dependency: The Power Chain

The technology layer of the felixOrg model includes a detailed mapping of the home power infrastructure: from the external power grid, solar panels, and a Tesla PowerWall, through a controller solar panels, to the main electrical panel, from the panel through individual breakers to the office distribution network, and from there through power strips, outlet splitters, and individual power bricks to the devices they power. This is not a level of detail that enterprise architects typically bring to a personal infrastructure model. It became necessary when the model was used to audit the resilience of the server infrastructure.

The modeling process required tracing the power path to every significant device: to RFStudio, the primary workstation; to RFiMac, the remote Intel host; to RFMini, the media server; to the network infrastructure that connects them. Drawing those paths in the model revealed a fact that had been operationally true for years without ever being examined: multiple critical servers shared power paths through single breakers and single power strips. A fault on that breaker — or an accidental contact with a power strip’s switch — would simultaneously remove power from several pieces of server hardware, without warning and without a clean shutdown.

The model made this visible not because the information was new but because the diagram forced the paths to be traced end-to-end. A mental model of the home network and the server rack does not naturally include the power distribution infrastructure; it begins at the Ethernet port or the device itself. The ArchiMate model has no such natural starting point. It follows relationships wherever they lead, and power is as real a dependency as a network connection.

Several of these single-point vulnerabilities have since been corrected: circuits redistributed, power strips repositioned, critical servers moved to protected outlets. The infrastructure is more robust than it was, because the model forced an audit that intuition had not.

The Acknowledged Gap

The same power chain that revealed the correctable vulnerabilities also revealed one that is not cost-effective to correct. The Tesla PowerWall provides whole-house battery backup against grid outages — a genuine and substantial protection. Its transfer time, however, is not instantaneous. During the handover between grid power and battery power, there is a brief interruption that most devices tolerate without consequence. Sensitive server hardware — systems with spinning disks, systems running database transactions, systems that do not expect unclean power interruptions — may not tolerate it without consequence.

The architecturally correct solution would be an uninterruptible power supply for each affected server, providing a seamless, zero-transfer-time bridge between grid power and the PowerWall backup. The model identifies exactly which servers are affected, traces the dependency chain, and makes the gap unambiguous.

The gap has not been closed. The cost of dedicated UPS units for every affected server, and the maintenance burden of monitoring their batteries, exceeds what the risk of a PowerWall handover interruption justifies — particularly given that the PowerWall itself is a low-probability failure mode relative to the disruptions it prevents. The model’s value here is not that it produced a corrective action. It is that it produced a documented, examined decision: the gap is known, the risk is understood, and the choice not to address it is conscious rather than inadvertent.

This is a different kind of insight than the redundancy or the hidden dependency. It does not identify something that should be fixed; it identifies something that should be acknowledged. There is a structural gap in the resilience of the power infrastructure, and the architecture tolerates it on the basis of a cost-benefit judgment rather than ignorance. The model converts the gap from a blind spot into a managed risk. It does not close the gap, but it changes the nature of the architect’s relationship to it.

The Mirror Effect

What these three examples share is not their content but their epistemic character. In each case, the condition — the redundancy, the fragile power path, the UPS gap — existed before the model was built. The modeling process did not create the problem; it made the problem visible. And visible problems are different in kind from invisible ones: they can be named, described, evaluated, and either addressed or consciously accepted.

The mirror effect is the cumulative product of this visibility. A model built and refined over time produces a progressively more accurate and complete picture of the system it represents. Each modeling session is an opportunity to discover what the previous session did not examine. Elements that appear in one layer without corresponding elements in adjacent layers flag capabilities that exist without infrastructure, or infrastructure that serves no modeled capability. Relationships drawn under time pressure and not revisited reveal assumptions that subsequent experience has qualified. The model is never finished; it is always more complete than it was.

What the model reflects, ultimately, is not just the system. It reflects the decisions embedded in the system — decisions made under time pressure, under resource constraints, with incomplete information, or without thinking systematically about the implications. Some of those decisions look good in retrospect; others reveal their inadequacy only when the full dependency chain is drawn. The model is where those decisions become visible as decisions rather than as circumstances.

Self-Knowledge as a Byproduct of Architecture

I did not build the felixOrg ArchiMate model in order to know myself better. I built it to manage complexity, to provide context for AI agents, and to have a structural record of how the system works. The self-knowledge was incidental.

But incidental is not trivial. A practitioner who builds and maintains an honest architecture model of their own operational environment acquires, over time, a form of self-knowledge that is difficult to obtain by other means: a clear-eyed picture of where the system is well-designed, where it is held together by assumptions rather than structure, and where it tolerates risk because the alternative is too costly. These are not flattering revelations. They are useful ones.

The model does not judge the decisions it reveals. It simply makes them visible. The judgment is the architect’s responsibility. The mirror only reflects.

*The final post asks whether this framework — the taxonomy, the dispositive repository, the architectural model, the context economy — can be applied beyond personal records to bounded research domains and organizational datasets, and what it means to think architecturally about information at any scale.*

The Architected Self 10

The Context Problem

Every conversation with a large language model begins with a context window: the bounded body of text the model can attend to at once. The quality of what the model produces is, in large part, a function of what that context contains. This is not a limitation unique to any particular model; it is a structural feature governing how language models work. The model reasons about what it is given. If it is given impoverished context, it produces impoverished output — competently, fluently, and at length, but impoverished nonetheless.

The most common form of impoverished context is the document dump: a collection of files, emails, reports, or notes pasted into a chat session in the hope that the model will synthesize them into something useful. Document dumps are not without value. A model given ten medical records will produce a better summary than one given none. But a collection of documents is not a structured representation of a system. It is a pile of evidence without a map of the territory the evidence concerns. The model can identify patterns within the documents; it cannot identify the relationships among the entities the documents describe, because those relationships are not in the documents — they are in the architecture.

The gap between what document context provides and what structural context provides is the subject of this post.

What Structure Gives That Documents Cannot

The felixOrg ArchiMate model is exported as three CSV files: elements, relations, and properties. The elements file lists every significant entity in the model — actors, roles, processes, services, applications, data objects, devices, goals, requirements, assessments — with its type, name, and documentation. The relations file lists every typed, directed relationship between elements — serving, realizing, triggering, composing, assigning, influencing — with the source element, the target element, and the relationship type. The properties file provides additional attributes for each element: version numbers, URI references, status indicators, and descriptive metadata that enriches the model beyond what the base element type captures.

Together, these three files constitute a traversable, structured representation of the felixOrg system. An AI agent given these files does not merely have information about felixOrg. It has a model of felixOrg: a graph whose nodes are real entities and whose edges are typed relationships, from which it can traverse the system in any direction, follow dependency chains across layers, and identify structural relationships that no individual document could reveal.

The difference is the difference between a library and an architecture diagram. A library contains documents; an architecture diagram models the building the library is in. An AI given the library can answer questions about the documents. An AI given the architecture diagram can answer questions about the building — its structure, its dependencies, its load-bearing elements, and what would happen if one of them changed.

The Personal Digital Twin

The term *digital twin* originated in engineering: a continuously updated virtual model of a physical system, used for simulation, monitoring, and optimization. A digital twin of an aircraft engine is not a manual for the engine; it is a live structural representation of the engine’s state, from which engineers can reason about behavior, predict failures, and test interventions without touching the physical system.

Applied to a person’s operational ecosystem, the concept scales down without losing its essential character. The felixOrg ArchiMate model is a continuously maintained structural representation of the felixOrg enterprise: its goals, its actors, its processes, its tools, its data, and its infrastructure. It is not a biography or a resume. It does not describe what I have done; it models how the system works — what serves what, what realizes what, what depends on what, and why any of it exists in the first place.

An AI agent given this model has something that approximates structural situational awareness of the system it is being asked to work within. It knows that Plato is the strategic architect and Cato is the tactical implementer, and that they have different relationships to different processes. It knows that DEVONthink serves the data archive and search service, which is accessed by the Maintain Digital Archive process, which is realized by the felixOrg records management service, which is provided in pursuit of the Data Integrity and Continuity goal. It can follow that chain in either direction — from goal to infrastructure, or from infrastructure to goal — without any document telling it to.

This is what the personal digital twin provides: not more documents, but a different kind of information entirely.

The Context Economy

Managing context across sessions, agents, and tools is itself an architectural problem — one that felixOrg addresses explicitly. I use the phrase *context economy* to describe the set of mechanisms by which context is created, maintained, transferred, and consumed across the system.

Plato — running on Google’s Gemini — receives the full ArchiMate model as uploaded CSV files that persist across conversations. This persistence is architecturally significant: Plato does not need to be re-briefed on the system’s structure at the start of each session. The model files are always present, always current (within the cadence of model updates), and always available for traversal. Plato’s role as strategic architect is enabled by this persistent full-model context: it can reason about the whole system, identify cross-layer dependencies, and make recommendations that are grounded in the complete architectural picture.

Cato — running on Claude Code in the terminal — operates differently. Its context is session-scoped: it begins each session by reading the relevant model files from the local filesystem, working against specific elements and nodes, and producing outputs that update the model or execute against it. Where Plato holds the map, Cato navigates a section of it at a time. This is not a deficiency; it reflects a principled division of labor between strategic and tactical work.

The handoff between sessions and between agents is managed by a standardized template — the Cato Daily Digest Handoff — generated by a shell script and structured to carry the metadata that the next session or agent needs to continue without loss of context. The handoff is not a document dump; it is a structured summary of what changed, what was decided, and what the current state of the relevant model elements is. The architecture of the handoff is itself a product of thinking about context as a resource to be managed rather than a pile to be accumulated.

Full Situational Awareness in Practice

The practical difference between document-level and structural AI collaboration is most visible in problems that cross document boundaries — problems that require understanding relationships among multiple actors, processes, and data sources simultaneously.

Consider medication reconciliation in the post-surgical context. Following a complex surgery and an extended acute rehabilitation stay, the reconciliation problem is real: prescriptions issued by the surgical team, medications managed during rehabilitation, and the existing medication regime supervised by a primary care physician do not automatically align. Discrepancies — dosage, timing, contraindications, omissions — are not visible in any single document. They emerge from the relationship among documents, prescribers, facilities, and the patient’s standing medical history.

An AI given the discharge instructions from the rehabilitation center can summarize them. An AI given the full felixOrg model knows that the medication reconciliation process is a defined business process in the medical management capability; that it involves multiple actors — the attending physician, the consulting neurosurgeon, the primary care provider; that the relevant data objects include both the hospital discharge instructions and the user’s prescription record; and that the goal of the reconciliation is to produce a single, authoritative medication list that all providers have confirmed. It can ask the right questions, identify the structural gaps, and reason about the process as a whole — not just the documents it happens to have been given.

This is what I mean by high-resolution, strategic collaboration. The resolution is not about the model’s intelligence; it is about the richness of the context the model is working within. Structure amplifies capability. A capable model working within structural context produces qualitatively different output than the same model working from a document pile.

The Architecture as Constraint

There is one further dimension of structural context that is easy to overlook: the model is not only input. It is also a constraint and an accountability mechanism.

When Cato produces a delta patch to the ArchiMate model — a set of new or modified elements and relations — that patch either conforms to the existing model structure or it does not. Element IDs either exist in the elements file or they are new additions that require explicit decision. Relationship types either conform to the ArchiMate standard or they are errors. The model imposes a schema, and that schema makes the AI’s outputs evaluable against an objective standard. The AI is not producing text that sounds plausible; it is producing structured data that either fits the model or does not.

When Plato recommends a structural change — a new element, a revised relationship, a reframing of a process — that recommendation can be evaluated against the current model to determine whether it is consistent with existing relationships, whether it introduces conflicts, and whether it addresses a real gap. The model does not make the AI more capable; it makes the AI’s outputs more accountable.

This accountability is, in the end, what distinguishes a personal digital twin from a sophisticated filing system. A filing system organizes information. A digital twin models a system — and a model can be right or wrong, complete or incomplete, consistent or contradictory. Those are standards against which AI collaboration can be evaluated, and they are standards that no document pile can provide.

*The next post shifts from technical to reflective: what does the iterative practice of building and maintaining the ArchiMate model reveal about the system — and about the person — it represents?*

The Architected Self 09

The Architected Self 06

---

Enterprise Architecture for One

ArchiMate is an open standard for enterprise architecture modeling, published and maintained by The Open Group — a consortium whose members include most of the world’s major technology and consulting organizations. It was developed to answer a question that large organizations have always struggled with: how do you represent, in a single coherent model, the relationships among a company’s strategic goals, its operational processes, the software systems that support those processes, and the physical infrastructure those systems run on? The standard provides a visual language — element types, relationship types, layers — for expressing exactly those relationships in a form that is both human-readable and machine-parseable.

The Archi tool is the most widely used open-source implementation of ArchiMate. It is free, actively maintained, runs on macOS, Windows, and Linux, and exports models in both a native XML format and as CSV files — the elements, properties, and relations files that serve as the machine-readable representation of the model in felixOrg.

Applying an enterprise architecture standard to a personal information system is not an obvious choice. Enterprise architecture was designed for organizations with thousands of employees, complex IT portfolios, and multi-year transformation programs. The felixOrg enterprise has one principal, a handful of AI agents, and a home office. The asymmetry is real. What is also real is that the modeling problem — how to represent the relationships among goals, actors, processes, tools, and infrastructure — does not become simpler when the scale decreases. If anything, it becomes more visible: in a one-person system, there is no organizational chart to obscure the architecture, no department boundaries to contain the complexity. The structure is whatever the model says it is.

The Layers of the Model

ArchiMate organizes elements into layers, each corresponding to a different level of abstraction in the system being modeled. In the standard enterprise context, the layers run from motivation at the top (why the system exists) through business (who does what), application (what software supports it), and technology (what infrastructure runs it). In felixOrg, each layer maps onto real elements with real relationships.

The *motivation layer* holds the goals, requirements, and assessments that justify the system’s existence and constrain its behavior. felixOrg’s motivation layer includes goals such as Data Integrity and Continuity, Fiscal Integrity and Tax Compliance, and Paperless Ground Truth — the architectural commitments that determine which tools are selected and how they are configured. It includes requirements such as the 3-2-1 backup strategy, bit-transparent capture, and just-in-time financial curation. It also includes clinical assessments: a formal medical assessment is modeled as a motivation-layer assessment, because it is a constraint — one that drove a surgical work package and a set of downstream requirements for recovery. The motivation layer is where the model asks: why does any of this exist?

The *business layer* holds the actors, roles, processes, and services that constitute felixOrg’s operations. Robin Felix is a business actor fulfilling multiple business roles simultaneously: records manager, financial manager, facilities manager, medical manager, and model manager. Each role is assigned to processes that realize it: the records manager role is realized by processes for batch scanning and OCR, document tagging, and archive maintenance; the model manager role is realized by the process for managing the felixOrg model itself. Plato and Cato are also business actors in the felixOrg model, with defined roles — strategic architect and tactical implementer — and specific relationships to the processes and services they support. The business layer is where the model asks: who does what, and for what purpose?

The *application layer* holds the software components, data objects, and automated functions that support the business layer. DEVONthink realizes the data archive and search service; Quicken realizes the digital ledger service; Aeon Timeline realizes the temporal mirroring function; the Archi application realizes the modeling service. Data objects — the felixOrg_lib database, the encrypted financial archive, the medical records corpus — are modeled as elements with defined relationships to the applications that access them and the processes that maintain them. The application layer is where the model asks: what tools support the work, and what data do they operate on?

The *technology layer* holds the physical and virtual infrastructure on which the application layer runs. RFStudio — an Apple Studio running macOS with 256 gigabytes of unified memory — is the primary node. Attached to it are the T7 Shield operational SSD, the KSink archive drive, and a CalDigit dock that provides connectivity to the broader workstation configuration. Tailscale provides a secure tunnel to remote nodes; Shell scripts and Applescript provide the primary orchestration layer, coordinating cross-application synchronization that no single application can perform alone. The technology layer is where the model asks: what hardware and infrastructure makes all of this possible?

Typed Relationships: The Grammar of Structure

The layers organize elements by level of abstraction. The relationships between elements are where the model’s explanatory power resides.

ArchiMate defines a vocabulary of typed, directed relationships. A *serving* relationship expresses that one element provides a capability to another: DEVONthink’s data archive and search service serves the business process of maintaining the digital archive. A *realization* relationship expresses that one element gives concrete form to another: the felixOrg_lib database artifact realizes the DEVONthink application component. A *triggering* relationship expresses causation: a business event — the completion of a scanning session — triggers the batch processing process. A *composition* relationship expresses that one element is structurally constituted by others: the felixOrg operational platform is composed of RFStudio, its attached storage, its network connections, and its software stack. An *assignment* relationship expresses that a behavior element is performed by a structure element: the records manager role is assigned to the Manage felixOrg Records process.

Each of these relationships expresses a structural fact about the felixOrg system that no tag, folder, or document can capture. A tag says: this item is of this type. A replicant says: this item appears in this context. A document says: here is a record of something that happened or is known. None of them says: this software realizes this service, which serves this process, which is assigned to this role, which is fulfilled by this actor, in pursuit of this goal. ArchiMate says all of that simultaneously, in a single model.

What the Model Reveals That Documents Cannot

Consider what it means to query the felixOrg ArchiMate model rather than the DEVONthink repository. A DEVONthink query for documents tagged `::med` returns all medical records — a useful corpus. But it does not answer the question: what is the full architecture of the medical management capability in felixOrg? Which actors participate in it? Which processes realize it? Which applications support those processes? Which data objects are accessed, and where do they live? Which infrastructure nodes run those applications?

The ArchiMate model answers all of those questions from a single traversal. It reveals dependencies: that the medical management process depends on DEVONthink for records storage, on Aeon Timeline for event mirroring, and on Plato for synthesis and research — and that all three depend on RFStudio’s infrastructure. It reveals capabilities: that the model manager role is distinct from the medical manager role, even though both are fulfilled by the same actor, and that the processes realizing each role have different tool dependencies. It reveals gaps: elements that appear in one layer without corresponding elements in adjacent layers signal capabilities that are supported but not modeled, or modeled but not supported.

None of this is findable in a document. A document records what happened or what is known. An architecture model records how the system works.

From Hierarchy to Graph

DEVONthink’s organizational logic is hierarchical: items exist at positions in a tree, and replication extends that tree with additional locations. The tree is navigable and useful. It is also limiting: a tree can have only one root, relationships between branches require replication rather than direct connection, and the structure that emerges is a set of nested containment relationships rather than a network of semantic dependencies.

ArchiMate’s logic is a graph. Every element can relate to every other element through typed, directed edges. There is no root, no primary hierarchy, no containment requirement. An actor can serve multiple processes; a process can be served by multiple applications; a data object can be accessed by multiple processes across multiple layers. The graph expresses the actual structure of a complex system, which is never a tree.

The personal information system of any professional of any complexity is a graph problem. Goals motivate requirements; requirements constrain tool selection; tools support processes; processes are performed by actors filling roles; all of it runs on infrastructure. These relationships cross the boundaries of any folder hierarchy and exceed the expressive capacity of any tag vocabulary. The graph model does not replace the document repository; it models what the repository holds.

A Living Model

The felixOrg ArchiMate model is not an archive or a snapshot. It is a current representation of the system’s structure, maintained as the system evolves. When a new device is added to the infrastructure, it appears in the technology layer. When a new clinical finding produces a treatment requirement, it appears in the motivation layer. When Plato or Cato’s role in a process changes, the assignment relationship is updated. The model is always intended to reflect the system as it currently is, not as it was when modeling began.

This currency is what makes the model useful as context — for the architect who maintains it and for the AI agents who work against it. A static model is a historical document; a current model is a structural truth. The distinction between them is the subject of the next post, which examines what it means to give an AI agent not a document but an architecture.

*The next post examines how the continuously maintained ArchiMate model functions as a machine-readable context layer for large language models — and why structural context produces qualitatively different AI collaboration than document-level context.*

The Architected Self 05

---

One Record, Many Locations

DEVONthink’s replication feature is simple to describe and easy to underestimate. A replicated item is a single record — one file, one set of metadata, one canonical entry in the database — that appears simultaneously in multiple groups. It is not a copy. Editing the item in one location changes it everywhere; deleting it from one location removes only that appearance while the item persists in all others. The record has one authoritative existence and as many contextual appearances as the architecture requires.

This mechanism is unremarkable until one considers what it makes possible: a document can be navigated to from multiple angles without being moved from its canonical home. A medical record homed in the temporal bucket can also appear within a physician’s structural group. A financial document homed in the financial archive can also surface on a desktop workspace curated for active work. The item does not change location; its visibility extends. This is what I mean by lightweight hierarchy: hierarchy that costs nothing to create, can be assembled or disassembled without affecting the canonical record, and serves navigation without duplicating storage.

The Desktop as Operational Surface

The first and most immediately practical use of replication in felixOrg is the desktop group — a DEVONthink group containing replicants of current project links and ongoing issues drawn from across the repository. The desktop is not a storage location. It is a curated operational surface: a view of what is currently active, assembled from items that are homed in their proper structural locations elsewhere.

The financial workflow illustrates this clearly. The financial section of the repository includes a broad financial group containing the full historical record, and a work-in-progress group that is a subset of it — current transactions, open items, and active reconciliation work. Both groups appear on the desktop as replicants. The broad financial group is there for reference; the WIP group is there for active management. Neither is moved from its structural home; both are accessible from a single surface without any navigational effort.

This use of replication is, at its core, a productivity pattern — a personalized dashboard assembled from items scattered across a large repository. What distinguishes it from a bookmarks list or a shortcuts folder is that the desktop items are true replicants: they reflect the current state of the canonical records in real time, and any work done through the desktop view updates the canonical record directly. There is no synchronization step, no risk of stale data, no manual reconciliation. The desktop is a window into the repository, not a copy of it.

Contextual Nesting: Organization, Product, Event

The second and architecturally more significant use of replication is contextual nesting: the assembly of a navigable, multi-level view of an entity and its related documents from items homed in different buckets.

The logic proceeds in three levels. An organizational group in `::org_bucket` represents a vendor, institution, or service provider. Within that organizational group, replicants of structural groups — items homed in `::structural_bucket` and tagged `::str` — represent the products, assets, or configurations associated with that organization. Within each structural group, replicants of temporal items — records homed in `::temporal_bucket` — represent the events associated with that specific product or asset.

The 3M example makes this concrete. The 3M group lives in `::org_bucket` — 3M is a vendor. Within that group sits a replicant of the “3M Model 497 vacuum” group, which is homed in `::structural_bucket`: the vacuum is a physical asset associated with 3M. Within the vacuum group sits a replicant of the “20260224 -- Replaced 3M vacuum filter” group, homed in `::temporal_bucket`: the filter replacement is a maintenance event associated with that specific asset on a specific date.

Navigating `::org_bucket` reveals: 3M → Model 497 vacuum → filter replacement event on 24 February 2026. All three levels are navigable from a single entry point. All three items remain homed in their canonical buckets. A query for all `::org` items still returns only the organizational records; a query for all `::tem` items still returns the maintenance event; a query for all `::str` items still returns the vacuum asset. The contextual view assembled by replication does not disturb the canonical structure of the repository; it extends it with a navigational path that the bucket structure alone could not provide.

This nesting also enforces the directional rule described in Post 3: temporal items are replicated into structural contexts, not the reverse. The maintenance event appears within the vacuum group; the vacuum’s structural record does not appear within `::temporal_bucket`. That bucket remains a clean chronological record; the structural groups gain contextual depth without compromising that integrity.

Cross-Database Linking

felixOrg uses multiple DEVONthink databases, as Post 5 described: a primary operational database, a music archive, and an encrypted financial database. Replication within a single database is straightforward and costless. Replication across databases is technically possible in DEVONthink but introduces friction — the replicated item’s home database must be open for the replicant to resolve — and is used sparingly.

Where a cross-database relationship is required, felixOrg uses item links rather than replicants. DEVONthink generates a unique `x-devonthink-item://` URL for every record in every database; an item in the primary operational database can contain a link to a record in the financial database, and clicking that link opens the target record directly if the target database is mounted. The link is not a replicant — it does not create a second appearance of the item — but it creates a navigable connection that serves the same contextual purpose in most cases.

This preference for item links over cross-database replication is consistent with the broader principle of minimizing dependencies. A replicant requires its home database to be open to function; an item link makes its dependency explicit in the URL itself. The item link is a more honest representation of the cross-database relationship: it says “this record exists in another database” rather than pretending the item has two simultaneous locations in one system.

Indexing — the DEVONthink feature that points to files stored on the filesystem outside the database rather than ingesting them — is similarly avoided except by exception. An indexed item is a pointer, not a stored record; its presence in the DEVONthink interface depends on the continued existence and accessibility of the file at its filesystem location. For a dispositive repository, this is the wrong architecture: the record should live in the database, not somewhere the database merely points to. Storing items in the working database is the rule; indexing is the exception, acknowledged as a deviation rather than a pattern.

What Replication Is Not

Replication creates navigational proximity. It does not create semantic relationships.

When the 3M organizational group contains a replicant of the vacuum structural group, that nesting expresses an association: this product is associated with this vendor. But it does not express the type of that association. Is the vacuum owned by the organization, purchased from it, maintained by it, manufactured by it? The replication says none of these things. It says only: these items are related in a way the architect found useful enough to represent by co-location.

This is the fundamental limit of hierarchy, even lightweight hierarchy: it can express proximity and subordination, but it cannot express the nature of a relationship. The 3M group contains the vacuum group — but “contains” is a positional metaphor, not a semantic statement. DEVONthink has no mechanism for saying “3M manufactured this vacuum” or “this maintenance event was performed by a contractor under a service contract” or “this asset is tracked for tax depreciation under Schedule C.” Those statements require typed, directed relationships of a kind that a document database cannot represent.

This is not a criticism of DEVONthink. It is a description of its scope. The document database organizes and retrieves; the architecture model relates and contextualizes. Asking DEVONthink to do what ArchiMate does is asking the wrong tool the wrong question.

Lightweight But Not Thin

Replication is genuinely powerful within its scope. The desktop operational surface, the three-level organizational nesting, the contextual inclusion of temporal events within structural groups — these are not trivial capabilities. They make a large repository navigable in ways that a purely tag-based system cannot replicate, because tags answer “what is this?” while replication answers “where does this belong in a given navigational context?”

The discipline required is knowing where the scope ends. Replication can assemble a rich, multi-level view of an entity and its associated records. It cannot say what those associations mean. When the meaning of a relationship matters — when the architecture needs to express not just that two elements are associated but how they are associated, what role each plays, and what the structural consequence of that relationship is — the work moves to ArchiMate.

*The next post introduces ArchiMate and the Archi tool, and explains how a modeling language originally developed for enterprise architecture maps onto a personal knowledge system with surprising precision.*

The Architected Self 07

The Architected Self 04

---

The Meaning of Dispositive

Post 1 introduced the term *dispositive database* with a brief definition borrowed from legal drafting: a database whose record governs, in the same sense that a dispositive clause creates or extinguishes legal rights rather than merely describing the background against which rights arise. It is time to examine that definition more carefully, because the choice of the term is not rhetorical. It describes a specific architectural commitment with specific consequences.

In contract law, the distinction between dispositive and recital provisions is fundamental. A recital explains; a dispositive clause acts. “Whereas the parties entered into a prior agreement in January 2020” is a recital — background context that informs interpretation but does not itself create obligations. “Buyer hereby purchases and Seller hereby conveys” is dispositive — the instrument of the transaction itself. Remove the recital and the contract still functions; remove the dispositive clause and there is no contract.

Applied to a database, dispositive means that the record in that database is the one that governs when records conflict or when a question arises about what happened, what a document says, or which version is authoritative. Not the scanned paper copy sitting in a filing cabinet, not the email in which a document was attached, not the cloud backup, not a colleague’s recollection — the database record. A dispositive repository is not a convenience copy or a mirror of some other authoritative source. It is the source.

This is a strong commitment. It requires that the database be reliable enough, durable enough, accessible enough, and sovereign enough to deserve that trust. The rest of this post examines whether DEVONthink earns it — and where it does not.

What Earns the Trust

The most fundamental requirement of a dispositive repository is that its owner controls it. This rules out any database whose continued accessibility depends on a third party’s decisions: a vendor’s pricing model, a server’s uptime, a company’s survival, or a government’s cooperation. Cloud-based document management systems offer genuine conveniences — ubiquitous access, automatic backup, search across devices — but they introduce a structural dependency that is incompatible with dispositive status. The record governs only if the record is accessible; a record behind a subscription paywall or a terminated account governs nothing.

DEVONthink runs locally. The databases live on hardware the owner controls, in a format the owner can read. There is no authentication handshake with a remote server, no monthly payment standing between the owner and their data, no terms-of-service revision that can retroactively restrict access. The application is a tool; the data is not hostage to it. This local-first architecture is the technical precondition for dispositive status.

The second requirement is durability of format. A repository that stores data in a proprietary binary format readable only by a specific application version is dispositive in name only — it is dispositive until the application stops working, at which point the records become inaccessible. DEVONthink’s database format — the `.dtBase2` package — is a directory structure containing the indexed documents in their original formats alongside metadata stored in SQLite, an open and widely supported database format. The underlying files are always accessible without the application. Even if DEVONthink ceased to exist tomorrow, the documents in the repository would remain readable, searchable by other tools, and recoverable in full. This is the format analog of ownership: the data belongs to the owner, not to the software.

The third requirement is retrieval capability sufficient to make the dispositive claim meaningful. A repository that governs but cannot be queried efficiently is governance without access. DEVONthink’s full-text search is fast, deep, and tunable — capable of searching across thousands of documents in seconds, supporting Boolean operators, proximity searches, and semantic similarity ranking. Combined with the tag-based retrieval described in Post 4, it provides the query surface that a dispositive repository requires: the ability to answer “does the repository contain a record of X?” with confidence, rather than with a reasonable probability.

The Encrypted Archive

felixOrg uses multiple DEVONthink databases, each scoped to a domain. The primary operational database — `felixorg_lib` — holds the general record: documents, research, correspondence, and the full range of items that pass through the ingestion pipeline described in earlier posts. A second database, `music_lib`, holds the audio and music archive. A third database — the financial archive — is kept in a separate encrypted container.

The financial archive is stored as a `.dtBase2` package inside an encrypted macOS sparsebundle disk image. A sparsebundle is a disk image format that presents as a mountable volume while physically occupying only as much storage as its contents require; the encryption — AES-256 — is applied at the volume level, so the entire database is cryptographically protected at rest. Access requires mounting the sparsebundle, which requires the encryption key managed through the macOS Keychain. The database is accessible only on hardware where the Keychain credential exists.

This architecture is worth describing in detail because it illustrates what sovereignty over sensitive data actually looks like in practice. The financial records — the material most directly relevant to legal, regulatory, and evidentiary obligations — are protected not by a vendor’s privacy policy or a cloud service’s security architecture but by cryptography on hardware under the owner’s physical control. The database is dispositive precisely because the owner controls the only path to it.

Structural Limitations, Honestly Stated

DEVONthink is an excellent document database. It is not a relational database, and it is not an ontological modeling tool. These are not failures; they are scope boundaries. But the boundaries are real and worth naming precisely, because the next two posts turn on what happens when the document database reaches them.

The first limitation is the absence of typed relationships between records. DEVONthink can place documents in groups, replicate them across groups, and tag them with a shared vocabulary. What it cannot do is express a relationship between two records with a defined type: that this document is evidence of a transaction between this actor and this organization, that this configuration record describes the state of this device at this moment, that this clinical assessment was produced by this physician in the context of this care episode. The closest DT can come is co-location in a group or shared tags — proximity and shared classification, not a typed, directed semantic link.

This limitation matters because the most important questions about a repository are often relational: not “what documents mention Dr. Smith?” but “what is the full picture of the care episode he led, across all actors, events, and documents, and how do those elements relate to each other?” The tag query answers the first question; it cannot answer the second. Answering the second requires a modeling layer that DEVONthink was not designed to provide.

The second limitation is the persistence of file-system metaphors. DEVONthink’s groups are enhanced folders — they support replication, tagging, and smart rules that folders cannot, but they retain the fundamental positional logic of the file system. An item has a home group. Replication gives it additional locations. But the navigational model remains hierarchical, and hierarchy remains exclusive in the sense that the primary location is still a single point in a tree. This metaphor serves document retrieval well. It is a poor metaphor for modeling a network of relationships, where no element is inherently subordinate to any other and where the interesting structure is the graph, not the tree.

Scope as Virtue

These limitations do not disqualify DEVONthink from its dispositive role. They define it. The things DEVONthink cannot do — typed relational modeling, ontological representation, graph-structured navigation — belong to a different layer of the architecture, which ArchiMate provides. The division of labor is principled: DEVONthink holds the documents and makes them retrievable; ArchiMate models the entities and relationships the documents concern. Neither system needs to do what the other does.

This scope clarity is itself a form of architectural integrity. A system that tries to be both a document repository and a relational model ends up doing neither well. DEVONthink’s designers made decisions — about format, about search, about replication, about tagging — that optimize it for document management. Those decisions produce constraints. Accepting the constraints, rather than fighting them, is what allows the system to function reliably across a professional lifetime.

Cognitive Sovereignty, Technically Expressed

Post 1 defined cognitive sovereignty as the owner’s sustained capacity to locate, understand, and act on their own information without intermediary. DEVONthink’s architecture is the technical expression of that principle.

The repository is local. The format is open. The encryption is owner-controlled. The search is immediate and deep. The application can be replaced without losing the data. The vendor cannot revoke access. No subscription stands between the owner and the record.

These are not incidental features. They are the architectural commitments that make dispositive status possible — and that distinguish a repository that serves its owner from one that its owner must serve. The financial archive sitting inside an encrypted sparsebundle on hardware in the owner’s office is, in the most literal sense, an instrument of cognitive sovereignty: a record that answers only to the person who holds the key.

*The next post examines replication — DEVONthink’s mechanism for placing a single document in multiple contexts simultaneously — and where the lightweight hierarchy it creates yields to the richer relational modeling that ArchiMate provides.*

The Architected Self 06

The Architected Self 03

---

Tags as Language, Not Labels

In most document management systems, tags are annotations: informal markers applied after the fact to make items easier to find. They accumulate organically, multiply inconsistently, and drift in meaning as the tagger’s vocabulary evolves. A tag applied in 2018 may mean something different from a tag bearing the same name in 2024. Without governance, a tag system is not a vocabulary; it is a glossary without a dictionary.

felixOrg treats tags differently. Within DEVONthink, the `::` prefix convention marks a tag as a member of the controlled vocabulary — a term with a defined meaning, a place in a hierarchy, and a governance rule governing its application. *Controlled vocabulary* is a term of art in library and information science: a finite, defined set of terms used consistently to index a collection. In felixOrg, the tag system is not a reflection of how the author happens to describe things at a given moment. It is a stable, maintained language for classifying what documents are and what they concern.

The distinction matters for retrieval. An uncontrolled tag system rewards whoever last renamed a category; a controlled vocabulary rewards anyone who understands the system, regardless of when they query it. The tags applied to a document in 2024 should mean the same thing to a query in 2034.

The `::` Namespace: A Prefix with Purpose

The double-colon prefix does two things simultaneously. It signals membership in the controlled vocabulary — distinguishing a felixOrg tag from a freeform annotation — and it makes the tag visually distinctive in any listing or search interface. A tag beginning with `::` is immediately recognizable as a typed, governed term, not an ad hoc label.

DEVONthink supports hierarchical tags, allowing parent-child relationships that create a structured vocabulary without requiring hierarchical encoding in the tag name itself. In felixOrg, four top-level tags correspond directly to the ontological categories established in Post 2: `::str` (structural), `::tem` (temporal), `::org` (organizational), and `::res` (resource). Each top-level tag is the parent of a set of domain-specific sub-tags. The sub-tags are where precision lives; the top-level tags are where ontological category is enforced.

Critically, the sub-tag names do not encode their parent. `::med`, `::nav`, `::fin`, `::leg` do not signal by name whether they report to `::str`, `::tem`, `::org`, or `::res`. That relationship is maintained in the DEVONthink tag hierarchy itself, not in the naming convention. A reader with access only to a flat tag list cannot determine a sub-tag’s ontological parent; a reader with access to the system can. This is an intentional design choice: it keeps tag names short and scannable at the cost of making the hierarchy opaque to external inspection. The tradeoff favors daily usability over self-documenting structure.

The felixOrg `::` vocabulary currently contains over forty terms: `::act`, `::actor`, `::arc`, `::art`, `::aud`, `::com`, `::cyb`, `::dat`, `::dev`, `::edu`, `::equ`, `::fac`, `::fam`, `::fin`, `::leg`, `::med`, `::mod`, `::mus`, `::nav`, `::nod`, `::org`, `::pet`, `::rad`, `::ref`, `::req`, `::rxf`, `::sdr`, `::ssw`, `::tec`, `::techsrv`, `::tra`, `::wor`, and others. Each is a defined term with a specific domain meaning. `::med` tags medical content; `::nav` tags naval and navigational content; `::rxf` tags content specifically associated with the author as an individual; `::fin` tags financial content; `::leg` tags legal content. The vocabulary is large enough to cover the full range of felixOrg’s domains and constrained enough that every term in it represents a genuine categorical commitment — not a convenience or a guess.

The Four Top-Level Categories

`::str` (structural) is the broadest top-level category. It receives sub-tags for actors, roles, technical components, physical equipment, facilities, human relationships, and other entities that constitute the standing configuration of felixOrg’s operational environment. When an item carries a tag that reports to `::str`, the tag asserts: this item is about something that exists as a persistent entity or relationship, independent of any specific event.

`::tem` (temporal) tags date-anchored items and events. In practice, most temporal items also carry a year tag from the `^YYYY` namespace — making the combination of `::tem` and a year tag the standard marker for a dated record. When an item is tagged `::tem`, the tag asserts: this item is about something that happened at a specific moment.

`::org` (organization) tags content associated with collective entities — businesses, institutions, agencies, service providers. It operates in parallel with `::org_bucket` in the DEVONthink repository rather than subordinate to it. A document filed in `::org_bucket` and tagged `::org` is doubly classified: the group provides structural location, the tag provides categorical retrievability. The redundancy is intentional. Groups can be reorganized; tags persist through reorganization. The tag is the durable assertion; the group is the current address.

`::res` (resource) tags items that are primarily reference material, instruments, or tools rather than records of events or standing entities. Applications, audio collections, software packages, and reference documents that serve as things to be consulted rather than things that happened or things that exist as configured entities fall under `::res`. It is the category closest to what a library catalog would call a resource: something used, not something documented.

Year Tags and Project Tags: Orthogonal Dimensions

The `::` namespace is not the only tagging dimension in felixOrg. Two additional prefix conventions serve distinct purposes and operate orthogonally to the controlled vocabulary.

The `^YYYY` tags — running from `^1967` through `^2027` — provide a year-based temporal cross-reference index. Every item with a significant temporal association carries the year tag marking the year of the underlying event or document date. A document from a 1985 naval deployment carries `^1985`; a 2026 surgical record carries `^2026`. The year tags are not redundant with the `::tem` category: `::tem` asserts that an item is a temporal record; `^2026` specifies which year. An item carries both, and most temporal items do.

The year tag also enables a retrieval operation that the `::` vocabulary cannot perform: returning everything associated with a given year, across all categories. A query for `^2026` surfaces medical records, financial entries, communications, and system events from that year — a chronological cross-section of the entire repository, unrestricted by domain. This is qualitatively different from a `::tem` query, which returns all temporal items regardless of year. The two dimensions — what kind of thing and when — compose independently.

The `##` tags — `##AI`, `##sancho`, `##clawdbot`, `##orbic`, `##secOnion` — mark items associated with specific active projects or systems. These are cross-cutting identifiers: they do not assert a categorical type but a project affiliation. A document can be tagged `::mod ::wor ##sancho` — a modeling work item affiliated with the Sancho project — because the project tag and the category tags operate on entirely separate dimensions. The `##` prefix is visually distinctive from both `::` and `^`, making the three namespaces immediately distinguishable at a glance.

Multi-Tagging and Combinatorial Precision

A document in felixOrg can carry multiple tags simultaneously — a category tag, a domain sub-tag, a year tag, and a project tag, each independently applied. This combinatorial flexibility is what distinguishes a controlled vocabulary from a folder hierarchy. A folder system accommodates one location; a tag system accommodates as many orthogonal assertions as are true of the item.

A medical record of a surgical encounter in March 2026 carries `::tem`, `::med`, `^2026`, and `::rxf` simultaneously — asserting that it is a temporal record, that it concerns medical content, that its year is 2026, and that it pertains specifically to the author. Each tag enables a distinct retrieval path. A query for all `::med` items returns the full medical corpus across all years. A query for `::med` filtered to `^2026` returns the medical records of a specific year. A query for `::rxf` filtered to `::med` returns all medical content associated with the individual, regardless of date. Each combination is a different question, and the tag system answers all of them from the same set of applied tags.

This is the retrieval power that a folder system cannot replicate. The folder positions an item along one axis — its location in the hierarchy. The tag system positions it along as many axes as are genuinely applicable to it, without forcing any one of them to be primary.

Three Systems, Three Roles

It is worth restating the distinction that the previous posts have been building toward, because the next several posts examine each of the remaining systems in depth.

Tags classify and enable retrieval. They answer the question: what is this item, and along what dimensions should it be findable? They operate on the content and attributes of documents and apply across the entire repository regardless of where documents are stored or how the groups are organized.

Buckets provide structural location. They answer the question: where does this item live in the repository? They impose the five-bucket organizational structure — `::actor_bucket`, `::facility_bucket`, `::org_bucket`, `::structural_bucket`, `::temporal_bucket`, plus the `_data_lake` holding area — that the decomposition process routes items into, providing browse-level navigability alongside tag-based retrieval.

ArchiMate provides relational modeling. It answers questions that neither tags nor buckets can: how do the entities this document concerns relate to each other, what roles do they play, what processes do they realize, and what is the structural context of the standing configuration they belong to? These are questions about typed relationships and architectural dependencies, not about documents and their attributes. No tag can express that a device serves a service which realizes a business process. ArchiMate can.

The three systems are complementary rather than competing. A well-designed personal information architecture uses all three, for the distinct epistemic work each performs — and keeps them from bleeding into each other’s roles.

*The next post examines the repository itself — DEVONthink as the dispositive backend of felixOrg — and what it means for a database to be not merely a store, but a sovereign one.*

The Architected Self 05

The Architected Self 02

---

From Taxonomy to Operation

The taxonomy established in the previous post answers a philosophical question: what kind of thing is this data? The present post answers its operational counterpart: where does it go?

The distance between these two questions is not trivial. A taxonomy classifies data in the abstract; decomposition routes it to a specific organizational structure in a specific system. Without a principled mapping from one to the other, the taxonomy is an intellectual exercise — useful for thinking, useless for managing. The decomposition step is where the philosophy becomes practice.

In felixOrg, incoming data is routed through five operational buckets before it enters the DEVONthink repository. These buckets — `::actor_bucket`, `::facility_bucket`, `::org_bucket`, `::structural_bucket`, and `::temporal_bucket` — are not folders in the conventional sense. They are typed ingestion zones, each designed to receive a specific class of items as defined by the taxonomy, and each imposing a normalization discipline on whatever enters it. A sixth named group, `_data_lake`, sits alongside them for items that resist clean classification — a subject addressed at the end of this post.

Maintainability as the Primary Constraint

Before describing how the decomposition works, one design requirement must be stated explicitly, because it governs every decision that follows: the architecture must be easy to maintain.

An elaborate system that demands significant effort to operate is not an information architecture — it is a second job. The measures that distinguish deliberate architecture from ad hoc accumulation are worth adopting only if their cost at ingestion time is low enough to be sustained across a professional lifetime. If classifying an incoming document requires ten minutes of deliberation, the system will be abandoned within a year. If it requires thirty seconds, the system becomes habitual — and habits, unlike procedures, compound.

Every element of the felixOrg ingestion pipeline is optimized for this constraint. The five buckets are few enough to be memorized immediately; the naming convention reduces the decision to three elements; the data lake provides a legitimate exit for anything that resists quick classification. The architecture builds out the structural model — populating the ArchiMate context that later posts examine — not by demanding comprehensive annotation at the moment of capture, but by accumulating well-routed, consistently named items whose structure emerges from the routing discipline itself.

Reduced friction at ingestion and a growing, useful model are not competing goals. They are the same goal, approached from two directions.

The Five Buckets

The `::temporal_bucket` is the most straightforward mapping from the taxonomy. It receives date-anchored events and records: surgical procedures, provider encounters, financial transactions, dated communications, and any other item whose identity is constituted by when it occurred. Items in this bucket do not change after ingestion; they accumulate. The bucket is ordered chronologically rather than alphabetically, because time is the primary retrieval dimension for temporal items.

The `::org_bucket`, `::actor_bucket`, and `::facility_bucket` together receive the structural items from the taxonomy, split along distinctions that the taxonomy itself does not make explicit. `::org_bucket` receives organizational and institutional structural items: businesses, hospitals, government agencies, service providers, and other collective entities. `::actor_bucket` receives individual actors: named persons, agents, and roles held by identifiable individuals. The split between organizations and actors is operationally useful because they have different documentation profiles, different relationship types, and different retrieval patterns. A medical record of a specific encounter belongs under the relevant physician in `::actor_bucket`; an insurance policy belongs under a carrier in `::org_bucket`.

`::facility_bucket` receives physical spaces: rooms, buildings, addresses, campuses, and other locations that exist as named places in the operational environment. Facilities are structurally distinct from the organizations that occupy them and the actors who use them. A hospital is an organization in `::org_bucket`; the rehabilitation wing on the third floor of that hospital is a facility in `::facility_bucket`. Conflating the two produces retrieval failures when the question is specifically about a location rather than an institution — and those questions arise more often than one might expect in a system that tracks medical care, household management, and physical infrastructure simultaneously.

`::structural_bucket` receives standing configurations that are neither organizations, actors, nor facilities: system architectures, operational processes, physical assets, and records of system states that need to be preserved without being attributed to a specific person, institution, or location. In a personal information system of any complexity, there is always a residual class of structural items that resist personification — network topologies, operational procedures, device configurations, equipment owned by no single organization — and `::structural_bucket` is their home.

Knowledge items do not map exclusively to any single bucket. They are typically homed in whichever bucket their primary subject belongs to — a clinical synthesis document lives under the relevant physician in `::actor_bucket`; a reference document about a vendor lives in `::org_bucket` — or they reside in a dedicated area of DEVONthink outside the five-bucket ingestion pipeline, written directly into the repository rather than arriving through a scan or import workflow. The taxonomy distinguishes them by nature; the bucket system routes them pragmatically by association.

The Data Lake

Alongside the five buckets sits `_data_lake`: a named group for items that resist classification. The data lake is not a failure of the taxonomy. It is the taxonomy’s acknowledgment of its own limits — and of the practical limits of time.

Not every incoming item arrives with its classification obvious. A large batch of legacy documents inherited from a previous system, a raw production of records before review, a collection of scanned materials whose dates and subjects have not yet been verified: these are data lake items. They exist; they need to be preserved; their classification is deferred, not abandoned.

The discipline the data lake requires is the discipline of non-permanence. Items in `_data_lake` have an implicit time to live. They should be reviewed, classified, and migrated into the appropriate bucket on a regular cadence. The lake is a buffer, not a destination. A data lake that grows without bound is a taxonomy that is collapsing — items are going in and not coming out, and the residual category is slowly consuming the system it was meant to protect. The signal that the lake has become a problem is when it begins to be used as a retrieval source rather than a staging area.

Normalization at the Gate

The bucket assigns a destination; normalization disciplines the item before it arrives. Every item entering felixOrg through the ingestion pipeline is named according to a standard convention: *Name, DTG, 2-3 word Description.*

The DTG — date-time group, a compact integer string encoding date and time in the military convention — anchors every item temporally at the moment of capture or at the moment of the underlying event, depending on the item type. For a scanned document, the DTG reflects the date on the document rather than the scan date: a discharge instruction dated 29 March 2026 carries that date in its name regardless of when it was digitized. For a communication or system log entry, the DTG reflects the event. The discipline ensures that the temporal anchor is always the event’s date, not the filing date — a distinction that matters enormously when reconstructing a chronology years later.

The two-to-three-word description constrains naming precision. It forces a commitment to a characterization specific enough to be meaningful at retrieval but brief enough to remain scannable in a file listing. “Pre-Op Consult,” “Discharge Instructions,” “Firmware Procedure” — these are descriptions, not subjects. They say what the document does, not merely what it concerns. The distinction is not cosmetic: a subject is indexable by search; a description is legible in a file listing without opening the document. Both are necessary; the naming convention captures the description. Search captures the subject.

For scanned PDF documents specifically, tags can be assigned at scan time — at the moment the document enters the system through the scanner workflow. This is the only point in the pipeline where tagging and ingestion are simultaneous. Documents created or received digitally are tagged after ingestion, during a subsequent review step. Tagging at scan time is an efficiency measure for a high-volume intake workflow, not a different category of operation.

The Replication Rule

The taxonomy holds that temporal and structural items are genuinely different in nature. The bucket system enforces this difference — but it also acknowledges that real items sometimes have legitimate claims on both categories. A record of a specific medical encounter is a temporal item: it happened on a specific date, and that date is its identity. But it is also directly relevant to the structural record of the physician who conducted the encounter. A purely positional system would force a false choice: the record goes in `::temporal_bucket` or in `::actor_bucket`, not both.

DEVONthink’s replication feature resolves this without duplication. A replicated item appears in multiple groups simultaneously; it is one record with multiple locations. felixOrg governs replication with a directional rule: temporal items may be replicated into structural buckets, but structural items may not be replicated into `::temporal_bucket`.

The asymmetry is principled. A temporal record of a specific encounter is appropriately surfaced within an actor’s structural group — it provides provenance and context for the standing relationship. But a structural item — an actor’s profile, a standing role, a persistent configuration — has no place in a temporal bucket ordered by date, because the structural item is not an event. Placing it there misrepresents its nature and corrupts the temporal bucket’s chronological coherence.

The rule is simple to state and occasionally difficult to apply in practice. Its difficulty, when it arises, is usually diagnostic: the item resisting clean assignment often turns out to be a knowledge item misread as temporal or structural, and the right response is reclassification rather than relaxation of the rule.

The Ambiguity Principle

Tags — examined in depth in the next post — cannot always be assigned with confidence at ingestion time. The subject of an item may span categories; the appropriate classification may depend on context not yet available; the controlled vocabulary may not yet contain a term that fits precisely. felixOrg’s response to this situation is deliberate: when there is ambiguity about the appropriate tag category, no tag is applied.

This is a harder discipline than it sounds. The impulse in any classification system is to assign a best-guess category and move on. Best-guess categorization feels efficient; in practice, it produces a slow accumulation of misclassified items that degrade retrieval precision without any single visible failure. A document mistagged once is a minor error. A thousand documents mistagged over a decade is a classification system that no longer means what it says.

The ambiguity principle treats an untagged item as preferable to an incorrectly tagged one. An untagged item is still retrievable by its content and its normalized name; full-text search does not require a tag to surface it. An incorrectly tagged item is actively misleading: it appears in tag-scoped queries where it does not belong and fails to appear where it does. The discipline costs nothing at retrieval time and preserves everything at classification time.

Decomposition as Discipline

The five-bucket system, the data lake, and their normalization rules are not overhead imposed on a natural process. They are the mechanism by which the taxonomy becomes durable.

A folder system defers classification: the user creates a folder when they need one, names it according to the convention of the moment, and populates it with whatever seems to fit. The decisions are local and immediate; their consequences are systemic and long-term. Decomposition eliminates that deferral. Every incoming item must answer the same set of questions before it enters the repository: what type of thing is this, which bucket does it belong to — or does it go to `_data_lake` temporarily — what is its normalized name and DTG, and what tag, if any is unambiguously appropriate, applies?

The discipline is imposed at the gate, not retroactively. The payoff is a repository whose contents are searchable, browsable, and auditable in ways that an ad hoc accumulation cannot match. The cost is a moment of considered classification at ingestion. The benefit is every subsequent interaction with the repository for the life of the system.

*The next post examines tagging in depth — how the `::` prefix convention establishes a controlled vocabulary distinct from freeform labeling, how tags interact with the bucket structure to enable precision retrieval, and what it means to distinguish tagging from the relational architecture maintained in ArchiMat.*

The Architected Self 03

The Architected Self 01

---

Before the Tools

Every information architecture project I have seen — personal or institutional — makes the same initial mistake: it begins with the tools. A database is selected, a folder structure is sketched, a tagging convention is adopted, and the data is poured in. The resulting system reflects the logic of the tool rather than the logic of the data. When the tool changes, or when the data’s requirements exceed what the tool assumed, the system must be rebuilt from scratch — because it was never grounded in anything more durable than a software choice.

The correct starting point is not a tool. It is a taxonomy: a principled classification of data by its fundamental nature. Not by subject matter — “medical,” “financial,” “legal” — which is a retrieval convenience, not an ontological distinction. But by what kind of thing the data is, and how that nature determines how it should be stored, related, and retrieved.

felixOrg uses a three-part taxonomy: temporal items, structural items, and knowledge items. These are not categories I invented; they reflect distinctions that have always been implicit in how information systems are designed and how professionals think about records. Making them explicit is what transforms an ad hoc file system into an architecture.

Temporal Items: The Immutable Record

A temporal item is a representation of something that happened. A dated transaction, a medical event, a signed agreement, a communication, a system change, a financial entry: these are records of specific occurrences in the world, tied to a moment in time that cannot be altered.

The defining characteristic of a temporal item is its *immutability*. The event it records has already occurred. A surgical procedure scheduled for 20 March 2026 either happened or it did not; once it happened, that fact is fixed. The record can be annotated, supplemented, corrected, or contextualized — but the event itself is outside the reach of revision. This is what distinguishes a temporal item from a structural item that merely carries a creation date: the date is not an attribute of the record’s administrative metadata but the essential identity of the thing the record represents.

In felixOrg, temporal items include the surgical events of March 2026, discharge instructions tied to specific dates, provider interactions anchored to specific encounters, dated financial entries, and the Aeon Timeline events that mirror significant occurrences alongside the DEVONthink record. Each is anchored to a moment. Each will never become a different moment. Their retrieval logic follows from this: you find them by *when* they occurred, by *who* was involved, by *what* event class they belong to. They do not change; they accumulate.

The practical consequence is significant. Temporal items age in a specific way: they become more valuable as evidence and less valuable as operational guides. A discharge instruction from 2026 is irrelevant to a clinical decision in 2029, but it may be crucial to a legal or administrative proceeding. An architecture that treats temporal items the same as structural or knowledge items will fail to preserve them with appropriate fidelity and will fail to surface them with appropriate precision.

Structural Items: The Standing Configuration

A structural item is a representation of something that exists — not at a moment, but over time. Actors, organizations, roles, facilities, devices, services, relationships: these are the entities and configurations that constitute an operating environment. They persist across events. They predate specific transactions and will outlast them. They change, but their change is not an event; it is a revision of standing fact.

The distinction from temporal items is subtle but important. A physician is a structural item — my surgeon is an actor who exists in the model independent of any particular appointment. The appointment itself — a consultation on a specific date — is a temporal item. The physician persists; the appointment is fixed in time. The relationship between them (physician performs consultation) is a structural relationship that exists as a pattern, while each instance of that pattern is a temporal event.

In felixOrg, structural items populate the ArchiMate model in significant depth: the network of physicians, institutions, and care facilities involved in a surgical episode; the devices and infrastructure of the primary workstation; the applications and data objects that constitute the software stack; the household facilities and equipment managed under felixOrg’s operational scope. These entities were modeled not because they participated in a specific event but because they constitute the standing architecture of a life that are useful for understanding and communication. They require a different representation from temporal items — typed, related, layered — because their nature is relational rather than evidentiary.

Structural items do change. A device is retired; a provider relationship ends; a household configuration is updated. When they change, the model is revised — not by adding a new record alongside the old one, as with temporal items, but by updating the standing representation. This revisability is precisely what distinguishes them from temporal items: the past state of a structural item is generally less important than its current state, while the past state of a temporal item is its permanent and irreducible content.

Knowledge Items: The Synthesized Understanding

A knowledge item is a representation of something that is understood — not observed directly (temporal) or configured as standing fact (structural), but synthesized from research, analysis, reflection, or expertise. Research notes, analytical frameworks, reference documents, strategic syntheses, clinical assessments: these are records of conclusions reached, not events that occurred or entities that exist.

Knowledge items are the most intellectually complex of the three types, and the most prone to misclassification. A clinical assessment — the formal finding of a spinal condition — might appear to be a temporal item (it was produced on a specific date) or a structural item (it describes a persistent anatomical condition). In felixOrg, it is classified as a knowledge item: it synthesizes diagnostic imaging and clinical examination into a standing medical understanding that informs subsequent decisions. The date of the assessment is an attribute, not the identity of the item; the condition it describes is structural, but the assessment itself is a physician’s synthesis. What matters for retrieval is not when it was written or who is the subject, but what it concludes and what decisions it informs.

The distinguishing features of knowledge items are their *constructedness* and their *revisability*. Unlike temporal items, they can and should be revised when understanding deepens or evidence changes. Unlike structural items, they are not simply facts about entities; they are conclusions drawn by an intelligence — human or artificial — from evidence. In felixOrg, knowledge items include reference documents authored by Plato, research notes assembled in DEVONthink, and the written output of analytical sessions: text that will outlive the specific context that produced it and continue to inform decisions long after the session that generated it is archived.

Three Types, Three Temporalities

The taxonomy is not merely a filing convenience. The three types differ in their fundamental relationship to time, and that difference has consequences for how they must be stored, related, and retrieved.

Temporal items are *point-in-time*: they record events that exist at a specific location in the past and do not move. Their retrieval is chronological, associative, and evidentiary. They accumulate without revision; any correction is itself a new temporal record appended to the original, not a replacement of it.

Structural items are *continuant*: they represent entities that persist through time, acquiring attributes and relationships as time passes. Their retrieval is by identity and role — by who or what something is, not when it happened. They are revised as facts change, and only the current state ordinarily needs to be preserved.

Knowledge items are *constructed*: they emerge from synthesis and can be revised as understanding improves. Their retrieval is thematic and conceptual — by what they say and what questions they answer. They improve with iteration; an earlier version is superseded by a later one rather than preserved alongside it as an independent record.

A system that conflates these types — storing a surgical event as if it were a standing entity, or treating a synthesized reference document as if it were an immutable record — will produce confusion that compounds over time. The folder system fails partly for this reason: it provides no mechanism for making the distinction. Everything is a file, and all files are equal. The taxonomy reasserts the differences that the data itself demands.

The Taxonomy as First Constraint

Why does this taxonomy precede tooling? Because every tool embodies assumptions about the nature of the data it manages, and those assumptions must be tested against the taxonomy before a tool is selected or configured.

DEVONthink, as I will examine in later posts, is a strong store for temporal and knowledge items: its full-text search, flexible tagging, and replication features serve documents whose retrieval is evidentiary and thematic. It is a less natural fit for structural items — entities and their typed, directed relationships — which require a modeling language rather than a document database. ArchiMate fills that role. The selection of both tools, and the principled decision about what each one holds, follows directly from the taxonomy. Without the taxonomy, the tool selection is a preference; with it, the tool selection is constrained and justified.

The taxonomy also constrains tagging, naming conventions, and the decomposition of data into operational storage zones. Before a tag can be applied, before a bucket can be assigned, before a database can receive an item, one must answer the prior question: what kind of thing is this?

*The next post examines tagging in depth — how the `::` prefix convention establishes a controlled vocabulary distinct from freeform labeling, how tags interact with the bucket structure to enable precision retrieval, and what it means to distinguish tagging from the relational architecture maintained in ArchiMate


The Architected Self 03

---

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.*

The Architected Self 02

Read more

CINCPACFLT Red Cell was an interesting experiment in 1987-1988, an attempt to see our own fleet operations and battle group transits through the eyes of the other guys. It was a victim of its own success.

In the last Red Cell operation my sequestered Red Cell analysts, working only from expected adversary sensor and intel data on U. S. operations, “directed” a simulated flight by adversary recon aircraft based on the anticipated track of a U. S. battle group. Right on schedule the real-world BEARs showed up at the battle group, an unpredicted dawn overflight that surprised and embarrassed our ops and intel folks both at the battle group and at the CINCPACFLT staff, a BAD THING. Soon after, the Red Cell program was terminated.

Being right and being useful do not overcome possible negative impact to the careers of those seeking flag rank.