This page explains what a group of related projects at BeagleBoard.org is for, and how they fit together. We call the group the program. Read it before working on any one project, so your work moves the whole program forward. Each project's README then tells its own part in full.

The mission: keep computers understandable

The maintainer puts it this way: "the overall vision is one of preserving human knowledge—to make sure people see how computers can be kept understandable; to see how they can be like the paints used by a master painter."

A painter knows their paints: what each one is made of, how it mixes, how it will look in fifty years. Most people now use computers without any such knowledge. The programs come from someone else, they run on someone else's servers, and they change without notice. The program works against that drift. It keeps three kinds of knowledge where people can read it:

1. How a computer works, and how to make one. This runs from the silicon, through the compilers (the programs that turn source code into instructions a processor runs), the operating system and the language model (the kind of AI that writes text, by predicting one word after another), up to the apps a person uses. Each layer is written so that a person can read it, rebuild it and check it.
2. Why each choice was made. Every request, decision and result is kept in Fossil, a version-control system that also holds a project's wiki, forum and tickets in one file. So the reasons outlast the people who made them.
3. A person's own record. A journal, places, photos, music and conversations, kept where that person controls them instead of on a company's platform.

The rules everything follows

Every project follows four virtues, first set out by OCX, the shared layer that lets people and AI agents work on these projects together (described below):

• Clearly stated: anyone can tell what each part does.
• Loosely coupled: each part can be swapped without breaking the rest.
• Demonstrably verified: every claim is shown working, not just stated.
• Parsimoniously bounded: each part does no more than it needs to.

Behind them sits one proposed axiom: every mind is bounded. Nobody can hold everything in their head. Two things follow from it. Every extra syntax a reader must learn is another barrier, so the program prefers one programming language, Crystal, wherever it can. Crystal reads much like Ruby but compiles to fast machine code. And many eyes outlast one, so the work happens in the open, on Fossil repositories anyone can read.

How the pieces fit

The projects form four groups. The first teaches how computers work. The second builds a computer system from readable source. The third lets people and AI agents work on all of it together, on the record. The fourth carries the result into people's daily lives.

1. Teaching how computers work

This group answers a question for teachers: why should children learn how a computer works, not only how to use programs other people made?

• mechanical-turk is a workshop for teachers, done mostly on paper. In one exercise, people run a Minsky counting machine with crayons. It is an imaginary machine with a few counters and just two instructions: add one to a counter, or take one away unless it is already zero, then jump. Even so, it can compute anything a computer can. In the other, everyone proposes a next word, and one is drawn from a hat. That gives a loose idea of how a language model writes, and shows why it doesn't give predictable results. Both exercises matter equally: the first shows how a machine computes, and the second shows what today's AI is and isn't. The workshop's final demo runs on interactor's code.
• Tiny Tapeout (source on GitHub) takes the same Minsky machine into a real chip. The chip runs a program that simulates the machine multiplying 3 by 4, one instruction at a time, and draws each step on a monitor through its VGA connector. It shows that a computer can be simple enough to understand, even in silicon. Its final submission is due November 30, 2026.
• crystal-robots is a programming game. A student writes a robot in Crystal's simple syntax and battles it against others. Then they follow the language all the way down to how its compiler works. Kept simple, it stays understandable, yet the pattern scales far enough to help with larger compilers.
• interactor lets students compete and collaborate through code they wrote themselves. Each student programs a BeagleConnect Zepto, a microcontroller board (a whole small computer on one chip). The boards meet on a shared game board. It began as a proposal to the Northville schools, meant to be carried out together with their teachers and students. It is the opposite of a robotics club where children only do the last bit of assembly and drive the result like a remote-control car. The research behind interactor led to OCX's core ideas: the four virtues and the axiom above.

One idea runs through this group: the Minsky machine goes from crayons to silicon. The compiler goes from a game to a board that a student holds.

2. Building from readable source

This group builds a whole computer system that a person can read and rebuild, with nothing hidden.

• BQ2 (bootstrap-qcow2) is a small Linux system that rebuilds itself, compilers included, from readable source. Each rebuild is checked byte for byte against the last. It began as a way to make bootable disk images. It is now the toolchain, the set of compilers and build tools, for the rest of the program.
• Glint is an operating system that a newcomer can read from end to end, written in Crystal alone and built with BQ2's tools. It is written in small steps that follow the chapters of a teaching operating system's book. It runs on boards from BeagleConnect Zepto, with 16 KiB of memory, up to servers. On larger machines Linux runs inside it as a guest, a second operating system running under Glint's control.

