A knowledge base should be a place to think

A chronological notebook records when an idea arrived. A knowledge base records where the idea belongs. Both are useful, but they answer different questions.

If I want to understand attention, the date of a note matters less than its relationship to matrix multiplication, probability, and the rest of a transformer. Those relationships are the structure I want to preserve.

Write an explanation with edges

A good chapter has a boundary. It says what the reader needs to know, makes one mechanism clear, and points to the next question. Trying to explain an entire field on one page can make every paragraph depend on a concept that has not yet been introduced.

Internal links are part of the explanation. A link can name a dependency without forcing the reader through it. Someone comfortable with linear algebra can continue; someone meeting a matrix product for the first time can take a detour and return.

Make uncertainty useful

A working note does not need to pretend to be a finished textbook. It does need to distinguish what has been checked from what is still a hypothesis. An unresolved question, written precisely, can be more useful than a confident sentence with an unclear assumption.

Equations and code help because they force choices into the open. A variable needs a definition. An array needs a shape. A program needs to decide what happens at the boundary. When the prose and executable example disagree, there is something concrete to investigate.

Let the structure follow understanding

The first version of a chapter may contain a paragraph about a neighboring topic. As that paragraph grows, it can become a subchapter with a stable address. The original explanation keeps a short bridge and a link.

This is how I want the site to evolve: through small improvements in the place where they are useful. The aim is a collection of explanations that become clearer together.

The attention chapter and the agent architecture chapter are the first examples of that approach.