What it is, and why I built it
I work across a body of files that has grown from a few hundred to nearly nine hundred over the past six months. Methodology drafts. Clinical reference material. Session summaries. Project briefs. Books in progress, my own and others'. Working sketches that may become finished artifacts or may be abandoned. By any reasonable measure, this body of files is the productive output of my recent work.
The File-Tracker is the application I built for myself to make that body of files navigable. It is a single HTML file that opens locally in a browser, with no server, no cloud account, no recurring subscription. It reads from a plain JSON registry that catalogs every file in my workspace and shows me what I have, where it lives, when I last touched it, and what I have noted about it. It is the surface I touch most often during the workday.
But the File-Tracker is no longer just a file browser. Over the past five months of iterative development with Claude as a co-architect, it has grown into something more — an integrated knowledge ecosystem with seven distinct working surfaces, each addressing a different question I have during the work. This essay is a tour of what it has become and an examination of the design pattern that I think makes the whole system distinctive.
The seven surfaces
The File-Tracker presents seven views into the same underlying body of work, each surfaced as a tab. Six of them are tours of an underlying body of files — different cuts through the same registry. The seventh, ResearchIQ, is different in kind, and gets its own section after this one.
All Files is the canonical browser. Every registered file appears here, filterable by project, type, and status, searchable across name and embedded content. This is the surface I open when I am trying to find something.
Projects is the project-level dashboard, derived from the registry. Each project — there are sixteen, mapping one-to-one to top-level folders — appears as a card showing its file count, status mix, last activity, and open notes. Each card expands inline to a working surface for that project: status note, recent activity, open notes with priority badges, quick links, pinned files, and action buttons that initiate work.
Toolbox is the link-launcher for the operational tools I use across projects. Fifteen entries across five categories — AI tools, design and productivity, web hosting, the kind of links I would otherwise have to bookmark in a browser and lose track of.
Save for Later is the read-later inbox. URLs I capture from elsewhere — articles to read, references to revisit — land here with a one-line note about why I saved them. They get triaged into ResearchIQ, archived, or deleted.
Sessions is the directory of my session-handoff documents — the documents I produce at the end of each working session that establish context for the next one. Critical infrastructure for working with an AI partner that does not retain memory across sessions.
Notes is the dashboard of every annotation I have made on any file or project across the system. Filterable by category, status, priority. The badge on the nav button shows me how many open notes I have at any moment.
Each of these surfaces was added incrementally, through a conversation in which I noticed a friction point and Claude proposed a structural response. None was specified upfront. The system as it stands is the artifact of that incremental, iterative co-design.
ResearchIQ is not a catalog
When I first built ResearchIQ, I thought of it as the place where I would store the research I had done — read articles, citations, working notes. A catalog. An organized memory I could return to.
What it became, through use, is something different. ResearchIQ is the system that delivers curated knowledge tailored to a specific drafting purpose. When I am drafting and a passage needs support — a clinical claim, a methodological point, a historical reference — I do not go to ResearchIQ to retrieve what I stored. I go there with a question, and ResearchIQ surfaces what is relevant.
The difference matters. A catalog answers what do I have on this topic. A delivery system answers what do I have that is actually useful for what I am writing right now.
Three things make ResearchIQ work this way. First, it knows the domains my work spans, and when I ask about something it scopes the search to the relevant domain rather than returning everything that happens to mention a keyword. Second, every entry carries an evidence rating: how directly does this article support the kind of claim I would make from it. When results surface, the ratings weight what comes back. Third, ResearchIQ tracks where my coverage is thin. If I am drafting on a topic the catalog under-covers, the system flags it — not as a missing-citation alert but as a hint that the next reading session should fill that domain rather than the one I am tempted to read more in.
None of these capabilities require AI in any sophisticated sense. What they require is that I built the catalog as a knowledge system rather than a list — that I committed, when I started entering articles, to the structure that would make later retrieval intelligent.
This is what makes ResearchIQ the load-bearing surface in the File-Tracker for the kind of work I do. The other surfaces help me navigate and manage. ResearchIQ shapes what I can write. When I am drafting and the supporting material I need exists in the system, it surfaces. When the material does not exist, ResearchIQ tells me before I have drafted around the gap. That is not a catalog function. That is a partnership function — the catalog stops being the destination of my reading and becomes the substrate of my writing.
I will return to ResearchIQ in a later essay where it deserves its own treatment. For this essay, what matters is that one of the seven surfaces in the File-Tracker is not really a surface. It is a system that the rest of the surfaces serve.
What makes the system distinctive
A reader familiar with knowledge-management tools will recognize that each individual surface has analogs elsewhere. Obsidian and Roam Research have linked-note systems. Notion has databases and project views. Pocket and Instapaper have read-later inboxes. Every research tool has tagging. The File-Tracker's individual features are not unprecedented.
What I think is distinctive about the system is the combination — and one design pattern in particular.
The combination. The File-Tracker runs on the file:// protocol with no server. Its source of truth is a plain JSON file that I can edit by hand if I need to. Its dashboard is generated by a Python build script that I can read and modify. It depends on no vendor, no platform, no subscription, no proprietary database. If a piece of it breaks, I can fix it. If a feature is wrong for my workflow, I can change it. The system is mine in a way that hosted SaaS knowledge tools cannot be. This combination — full data ownership plus full code transparency plus working-tool ergonomics — is not common in the contemporary knowledge-tool landscape.
The design pattern. Every working surface in the File-Tracker has a button labeled Flag for Claude. This is what I think is genuinely novel, and it is worth describing in detail.
Flag for Claude
The button appears on file cards, on project cards, on save-for-later items, on research articles, and as a general toolbar action. Clicking it opens a small modal where I select a type — Help, Idea, Question, or Strategic — and write three short fields. Clicking Copy Packet generates a structured text block, copies it to my clipboard, and saves the flag as a note linked to the item.
The text block — the packet — is the payoff. It contains the item's metadata, an excerpt of its content, any notes I have linked to it, any prior flags on the same item, and the three fields I just filled in. Pasted into a new Claude conversation, it gives the conversation everything it needs to engage with the item without asking me orientational questions.
This pattern matters. In the practice of working with an AI partner, the friction point that recurs most often is getting the AI oriented to the specific thing I want to talk about. Without context, the conversation starts at a disadvantage; the first three or four exchanges are spent describing the problem rather than working on it. The Flag for Claude pattern eliminates that friction by making the tool itself responsible for generating the context packet.
The implication is broader than the File-Tracker. In a world where AI partnership is becoming load-bearing for knowledge work, our tools should be designed for it. They should know how to brief an AI about their own contents. They should generate handoff packets the way the File-Tracker does, automatically, with the metadata and content already structured for ingestion. They should not require the user to re-explain what the tool already knows.
I have not seen this articulated as a design principle elsewhere. Most AI integrations in existing knowledge tools are about generating content from prompts or summarizing documents within the tool. The Flag for Claude pattern is different — it is about the tool packaging itself for a separate AI conversation that the user will conduct elsewhere. The tool participates in the partnership without trying to be the AI itself.
I think this pattern will become more common as more people work with AI partners across many tools. The File-Tracker is one instance; the pattern is general.
The DKA underlying
The File-Tracker is also a clean expression of DKA principles applied to its own domain.
Files have single homes — every file lives in exactly one folder. The registry tracks each file once. Cross-cutting access — by project, by type, by date, by tag, by note status — is achieved through metadata, not duplication.
Folders are outlines. The sixteen top-level folders correspond to the sixteen project tags in the registry, no exceptions. The structure is explicit and editable.
Derivable views are derived. The Projects dashboard is computed from the registry at render time. Open-notes counts are computed from localStorage at render time. Status distributions are aggregated dynamically. None of this is stored as primary data; all of it is recomputed every time the dashboard loads.
The system is hand-editable at every layer. JSON for the registry. Python for the build script. HTML for the dashboard, generated from the script. localStorage for ephemeral state. Each layer can be inspected, modified, debugged, and recovered. There is no proprietary opacity.
These properties are not accidental. They are what DKA looks like when implemented in a personal knowledge tool by someone who has been thinking about the principles for thirty-nine years.
The partnership move
The File-Tracker exists in its current form because of the iterative partnership I have described in earlier essays. I did not specify the system upfront. I started with a simpler tool and brought friction points to Claude, who proposed structural responses that I evaluated against my workflow. Each chunk we shipped was preceded by a question I had not thought to ask, and followed by a decision I made about my own work.
The Flag for Claude pattern, in particular, emerged this way. I asked Claude to help me design a way to capture thoughts I wanted to bring into a future Claude conversation. Claude observed that the packet should include not just my thought but the context the conversation would need — file metadata, related notes, prior flags. The pattern fell out of that observation. Neither of us could have produced it alone. I had the workflow problem; Claude had the design move that turned the workflow problem into a generalizable pattern.
What I find most worth noting is that the system, as it stands, is more coherent than I would have built alone. Not because Claude designed better than I would have, but because the iterative conversation produced design decisions that incorporated both my workflow data and Claude's structural patience. The result is a system that is unambiguously mine in its priorities and unambiguously coherent in its architecture.
What this enables
For me, the File-Tracker is the substrate that makes everything else I do possible. Every essay in this series, including this one, is drafted with the File-Tracker open on a second monitor. Every research project, every methodology draft, every session of work — all of it lives in or moves through the system. The Flag for Claude button is what I press when I want to bring a specific thing into a Claude conversation; the packet that lands on my clipboard is what makes the conversation immediately productive rather than orientational.
For the broader question of what this means: knowledge workers in any domain could build similar ecosystems for their own work, applying DKA principles and using AI partnership to evolve the system over time. The File-Tracker is one instance of a general pattern. The methodology is portable; the specific implementation is mine.
The pattern's value compounds. Each tool you build that knows how to package itself for AI conversations makes the next AI conversation more productive. Each AI conversation that lands fully oriented produces design moves you can fold back into the tools. The system improves with use. This is not magic; it is the consequence of designing for the partnership explicitly rather than treating AI as an external resource bolted onto otherwise traditional software.