One of the most useful questions I received from an early reader of The Human OS Manual was also one of the simplest: Is the Human OS just a software metaphor?
I liked the question because it went straight to the title. Not the argument behind the book, the research, or the stories. The title itself.
A title starts working before the reader has agreed to any of the ideas behind it, and this one arrives carrying a very obvious association. I had spent enough of my working life around software, digital products, cybersecurity, and technology to know that “operating system” would make some readers think immediately of code, interfaces, permissions, updates, background processes, and machines.
My first instinct was to answer no. The book was about biology, behavior, health, recovery, work, technology, relationships, and the conditions in which all of those interact. I was not claiming that a person literally runs software.
But that answer was too defensive. Of course the phrase is borrowed from software. “Operating system” has a history, and the title deliberately uses the familiarity that history created. The more useful question is not whether the phrase is metaphorical. It is what the metaphor allows us to see, and what it might make us misunderstand if we carry it too far.
That distinction matters because metaphors do more than decorate language. They transfer structure from something familiar to something harder to see clearly. Used carefully, that can make a pattern more legible. Used carelessly, the borrowed structure starts telling us what the new thing must be.
What The Metaphor Earns
Biology has never been free of metaphor. Genes have been described as code, genomes as programs or blueprints, cells as factories, proteins as machines, and gene editing as a form of cutting and rewriting. None of those descriptions is literally complete. Their usefulness comes from allowing one structure to illuminate another long enough for a difficult process to become easier to reason about.
Andrew Reynolds has written extensively about this role of metaphor in the life sciences. The important point is not that biology secretly is software, engineering, or architecture. It is that analogy can be scientifically useful without becoming a literal account of what the organism is.
That is the standard I now apply to the Human OS.
The software analogy earns its place for me in one basic way: it reminds us that what is visible on the surface may depend on conditions and interactions that are not visible at the surface.
Most people understand this intuitively with technology. If an application becomes slow or unstable, we do not assume the icon on the screen contains the whole explanation. Memory may be constrained. A permission may have changed. A network connection may be unreliable. Another process may be consuming resources. The visible failure is real, but the useful explanation may sit somewhere else in the arrangement.
That habit of looking below the visible outcome followed me long before I started writing about health. In software and digital products, the error a user encountered was often only the place where a deeper problem finally became visible. In business, a weak result could come from incentives, process, timing, market conditions, or structure. In cybersecurity, a person clicking the wrong link could be the event while rushed work, confusing procedures, hierarchy, or poor system design helped explain why the event was likely.
The visible behavior still mattered. The explanation simply became more useful when the frame widened enough to include what had produced it.
That is the part of the operating-system metaphor I wanted to carry into the book. Irritability is visible. A missed workout is visible. Poor concentration is visible. A night of broken sleep is visible. The fact that something is visible does not guarantee that the explanation begins there.
This is also why I have become wary of frameworks that sound comprehensive because they give every problem a label. A wider model is only better if it reveals something the narrower explanation was hiding. Otherwise it is simply a larger vocabulary.
There is also a subtler risk in borrowing machine language. With a machine, deviation from specification usually points toward malfunction. With a person, an unwanted response can be costly without being meaningless. Avoidance may have been learned in a context where it reduced danger. Vigilance can remain long after the conditions that first made it useful have changed. A habit can persist because it still solves one immediate problem while creating another later.
That does not make every response adaptive or every difficulty a hidden form of wisdom. It simply means that “error” can be the wrong first category. Before deciding what should be corrected, it can be useful to ask what the response has been doing, what conditions keep making it available, and what changing it would actually require. Software language helps me look beneath the interface. Biology requires me not to assume that what I find there is a bug.
A Metaphor Is Not a Claim About What Something Is
The distinction I was missing when I first answered the reader’s question was between using a metaphor and making a claim about the nature of the thing being described.
Those are not the same move.
A map can represent a city without being a miniature city. A scientific model can isolate relationships that matter without reproducing everything about the system it represents. Metaphors work in a similar way. They select. They emphasize. They leave things out.
That is why the omissions matter as much as the similarities.
If “Human OS” encouraged readers to think that biology is programmable in the same sense as software, I would consider that a failure of the metaphor. If it suggested that the right instructions can overwrite history, that a person can be restored to a clean factory setting, or that every unwanted response is equivalent to corrupted code, it would be worse than useless. It would import exactly the kind of reductionism the book is trying to resist.
Daniel Nicholson has made a related argument about machine metaphors in biology. Machines can be useful heuristics for thinking about organisms, but they become misleading when the analogy is promoted into a general theory of what an organism is. A machine is ordinarily designed from outside for a purpose specified by someone else. Its organization is imposed. A living organism develops, maintains itself, changes through experience, and participates in the conditions of its own continued functioning.
That is a much larger difference than vocabulary.
A Person Has No Clean Factory Setting
Software makes one assumption particularly easy to import without noticing it: the idea that there is a correct original state to which the system can be restored.
People do not work that way.
There is no untouched version of me stored somewhere outside the life I have lived. Development changed the organism. Learning changed it. Injury, relationships, work, stress, training, illness, success, disappointment, culture, age, and repeated experience all became part of the conditions from which the next response emerged.
That does not mean people cannot change. It means change is not a rollback.
Even recovery does not return a person to an identical previous version. A good night of sleep can restore function. Training can increase capacity. Therapy can change how an old experience is interpreted. A relationship can alter what feels safe enough to attempt. But the organism that arrives afterward has a history the software metaphor does not know how to represent very well.
This is where language such as “reprogram yourself” has always made me uneasy. Sometimes a new instruction genuinely helps. A different routine, rule, interpretation, or practice can reorganize behavior. But the phrase implies a programmer standing outside the system, entering better code until the correct behavior executes.
Human change is usually messier than that. An intention arrives inside a body with a current level of energy, a history of repetition, social consequences, learned expectations, and practical constraints. The instruction is one influence among many.
The metaphor becomes less useful as soon as it asks us to forget that.
Living Systems Do Not Simply Execute
There is another limit that matters.
Software executes instructions someone wrote. Human behavior does not emerge from a single codebase.
Genetics matters, but genes do not operate in isolation from development and environment. Thought matters, but thinking does not occur independently of sleep, physiology, memory, emotion, social meaning, or current demands. Culture matters, but it does not erase individual biology. Relationships matter, but no relationship fully determines the person inside it.
There is no single layer acting as the programmer while the others obediently execute.
This is one reason I prefer systems language to programming language even though both come from the same technological neighborhood. A system lets us ask how parts affect one another without pretending one part is fully in command.
Even then, the language has to remain provisional. “System” can become its own kind of intellectual comfort. Once you start seeing interactions and feedback loops, almost anything can be turned into a systems explanation. The model becomes more impressive while the person becomes less visible.
I do not want that either.
Sometimes a poor decision is a poor decision. Sometimes someone needs better information. Sometimes a medical problem requires medical treatment rather than a wider theory of lifestyle. Sometimes a difficult job is difficult because the economics are bad, not because the person has failed to regulate themselves. Sometimes a relationship should end. Sometimes the environment cannot be redesigned, and the task is to build enough capacity to meet it.
A systems explanation earns its place only when it explains more than the simpler account without flattening the differences that matter.
The Book Is Not The Metaphor
That distinction became more important as The Human OS Manual developed.
The early language was necessarily compressed. “Operating system” gave me a way to point toward interactions that conventional categories often separate. Sleep, food, movement, work, stress, technology, relationships, attention, and recovery can each be studied on their own, but they are carried by the same person through the same day.
The title helped me name the level at which I wanted to look.
The book eventually needed much more precision than the metaphor could provide. Once the architecture became explicit, the work had to stand on biology, behavioral science, systems thinking, lived observation, and evidence rather than on the reader’s familiarity with software. The analogy could open the door. It could not be allowed to become the explanation.
That is why I would not use this essay to reproduce the architecture of the book. The architecture has its own job. The question here is whether the title remains defensible once the reader can see that the subject is a living organism rather than an engineered machine.
I think it does, but only because the metaphor is limited.
“OS” still communicates something useful before the reader knows the model. It suggests that the visible application is not the whole system, that several processes can interact at once, that local success can coexist with trouble elsewhere, and that changing an outcome may require understanding the conditions in which it is being produced.
Then the software analogy should start surrendering territory.
Questions of development, adaptation, history, relationship, illness, aging, environment, and recovery increasingly belong to biology and ecology rather than software design. I see that as a feature. A metaphor should be allowed to lose explanatory power when the material outruns it.
Why The Title Still Stays
I considered titles that would have placed the book more comfortably inside wellness, performance, healthspan, productivity, or behavior change. Each would have made one part of the project immediately legible. Each would also have encouraged the reader to enter through a narrower category.
“Human OS” had one advantage I kept returning to. Before the reader knew anything about the architecture, it suggested that the visible issue might be part of something larger.
That was enough to earn the title.
It also matched the path by which I reached the work. I spent years inside technology, advertising, digital products, startups, sales, cybersecurity, and commercial systems. The recurring professional question was rarely only whether something had worked. It was what conditions had made that outcome likely, what the visible result concealed, and what would happen if the conditions changed.
Later, when I turned more of that attention toward health, behavior, coaching, breathwork, recovery, and healthspan, I kept finding versions of the same mistake. We often treat the place where a problem becomes visible as though it must also be the place where the explanation begins.
The software metaphor did not create that habit of attention. It gave the habit a compact name.
That provenance matters because I do not want to pretend the language arrived from nowhere. It came through a career spent around systems, then changed as the object of attention changed. The Human OS of the finished book is not software theory applied to the body. It is a biological and systemic framework that inherited some language from a field I already knew.
The distinction is important enough that the title should carry its own warning label.
The Metaphor Should Disappear Into Usefulness
A good metaphor should eventually become less interesting than what it helped the reader notice.
If someone finishes The Human OS Manual still thinking primarily about computers, the title has probably occupied too much space. I want the phrase to make one move possible: from the visible problem toward the conditions and interactions underneath it.
After that, biology should be allowed to be biology. Relationships should be relationships. A city should not need to become an input variable to matter. Grief does not need to become corrupted code. A difficult season does not need a software patch. A body does not need to be called hardware before its limits deserve attention.
The metaphor has done its work once the life becomes easier to read without it.
So yes, the Human OS begins with a software metaphor. I am more comfortable saying that plainly now than I was when the question was first asked.
The metaphor earns its place when it reminds us that visible behavior can depend on conditions and interactions that are not visible at the surface. It stops earning its place when it makes a person sound programmable, replaceable, resettable, or controllable in the way software can be.
The book has to remain on the useful side of that boundary.
I do not need the reader to believe that a human being has an operating system in the literal sense. I need the phrase to help them notice when the problem they can see may be only one part of the explanation.
After that, the metaphor can get out of the way.
See how the Human OS fits together →
If this helped you name something you have been feeling but had not quite put into words, please share it with someone who might need the same language.
The Human OS Manual is now available for pre-order. If this work resonates, you can reserve your copy and follow the ideas here as they continue to develop.
Feel free to leave a comment. I read and respond to every thoughtful note.
Notes and sources
1. Andrew S. Reynolds, Understanding Metaphors in the Life Sciences (Cambridge University Press, 2022).
2. Daniel J. Nicholson, “Organisms ≠ Machines” (Studies in History and Philosophy of Biological and Biomedical Sciences, 2013).
3. Stanford Encyclopedia of Philosophy, “Models in Science” (substantive revision 2025).