2026 is going to be for adding edges to our corpus of 2025. Here I am laying out a detailed prescription of hows and whys (according to me). My rule for myself is that I am not going to introduce any new points to the corpus myself in 2026, and solely create edges between the data. Then I would like to move up several points in Mashey's small-is-beautiful Bell labs success scale:

1. Not even I use it
1. I use it
1. My close friends use it
1. My somewhat distant friends use it
1. We are inundated by strangers

The scheme I am prescribing here it going to be new for me as well, so I am graduating to "I use it" at the beginning of next year, and we will see from there!

Lateral transfer of knowledge is observed to be extremely difficult. Git and package management are not successfully solving this problem. This motivates my 2026 methodology.

1. Write common lisp condition fragments, i.e.
   - new named ANSI CL conditions
   - new common lisp functions with-restarts (in the condition sense)
   - new common lisp handlers to attach to named conditions
2. These are stored in lispdef entities in a knowledgebase
   - In the Leonardo System, entities are in entityfiles are in knowledgebases are in agents are in software-individuals
3. tar archives of one knowledgebase in one of your agents in one of your software-individuals at one point in time are published on itch.io
4. On the other end, you download itch.io knowledgebase archives into an agent in one of your software-individuals
5. Your software-individual generates a `lisp` code artifact directly being a concatenation of conditions, functions with-restarts, and condition handlers.
6. Your creation of 5. is your program as such which is itself a knowledgebase, an archive of which you would distribute on itch.io.
7. Tangentially the software-individual containing your agents has as its own kitten as its body. Originally, this concept was Sandewall's `Madman` knowledgebase, but this bitrotted (it was too tightly coupled to what the web was like 15-20 years ago). However Sandewall's Biological Software concept of a software-individual with a society-of-mind of internal agents, having knowledgebases of and about its limbs/functionality, needs something like a biological notion of a body, though as Sandewall noted, obviously not a literal human one. He used dynamic document generation (madman). I am going to introduce a kitten-based one, madkitten.

This is the whole scheme. I am going to try this for a year, and hopefully you join me (moving me up Mashey's scale to "joined by close friends" or even "joined by not-so-close friends" (before we are all inundated-by-strangers).

## Sharing knowledgebases (i.e. leonardo system generated directories of knowledge)

You do not make knowledgebase directories directly rather the leonardo system makes one persistent, dynamically updated directory for knowledgebases inside an individual's agents, which are human-readable (much more human-readable than XML or s-expressions). We cannot publish agents on itch.io because agents are essentially chunks of brain matter, which are a part of a functioning brain. On the otherhand, knowledgebases - fragments of programs __used by__ chunks of brain matter agents, are already by their nature nice archivable and sharable folders.

When individuals' agents are communicating with eachother, e.g. in FIPA standard interagent communication, they are generally exchanging single properties of single entities at a time because this is the only sane thing to do in logical calculus terms. However, this works between two agents because they are functioning unattended, and quite quickly. For humans involved, the human will download and untar an entire new knowledgebase (i.e. Leonardo generated directory structure) into an agent to digest at a time.

## Choosing itch.io

Viz itch.io - Their content policy [identifies AI-based mass content as bannable spam](https://itch.io/docs/creators/quality-guidelines#avoid-uploading-excessive-amounts-of-automatically-generated-or-ai-generated-content) but it is not entirely banned as long as it is accurately flagged which is a little weak, but at least a gesture in the anti-slop direction. Sez them, they support open and independent game development by freely hosting games and game fragments free and long-term.

Itch.io __is__ an __indie game marketplace__ which accepts payments for you on your behalf and handles payment processors with a default of *pay-what-you-will, suggested $2*. In 2026, I will experimentally try and lean into this two-dollars-or-free model. One thing is that it creates a visible difference between free, open software development and begging. Many people are in contexts where begging for help is completely appropriate, but I honestly do not think that software development or wikipedia for that matter should be indistinguishable from the plight of people in Gaza right now for example.

Itch.io's profit model is that marketplace sellers pay-what-they-will from purchases of their game / software content to sponsor itch.io itself. This is not very evil as companies go.

Note that I am not suggesting that lisp programmers' work is worth $2 / program. This is like getting one cup of coffee once in passing. The person who is *just* getting a cup of coffee someone else was already making does not pay to staff the cafe, or to build the cafe. On the other hand, if you want someone to build (and publicly release!) a particular condition / handler / function for your particular case, that would be hundreds of dollars per part of a day of work as normal: if you wanted them to maintain it, that would be a monthly retainer on top of the payment for any particular work. (Sorry that I am just outlining software business as usual). But for one cup of coffee in passing you only buy the cup of coffee in passing. However I will also note that you might prefer to buy a cup of coffee for two dollars rather than just opportunistically drinking unattended cups you find on uncleared lunch tables. At the same time, I think everyone can agree to unconditionally make and give coffee to people who say they cannot afford it.

## Focus on the Common lisp condition system

The common lisp condition system is a piece of lisp thoughtleadership (this is the common term, not just my embellishment) that was adopted into lisp companies but not later copied into later languages as a paradigm yet. It has clear advantages (see Kent's presentation of it for python devs), which I think are well understood to reflect Bell Labs' John Mashey's Small-Is-Beautiful talks, of which we are meant to get him as a guest early 2026.

Common lisp's condition system clearly separates programming into three decoupled (dethrupled?) reuseable parts:

1. Definition of new conditions
1. Lisp functions (programs) `with-restarts`..`(signal condition)` (i.e. to restart locally from after conditions are signalled).
1. Writing handlers i.e. that connect a signalled condition to a local restart via a small lisp program.

Kent calls these handlers half-programs. They have the novelty of being written and attached externally/separately in time to the program that will use them, but in the program's execution are run __locally__, allowing handlers to eventually choose to restart the program locally when appropriate. This is a very big deal. (If you are a non-programmer, this is an incredibly desireable unicorn. If a problem happens inside your house, you are not forced to leave your house before considering the problem. For example you could use a fire extinguisher on a small fire locally, rather than on principle only ever leaving the house and calling a firetruck to eventually arrive. Other languages just do the leave-the-house-to-burn / call-firetruck thing.).

## Emacs eev

The Leonardo system uses emacs' emacs-server for my software-individuals which are each common lisp slime repls. This is intended to be a low level detail from your perspective. I have to use some kind of server and process communication strategy: Emacs has the best available advanced infrastructure.

Interface-wise, I am using Eduardo's eev mode for my Leonardo software-individuals (i.e. autonomously operating containers for agents). eev takes a sort of anti-data-hiding approach to ease of use. Its `find-` functions for example generate disposable documents filled with things you probably would like to do, customised to your particular needs, often needing a single button or a safe repeated button tap at the generated code you have visually identified as what-you-were-going-for.

Furthermore, eev's eepitch machinery for pitching lines of code at potentially interactive-shell emacs buffers is extremely powerful. I co-opted it for my leonardo system to use on the principle that a machine intelligence is intelligent if its useages are common to powerful human useages.