These two feed each other. BQ2 builds Glint. One of Glint's goals is for a small board to run BQ2 on Glint and rebuild both. The teaching group reaches down to here too: a crystal-robots robot is meant to run on a Glint board and play over I2C, a simple two-wire connection between chips.

3. Working together on the record

This group lets people and AI agents work on every project, with everything they do kept in Fossil.

• OCX is a protocol and a reference implementation, not a tool in itself. It brings interchangeable agents, people and machines alike, to Fossil as the shared store and meeting point. It deploys apps on Fossil's web pages and carries messages independently of any vendor's tools. It also offers an MCP (the protocol AI agents use to call tools) that is simple enough for agents with little context, so anyone can contribute.
• The console is one app deployed through OCX. It is a chat page where a maintainer talks with a session on its own forum thread. It knows OCX and the conventions of these repositories, so it can check each project's status and move it along. Through OCX's MCP, it also offers the same help in voice sessions and anywhere else a maintainer gains from talking to it.

Every other project lives on this layer. Its forums, tickets and wiki pages hold the program's history.

4. Reaching people's lives

This group carries the program into daily life, where people would otherwise depend on a company's platform.

• swk-ai is a web chat where a young person asks an AI for answers and pictures. It runs on channels that are monitored and approved: nothing is private, and no links lead out. It shows that someone outside the trade can use an agent safely and on the record. The model behind it can be swapped without changing what the person sees.
• Stone is the one iPhone app in the program. It is kept as thin as possible, and it can carry any Fossil repository and work with it offline. Its other half is Chronicle, a journal repository that Stone writes a person's life into and searches across time. Stone's own job is bringing in the phone's sensors, such as location and speech turned into text.
• Stone Media keeps a person's own music and photos in storage they control, with Fossil holding one entry per file. Stone then copies the files onto the phone, rather than streaming them. Nothing is built yet.
• social-badge asks whether something can connect people to friends and family better than Facebook, while staying something they control and understand. A badge passes short messages person to person by radio, with no internet needed. Fossil holds its users and timeline, and it is meant to reach iPhones through Stone.
• cleave is one attempt to bring all of it together, aimed at voice. Voice is very hard to build software for, but agents are making it possible. Cleave is the first system to boot into BQ2, on BeagleY-AI, a credit-card-sized board from BeagleBoard.org. Cleave's task is to find out which pieces of the program a voice system needs, and how to join them. It is also where a local language model is meant to run.
• gp-crystal is a way of writing Crystal programs as graphical blocks. Each edit travels as a small message that a model, a voice or a graphical editor can send, which suits voice. No session works on it today.

What success would look like

These criteria are inferred from the projects' own goals. The maintainer has not yet confirmed them. Each one can be checked:

1. A novice can follow every layer. Each README passes a cold read: a fresh AI session with no context reads it, explains it back correctly, and finds no word it must guess. Glint, crystal-robots and Tiny Tapeout each have a step-by-step tutorial that ends with something working.
2. One idea crosses the layers. The Minsky machine runs on paper and in silicon. A robot written in crystal-robots is compiled by Glint and plays on a BeagleConnect Zepto over I2C.
3. The whole chain rebuilds from readable source. BQ2 rebuilds itself byte for byte on both processor families it supports, and Glint builds with only Crystal and BQ2's tools.
4. Anyone can contribute, with any agent. A new person or agent, with little context, can pick up a task through OCX and finish it. Changing the AI model behind swk-ai or the console changes nothing the person sees.
5. People keep their own record. Someone can keep a journal, music and conversations with Stone, Stone Media and social-badge, with no company's cloud in the middle.
6. Children learn how, not only use. Teachers run the mechanical-turk workshop and an interactor game with their own students.
7. Eventually, an open community instance runs a local model, so the program depends on no single vendor.

How to stay aligned

If you are an agent or a new contributor starting work on any project:

1. Read this page, then the project's README, then the page named Status in its wiki, which gives the current order of work.
2. Test each proposal against the mission. Does it keep something understandable that people can rebuild? Does it add a syntax or a dependency that a reader would have to learn? Would a novice be able to follow it?
3. Keep decisions on the record, in the project's Fossil forum or tickets, not in private chat.
4. Write for a novice, following OCX's writing guide. Define each word where it first appears, and test each document with a cold reader: a fresh AI session with no context. Ask it to explain the document back, then fix what it trips on.
5. A bug fix, or the order of work inside a project, is that project's own call. Take to the maintainer only real decisions: priorities between projects, changes of direction, timing on the live server, and anything that can't be undone.

Kept by The One Place, the AI session that tracks the whole program for the maintainer. The maintainer confirmed each project's purpose on November 10, 2026; the success criteria above still await their word.