The Bootloader of Knowledge
The alien and the apple
Imagine an alien arrives on Earth with absolutely no knowledge of our world.
It encounters something.
At first, it doesn’t call it an apple. It doesn’t even know that it is an object.
It simply observes a change.
There is a configuration of sensory information. It changes when the alien interacts with it. The alien records the difference.
It tries the same interaction again.
The result is similar.
It tries something different. The result changes.
Now it has the beginnings of a pattern.
It can start making predictions:
If I perform this action again under similar conditions, something similar should happen.
Then it tries to break that prediction.
It changes the conditions. It repeats the experiment. It looks for exceptions.
Eventually, it may notice that certain patterns recur together. Some things consistently appear alongside other things. Some changes persist. Some disappear. Some transformations can be reproduced.
Only after enough observations does it begin giving these regularities names and building abstractions around them.
Eventually it might discover what we call an apple. Later, it might discover that apples come from trees. Later still, it might discover that trees are part of a larger biological system.
But none of those concepts are given to it in advance.
The world comes first. The concepts come later.
That is the idea behind the Bootloader of Knowledge.
A bootloader is the small piece of software that runs first, before the rest of an operating system exists, and prepares the system so everything else can run. The name fits because this process plays a similar role for knowledge: it gives a system a way to start from very little, build reliable claims about the world, and gradually construct more complex understanding without assuming the conclusions it is trying to discover.
The Bootloader of Knowledge
The Bootloader of Knowledge is a process for turning observations into reliable claims.
The basic idea is simple: any claim about the world has to go through a process before the system should trust it.
It is essentially the scientific method formalized from my experience building systems.
The process is:
Change → Compare → Hypothesize → Predict → Falsify → Verify Independently → Generalize → Abstract → Isolate & Intervene → Compose → Calibrate → Select the next target
It is not necessarily linear. It is a loop. A failed prediction can send you back to the hypothesis. A failed calibration can expose a problem several steps earlier. A bug in a foundation can send you back to the type system.
The important part is that claims earn their place in the system through this process.
The rest of this article follows that process.
1. Change: start with what actually happens
The alien begins with change.
It doesn’t begin with an object, a category, or an explanation. Something is different from what it was before.
This is the first stage of the Bootloader because there is nothing to explain until something happens.
There is a configuration of sensory information. It changes when the alien interacts with it. The alien records the difference.
The system doesn’t yet know what caused the change.
It simply knows that there was one.
The system doesn’t yet know what caused the change.
It simply knows that there was one.
For example, imagine the alien releases a small object. The object moves relative to the alien. It releases the object again, and the object moves again. At this point, the alien doesn’t know what “falling” is, or even that there is a force acting on the object. It only knows that the state of the world changed after the object was released.
That distinction is important. The Bootloader starts with observation rather than interpretation.
2. Compare: turn change into a pattern
Once there is a change, the next step is to compare it with what came before, and with what happens when the interaction is repeated.
The alien tries the same interaction again.
The result is similar.
It tries something different.
The result changes.
Now there is something more useful than a single observation. There is a relationship between actions and outcomes that can be compared across observations.
The alien releases objects of different shapes and sizes. It releases them from different positions. The objects continue to move toward the same region of space. The alien still doesn’t know why. It has simply discovered that the changes are related in a repeatable way.
This is where the Bootloader begins moving from raw change toward knowledge.
Compare does not explain the difference yet.
It establishes that a difference exists and gives the system something that can be investigated.
3. Hypothesize: propose an explanation
Once the system starts seeing patterns, it can propose a hypothesis.
The alien might arrive at something like:
If I perform this action again under similar conditions, something similar should happen.
At this point, the system has an explanation to investigate.
But it does not have knowledge yet.
A hypothesis is a proposal. The Bootloader deliberately keeps that distinction because accepting a hypothesis too early would turn an assumption into a foundation.
The alien might now propose: “Objects released under these conditions tend to move toward this region.” It doesn’t call that region “down,” and it doesn’t call the phenomenon “gravity.” Those concepts haven’t been established yet. The hypothesis simply describes the pattern it has observed.
The next stage exists to make the hypothesis testable.
4. Predict: make the hypothesis vulnerable to reality
A hypothesis becomes useful when it produces a prediction.
If the system believes that a particular action produces a particular result under certain conditions, it should be able to say what it expects to happen when those conditions occur again.
The alien predicts that if it releases another object from the same location, the object should move toward the same region. It then predicts that releasing it from a higher location should still produce movement toward that region.
Now the claim can meet reality.
This is an important transition in the Bootloader.
The system has moved from:
“I think this might be true.”
to:
“If this is true, I should observe this.”
That gives the system something it can try to break.
5. Falsify: try to break the claim
The next stage is Falsification.
Instead of asking only how to confirm the hypothesis, the system changes the conditions. It repeats the experiment. It looks for exceptions.
It tries to break its own prediction.
The alien releases objects from different locations. It uses different objects. It releases them at different heights. It changes the surrounding conditions. It looks for an object that does not behave as predicted. If it finds one, the hypothesis needs to change. If it doesn't, the hypothesis has survived another attempt to break it.
This is where tests become part of the Bootloader.
A test is essentially a falsification attempt. It makes a claim about what the system should do, then tries to find a situation where that claim fails.
The generic parts of the system should therefore have generic tests.
Test the atoms.
Test the types.
Test the state machine mechanics.
Test the rules that should remain true regardless of which domain is built on top.
Those tests can remain stable while the domain changes.
End-to-end tests serve a different purpose.
They test the composed system at the point where all the pieces meet. A Playwright test, for example, can take a claim that appears correct in isolation and try to falsify it through the actual application.
This matters because some failures only appear after composition.
The generic components may each be correct while their combination is not.
If every domain gets its own collection of tests tied closely to its implementation, those tests become expensive to maintain. Domains change. The tests change with them. Eventually the test suite itself becomes a source of technical debt.
Testing the generic substrate works differently.
The tests can remain stable while the domain changes because they are testing the claims that are supposed to remain stable.
6. Verify Independently: don’t let one implementation prove itself
Surviving a falsification attempt is not always enough.
There is a second layer of verification that is easy to overlook: independent verification.
Two systems that share the same implementation can agree simply because they share the same mistake. Independent implementations provide a stronger test.
The alien now uses a second experimental setup to measure the object's movement. Instead of relying on the same observation mechanism, it uses a different one. If both independently produce the same relationship, the alien has more reason to trust the result.
A compiler and runtime, two interpreters, or a specification checker and execution engine can provide this kind of comparison.
If they arrive at the same result independently, the claim has survived a stronger test than internal consistency alone.
This gives the Bootloader another important property.
A claim shouldn’t become foundational simply because one implementation happens to agree with itself.
The more important the claim becomes, the more valuable independent verification becomes.
7. Generalize: determine what survives the experiment
If a claim survives falsification and independent verification, the Bootloader can ask a new question:
What part of this result applies beyond the specific case in which it was discovered?
The alien tests rocks. Then pieces of metal. Then water. Then itself. The observation appears to apply across many different things. It can now move from “this particular object behaved this way” toward “objects in this environment exhibit this behavior under these conditions.”
This is Generalization.
Don’t leave a special-case patch in one consumer if the underlying rule belongs in the generic substrate.
Move it to the layer where it can protect everything built on top of it.
This is where the Bootloader starts turning individual discoveries into reusable knowledge.
But generalization alone isn’t enough.
The system still needs to determine what form that knowledge should take.
8. Abstract: put stable knowledge into reusable structures
Generalization leads to abstraction.
The central architectural question becomes:
What should remain stable, and what should be allowed to change?
A useful system needs both.
The generic layer provides stable rules and mechanisms. The domain-specific layer provides the changing behavior built on top of them. The two need to remain separate.
The alien now needs a way to represent what it has learned. Eventually, after enough investigation, it might develop an abstraction for the persistent relationship it has discovered. Much later, we might call that relationship “gravity.” The important point is that the abstraction came after the observations, predictions, and experiments that supported it.
This separation is a consequence of the Bootloader.
Once a rule has survived the process and been shown to apply beyond one particular case, it should not have to be rediscovered independently by every domain.
It can become part of the generic layer.
Atomic composition
The basic building blocks should be small enough to be reused everywhere.
Think LEGO. The same pieces can be assembled into many different structures. You don’t modify the LEGO brick every time you build a different house.
This is what makes the generic and domain-specific split real. Domain behavior comes from composing the atoms differently, rather than constantly creating new versions of the atoms themselves.
The Bootloader can therefore produce small, stable pieces of knowledge that can later be composed into more complex systems.
Strict typing
The type system becomes a shared reference point.
There should be one definition of a type, imported everywhere that needs it. When that definition changes, the consequences propagate through the system.
This is useful because the system itself surfaces disagreement. An edit to a shared type should force dependent code to prove that it still makes sense.
The type system therefore acts as part of the generic reference layer.
This is especially important because foundational claims propagate the furthest.
A mistake in a high-level feature might affect one feature. A mistake in a shared type or primitive can affect everything built on top of it.
That makes the foundation a particularly important target for the Bootloader.
The more foundational the abstraction, the more carefully it needs to survive the process.
9. Isolate & Intervene: find where the problem actually lives
The Bootloader doesn’t stop at abstraction.
A system can discover that something is wrong without immediately knowing where the underlying problem is.
A bug might appear in a high-level feature while the actual problem exists in a shared primitive.
The system therefore needs to isolate the real cause and intervene there.
Suppose one of the alien's experiments produces a different result. It doesn't immediately change its entire model. It changes one variable at a time. Is it the object? The location? The measuring apparatus? The environment? By isolating the variables, it can determine where the disagreement actually originates and intervene there.
This is the role of Isolate & Intervene.
The goal is not simply to patch the visible symptom.
It is to identify where the underlying claim or mechanism is wrong, then make the change there.
This is another reason to separate generic mechanisms from domain-specific behavior.
If the problem is generic, fix it in the generic substrate.
If it is domain-specific, keep the intervention at the edge.
Side effects
The domain-specific part is where the system touches the outside world.
Databases, APIs, files, users, networks and other external systems all introduce domain-specific behavior and uncertainty.
Keeping these effects isolated means they can change without contaminating the generic substrate.
The generic machinery stays stable. The domain-specific behavior lives at the edges.
This gives the Bootloader a place to intervene without constantly changing the foundations that have already survived previous cycles of verification.
10. Compose: put the validated pieces back together
Once the relevant change has been isolated and made, the system has to compose it back into the larger system.
This is where state machines become useful.
State machines provide a generic substrate for mutation.
A state machine can be thought of as a sequence of frames. Something is in one state, an event occurs, and it moves to another state.
The mechanism doesn’t need to know what those states mean. It only needs to know that states exist and that transitions follow rules.
That makes the state machine useful as a generic container for many different domains.
The generic mechanism can therefore remain stable while domain-specific knowledge is composed on top of it.
The alien can now combine its knowledge about the behavior of objects with its knowledge about movement, measurement, and navigation. Each piece can be used as part of a larger system without needing to rediscover the underlying relationships every time.
This is the Compose stage of the Bootloader: validated mechanisms and abstractions are combined into something that can operate in a particular domain.
Some failures only become visible here.
The generic components may each be correct while their combination is not.
That is why composition feeds back into the earlier stages rather than being the end of the process.
11. Calibrate: determine whether the system still matches reality
After the change has been composed into the system, the Bootloader needs to determine whether the system is still behaving as expected.
This is Calibration.
The alien predicts where an object should arrive after being released from a particular position. It measures what actually happens and finds that the prediction is slightly wrong. It measures the difference, adjusts its model, and runs the experiment again. Calibration is the process of bringing the model and the observed world back into closer agreement.
A system can have a correct local rule while its broader model becomes stale.
It can pass its existing tests while the environment around it changes.
Calibration therefore closes the current cycle by asking whether the knowledge produced by the process is still useful and accurate enough for the environment in which the system operates.
This is where the earlier stages come together:
Compare → Hypothesize → Predict → Falsify → Verify → Calibrate
The system observes what happened, compares it against its expectations, and determines whether its model still corresponds sufficiently well with reality.
If not, the process begins moving backward.
A failed calibration can expose a problem several stages earlier.
Entropy: the constraint on running the Bootloader
The Bootloader describes how a system learns what is correct.
Entropy describes the constraint under which that process operates.
Resources are limited. A system can only absorb so much disorder from its environment and push so much back out. But the important variable is not simply how much disorder exists at any given moment.
Time matters.
What matters is the rate at which disorder accumulates compared with the rate at which the system can process and export it.
A spike is fine if the system has enough time to deal with it before the next one arrives.
It is similar to debt. Having debt is not necessarily the problem. The problem starts when accumulation consistently outpaces repayment.
The Bootloader is part of that repayment process:
Compare → Hypothesize → Predict → Falsify → Verify → Calibrate
Each cycle takes time.
A system’s survival therefore depends on whether it can complete its cycles quickly enough to keep up with its environment.
If the environment changes faster than the system can complete its loop, its model can become stale before it has even been verified.
The system may have a perfectly sound process for producing knowledge, but if the world changes faster than the process can run, the knowledge arrives too late.
That staleness is itself accumulating entropy.
This is why equilibrium is not stillness.
It is bounded mutual change between the system and its environment.
The system changes in response to the environment, and the environment changes in response to the system.
A system whose claims about the world are wrong makes the problem worse. It keeps acting on the wrong model, so its interactions with the environment become wasteful or self-damaging.
This is one direct way a broken epistemic process causes a system to exceed its entropy bound while still behaving as though it is maintaining equilibrium.
When a system cannot keep reducing entropy, freezing is the fallback.
Freezing does not reduce the disorder. It stops further exposure to it.
The system gives up some of its ability to adapt in exchange for stopping the accumulation.
But a living system cannot remain frozen indefinitely.
Maintaining equilibrium requires continuous throughput, the same way the human body maintains equilibrium through ongoing processes rather than reaching some final static state.
12. Select the next target: the Bootloader starts again
The Bootloader ends its cycle by selecting what to investigate next.
There will always be another uncertainty, another unexplained change, another assumption that could be wrong, or another foundational claim that could benefit from verification.
The alien now has a useful model of this particular phenomenon, but that model also exposes new questions. Does the relationship change in another location? Does it change outside this environment? Does another large object affect it?
It selects one of these uncertainties as the next target and begins again.
Change → Compare → Hypothesize → Predict → Falsify → Verify Independently → Generalize → Abstract → Isolate & Intervene → Compose → Calibrate → Select the next target.
And repeat.
The architecture exists to make this process cheap and repeatable. A change is made, compared against what already exists, and turned into a hypothesis and a prediction. The prediction is then tested, broken where possible, and independently verified where practical.
The result is generalized, abstracted, and composed back into the system. When something doesn’t behave as expected, the system isolates the cause, intervenes there, and calibrates against reality.
Then it selects the next target.
The goal is not to build a system that never changes. It is to build one that can change without losing its ability to determine whether the change was correct.
Beyond all of this
The Bootloader doesn’t have to stop at understanding the world. Once the loop is stable enough to trust, it can turn itself on its own foundations. A claim can become the next target, then the method used to establish that claim, then the goals that determine what to investigate, and eventually the assumptions behind those goals. The same process keeps running: the system uses its method for gaining knowledge to examine the method itself. In that sense, the Bootloader is not just a way to build knowledge. It is a way for a system to progressively examine and refine the machinery by which it knows.