The system running this portfolio and job hunt is CS4 in use. When this session ends, it gets one index entry, one chunk append, and a tag.
Foundational RAG
File-Based RAG Architecture
A queryable knowledge base spanning 8+ AI projects, built in plain markdown with no database, no vector store, and no code. It solves the stateless-session memory problem that breaks most sustained AI work.
The Problem
Claude has no memory between sessions. Each conversation starts from zero.
For a single project used occasionally, that's a manageable cost. You re-establish context at the top of a session, lose a few minutes, and move on. Across 8 concurrent projects spanning months of active work, it becomes a structural problem. The context window is finite. Re-loading everything that matters for a given session competes directly with the work you're trying to do. And if you don't re-load it, Claude operates on incomplete information and makes decisions that contradict things decided two weeks ago, in a session it has no access to.
The volume compounds it. Eight projects. Each with its own decisions, conventions, open questions, and accumulated history. Some sessions build on something resolved six weeks prior. Some decisions only make sense in the context of three earlier ones. There's no way to hold all of that in a single context window, and no way to predict which specific pieces will matter before a session begins. The options were: waste significant time reconstructing context manually at the start of every session, accept that Claude would regularly work blind on decisions that required historical context, or find a different structure entirely.
The reasoning, the things tried and rejected and why — all of it existed only in closed sessions with no way to surface it the next time it was needed.
Without the system
Each session starts from zero
With the system
Every session retrievable by tag, date, or entry number
The System
Four components. All plain markdown files. No database, no embeddings, no vector index, no code to maintain.
Component 01
Index Files
Every project maintains a single index file. Each logged session adds one row: an entry number, date, timestamp, a plain-language summary of one or two sentences, a tag set, and a pointer to the chunk file where the full session lives. The index stays small by design. It reads in full without consuming meaningful context, making it fast to scan before any retrieval decision.
Component 02
Chunked Log Archives
Full session content lives in separate chunk files, each capped at approximately 1,300 lines before a new numbered file begins. Large enough that files don't fragment constantly, small enough that reading any single file stays within efficient context limits. The largest project has 16 chunk files and over 11,800 lines. Zero database required.
Component 03
Tag Vocabularies
Each project maintains its own tag vocabulary: lowercase, hyphenated, specific enough to filter meaningfully across months of work. New tags are added only when genuinely needed, and when they are, they get registered in the project's CLAUDE.md. That registration step is what keeps them consistent. Without it, the same concept gets labelled differently each session and topic-based retrieval breaks down.
Component 04
Per-Project Skill Files
Each project contains a .claude/skills/log.md file that instructs the AI on exactly how to log a session: what fields to include, how to handle edge cases, when to open a new chunk file, and how to update the index. This file is what keeps format consistent across sessions and across months. Without it, log structure drifts. With it, every entry follows the same pattern regardless of when the session happened or which context window ran it.
Anatomy of an index entry
How a session uses it
Reads CLAUDE.md
Behavioral rules load automatically
Loads index
Scans the full entry list in seconds
Identifies chunk
Tag or entry number narrows the target
Pulls history
Only the relevant archive file is read
Format varies by project type
Work and career sessions use structured detail blocks: date, role context, what was decided, what was produced. Reflective sessions use a transcript-style format that preserves the conversational texture rather than compressing it.
A third format serves a different purpose entirely. Each entry logs a brief situation summary followed by a list of coded IDs drawn from an external reference database. The meaning lives in the database, not the log. The log exists to track what was flagged across sessions — so when the same item surfaces in a new scenario weeks later, it's visible as a recurrence. Designed for cross-session pattern detection, not for reading as narrative.
The index structure stays the same across all three. The chunk format adapts to what that type of content is actually for.
For a recruiter evaluating AI implementation work, the signal here isn't what was built. It's that it was designed to hold up. Most AI projects lose coherence across sessions, across tools, and across time. This architecture is the reason the other case studies in this portfolio stayed on track.
Key Architectural Decision
The design constraint that shaped everything was the context window.
Claude can't hold an entire project's history in working memory. It can only read what fits in the current session. Every session starts blank. For occasional use, that's a manageable inconvenience. Across eight or more active projects spanning months of work, it becomes a structural problem: either the session spends significant time re-establishing context, or it starts thin and makes errors from missing it. The design question this forced was specific: what is the minimum structure that allows Claude to re-orient quickly and accurately at the start of any session, without reading everything?
Three decisions answer that question.
Decision 1 — The index as the retrieval layer
The index file is the answer to the re-orientation problem. Each project maintains one. Every logged session produces a single entry: a sequential number, a date, a timestamp, a one-to-two sentence plain-language summary, a tag set, and a pointer to the archive file holding the full transcript. The index is small by design. It reads in full without consuming much of the context window. It functions as a table of contents for months of work.
The chunk files hold the detail. The skill file ensures every future entry is written in a way that makes the index useful. The tag vocabulary ensures that “where to look” can be answered by topic, not just by scrolling backward through time. Each component exists to make the others more valuable. Remove any one and the retrieval layer degrades.
Decision 2 — The living to-do file
The index handles retrieval of history. The living to-do file handles current state. It's read at the start of every session and updated at the end — recording what's complete, what's in progress, and what was deferred. It functions as a last-known-state marker: the first thing the AI reads to understand where the project stands right now, before consulting any history.
When the to-do provides enough context, that's all the AI needs. When it doesn't — when a decision was made three sessions ago and the rationale matters — the AI knows to check the index by tag or date, then read the relevant chunk. The two layers work together: to-do for current state, index and chunks for history.
Decision 3 — The 1,300-line chunking threshold
Full session content lives in separate archive files. Each file holds approximately 1,300 lines before a new numbered file is created. That number wasn't arbitrary.
Too low, and chunk files split constantly, adding navigation overhead to every retrieval. Too high, and reading a chunk to find one specific session becomes expensive, loading far more context than the task requires. 1,300 lines is the calibrated point that keeps single-file reads tractable while letting a project run for weeks before needing a new file. The two-layer structure means the right amount of context is loaded for the task at hand, no more.
Decision 4 — Per-project format variation
A career planning session and a reflective personal session are not the same kind of record. What makes a career session useful to retrieve is the decision that was made and why. What makes a reflective session useful is the texture of what was said. Applying one format to both would have made one of them less retrievable. Designing per-project formats meant accepting upfront complexity in exchange for better retrieval quality later. That tradeoff was worth making.
What this is, technically
No database. No vector store. No code. The system runs entirely on markdown files and behavioral instructions written into CLAUDE.md and the skill files. It is, technically, a manually curated RAG architecture: retrieval-augmented generation where the retrieval layer is structured text and the augmentation is what Claude does with the context once retrieved. The index is the retrieval layer. The chunk files are the knowledge base. The skill files are the schema. The tags are the query interface. The fact that none of this required a database or a single line of code is not a limitation of the design. It's evidence that the design was matched precisely to the constraint it was solving.
The So What
The problem this architecture solves isn't specific to Claude. Any AI system that operates as a series of stateless sessions faces the same constraint: each session starts with no memory of what came before. Scale that across months of work and eight active projects, and the gap between what the AI could know and what it actually knows becomes the primary bottleneck.
What was built here is a retrieval layer, not a workaround. A fast-access index that loads only what's relevant, an archive layer that preserves everything without bloating context, a tagging system that enables topic-based recall, and a format specification that keeps the whole structure consistent without manual reconstruction at the start of every session. The same architecture would work with any stateless AI interface and any file-based output format.
Other models were brought in at various points across these projects — for research passes, parallel evaluation runs, cross-model comparison work. All of them read and wrote the same files using the same protocols. None required special handling or format translation. That was by design: the file structure and skill files provide a stable interface any AI can operate against. The model is interchangeable. The system holds.
What it shows about the builder is a specific kind of systems thinking: not building a feature, but building the infrastructure that lets features hold up over time. This page is running on that system. The portfolio site build and the job hunt it supports are two of the eight-plus projects currently tracked inside it.
8+
Active projects
Career, software, client, personal
16
Chunk files
Largest single project
11,800+
Lines archived
Zero database. Zero code.
Without a database, a vector store, or a line of code, Thomas designed a retrieval architecture that gives Claude structured, queryable access to months of session history across eight or more active projects, with the largest spanning 16 chunk files and 11,800+ lines. He wrote the behavioral scaffolding, chunk management system, and format specifications that keep it consistent without manual intervention. The result is a production memory layer built entirely from plain-text files, maintained by an AI operating inside the system it's maintaining.