Methods, Librarians, and Learned Books
The Response Before The Answer
When a scientist receives a problem, the interesting object is not only the final answer. There is a response before the answer: classify the problem, search for the right analogy, decide what would count as evidence, choose which tools to trust, and only then compute.
That response is a method. Writing matters because it externalizes the method. Analogy matters because it lets a method move: the same response pattern can jump from one domain to another when the structure is similar enough.
The question I keep circling is whether we can learn that response pattern directly.
The Librarian
Imagine a librarian answering a question. They parse the request, walk to a shelf, open a book, copy the relevant fact into a ledger, and produce a reply. If I had the actual book and knew the rule for writing into the ledger, I could do well on the task.
Now replace the book with a learned book. Replace the ledger with a learned ledger. Keep the route.
That is the basic shape I want: generate a method that would produce output x if the right data sources were plugged in, then make the data sources optimizable.
The method might be wrong as a description of the actual librarian. That is fine. It only needs to be a useful route.
Plausible Circuits, Not True Circuits
Given a prompt P, an LLM produces a response R. The hard problem is extracting a plausible method from P -> R: what sources did the model seem to consult, what transformations did it perform, what intermediate objects would make the answer natural?
Circuit interpretability makes this feel less mystical. If we knew which circuits an AI model used over time, we would have evidence about the algorithms it tends to deploy. But for this idea, we may not need the true circuit. A plausible circuit could still define an architecture that generalizes across a class of problems.
That creates the possibility of pruning. If a compact method explains a family of responses, then we can optimize that method and its learned components instead of carrying a giant undifferentiated function around.
The Tradeoff
There is a simple measure hiding here: how much content must be learned after the method is chosen?
A very general method, like an input-output black box, can represent almost anything. But it has weak bias, so it has to learn a lot. A specific method, like “ask the science librarian, check the physics shelf, copy the relevant law, apply it to the example,” needs less content because the route already knows where to look.
So the method has two measurements:
- How many scenarios can it accommodate?
- How much must be learned before it works?
Bias becomes a topological property: the shape of the space of possible routes.
Learning The Library And The Librarian
There is another version where the librarian is itself an architecture. Instead of learning one monolithic system, learn the library and the librarian together. The library stores content. The librarian routes requests. The ledger records useful intermediate structure.
The challenge is disambiguating the interfaces. What counts as a book? What counts as a shelf? What is the ledger allowed to write? In pure neural-network language, these are trainable modules. In a richer substrate, they could be programs, genetic programs, symbolic routines, retrieval systems, or mixtures of all of them.
A Symbolic Detour
Symbolic approaches often get framed around truth and falsehood: propositions, rules, validity, derivation. That is one route, but it is not the only one I find natural.
If I go symbolic, I am more drawn to two neighboring ideas. One is a clear computational substrate, something like Bend or other parallel functional systems where the graph has operational meaning. The other is language-game creation, closer to Wittgenstein’s Brown Book: meaning as use, not as a static proposition.
There is also a third route, closer to a morphological method in philosophy, where the data are familiar uses of words. This is where the computational graph idea lives for me. The graph is not a proof of truth; it is a structured use-pattern that can be observed, abstracted, and optimized.
The Basic Algorithm
Observe a response. Construct a plausible model that explains how such a response could have been produced. Abstract that model into a reusable method. Replace the information sources with learned or searchable components. Optimize the whole thing on tasks of that type.
The central difficulty is source identification. Given only P and R, what did the method need to know? Multi-turn conversations are useful here because they reveal routes, revisions, analogies, and repairs instead of only final answers.
The dream is not to discover the one true internal algorithm. The dream is to generate methods good enough to become architectures.