The question DKA answers
Over a working life of thirty or forty years, a person in knowledge work accumulates a body of material. Documents, references, drafts, ideas in various states of completion, contracts, presentations, methodologies refined across many engagements. By any reasonable measure, this body of material is the productive output of the career — the externalized form of what the person knows and what they have made.
For most knowledge workers, this body of material is not organized. It is scattered across email accounts, defunct cloud services, old hard drives, project-specific document repositories that have since been deprecated, and the unsorted accumulation of a working life. When the person retires, changes companies, or simply needs to find something from eight years ago, the material is functionally lost. The expertise persists in the person's head; the artifacts that supported the expertise are gone or unfindable.
This is not a small problem. It is the default condition of knowledge work, and it represents an enormous waste — the cumulative artifact of decades of effort, abandoned or buried because it was never organized in a way that could survive its own growth.
The Dynamic Knowledge Architecture, or DKA, is a framework for organizing a body of knowledge such that it remains useful as it grows. It is what I have been developing, refining, and applying across my own work for the past thirty-nine years.
What DKA is
DKA is not a software product. It is not a single tool or platform. It is a set of principles that govern how knowledge is structured, stored, and accessed — implemented in whatever specific tools the work requires. The principles are general; the implementations are particular.
The principles are easy to state and difficult to internalize. Across thirty-nine years of applied practice, I have arrived at a small set:
- Knowledge has structure, and the structure should be made explicit.
- Items have a single home; cross-cutting relevance lives in metadata, not duplication.
- Derivable information stays derivable. Do not store what can be computed.
- Folders are outlines. The filesystem is the source of truth.
- Active work and archival reference are structurally separated.
- Project tags map one-to-one to physical folders. No exceptions.
- Naming conventions are not decorative. They carry information.
Each of these principles will get its own essay in the writing that follows, where the reasoning behind it can be unfolded with care. For now, the point is the shape of the set: a small number of principles, mutually reinforcing, that together produce knowledge architectures capable of growing without collapsing.
Why this particular combination works
Knowledge architectures fail in a few characteristic ways.
Pure tag-based systems — where every item is described by free-form tags and no hierarchy exists — handle cross-cutting relevance well but lose structural orientation. After two thousand items, you can no longer browse the system; you can only search it. And search requires you to know what you are looking for, which is exactly the condition that fails for older work whose vocabulary you no longer remember.
Pure folder-based systems — where every item lives in exactly one place in a hierarchy — preserve orientation but fight against cross-cutting access. An item that legitimately belongs to two domains has to live in one folder and be invisible from the other. Browsing works; cross-domain queries do not.
Database-driven systems, popular in enterprise software, can address both problems but introduce a worse one: vendor and format dependence. Your knowledge becomes inaccessible without the specific software you used to organize it. When the software is deprecated, retired, or simply changes its export format, the knowledge degrades.
DKA's combination is filesystem-as-structure plus metadata-as-overlay plus build-pipeline-as-derivation. The filesystem provides the explicit hierarchy — folders are outlines, every item has a single home. A small JSON registry provides the metadata — tags, categories, cross-references, computed views. A build pipeline derives whatever further views are needed — dashboards, indexes, summaries — from the registry, never as primary sources but always as products.
This combination is durable for specific reasons. The filesystem is not going away; it is one of the most stable abstractions in computing, with continuous availability across operating systems and decades. JSON is plain text, version-controllable, diffable, recoverable from any backup. Build pipelines are reproducible — given the inputs, you can always regenerate the outputs.
The system has another property worth naming: it is editable by hand. If something goes wrong in the dashboard, you open the JSON, fix it, rebuild. If a folder structure no longer fits how the work has evolved, you move folders, update the registry's path fields, rebuild. There is no proprietary database to wrestle with, no API to learn, no platform to depend on. The whole system is text files and small scripts. A person with basic tools can maintain it indefinitely.
Why dynamic
The Dynamic in Dynamic Knowledge Architecture is doing real work in the name. Most knowledge architectures are static — defined once, then maintained against an assumed-stable taxonomy. They fail when the taxonomy needs to change, which it always does. The work itself evolves; new domains emerge; old categories no longer fit.
DKA assumes the taxonomy will change and is designed to absorb the change without losing accumulated content. When a new project emerges, you create a new top-level folder; the project tag is added to the registry's canonical list; existing items can be retagged if relevant. When an old project recedes, its folder remains as a reference layer; new work does not touch it. When two folders should be merged because the underlying work has converged, you move the contents, update the paths in the registry, rebuild. The system bends with the work.
This is not a feature most knowledge tools advertise. Most tools are optimized for a snapshot — what your knowledge looks like today. DKA is optimized for the trajectory — what your knowledge will look like across decades of accumulating, reorganizing, recategorizing, and rediscovering.
What DKA enables
The artifacts of a body of work, organized by DKA, become accessible in a way that ad hoc accumulation never makes them. You can find a document from eight years ago because there is a place where eight-years-ago material lives, and the metadata can tell you which projects it touched. You can construct a new view across the corpus — say, every artifact related to a specific clinical domain — because the metadata layer supports cross-cutting queries without requiring you to have anticipated this query when the items were filed. You can hand a body of work to a successor — your team, your literary executor, your future self — and they can navigate it without your real-time guidance, because the structure is explicit.
For me specifically, DKA is what has made it possible to move into late-career productivity that would otherwise be inaccessible. I am working on more substantial artifacts now than at any earlier point in my career — books, methodologies, applications, white papers, knowledge architectures across multiple domains — drawing freely on thirty-nine years of accumulated material. None of this would be possible if the material were scattered.
It is also what makes the partnership with a language model productive. Without DKA, the partnership would be aimless conversation. The model could generate plausible designs for any number of organizational schemes, and I would have no basis for choosing among them other than aesthetic preference. With DKA, every design decision has a principle to evaluate against. The principles are not negotiable; their application is. That asymmetry makes the conversation tractable.
What this essay is not
This essay is not a how-to guide. The principles are stated; the essays that follow develop them with the rigor each deserves. A reader who wants to apply DKA to their own work should read those essays and adapt the principles to their situation.
This essay is also not a complete history of how I arrived at DKA. The principles were not derived in advance; they emerged across decades of failed attempts, and the history of how each principle was discovered matters in its own right. That history belongs in different essays — the case studies, where the principles can be seen forming through specific work.
What this essay is, simply, is a name and a frame. The name is Dynamic Knowledge Architecture. The frame is a small set of mutually reinforcing principles, implemented in plain text and durable tooling, designed to accept the changes that thirty or forty years of knowledge work will produce.
The essays that follow walk through each principle in turn.