Most of what shapes us happens in chains we never see whole. A bad month of sleep, a friend cancelling plans, an old sketch picked up on a free weekend. Each piece is easy to remember. The path between them is not. I’m building huhu to keep those pieces and follow the path.
I think about life through causes and consequences. A life is a web of causes, most of them invisible when they happen. Something small changes the conditions for what comes next, and its effects can land somewhere that seems unrelated.
The universe is the larger picture behind that. Everything we’re made of comes out of a long chain of earlier events, through the formation of elements, stars and planets. That made me curious about the smaller chains inside one life.
Could I reproduce a little of that connected history at the scale of one life, and explore it?
That’s an analogy that drives the question. It doesn’t prove that a life follows the same laws as the universe.
It started in Notion. I called it human os: a template of a person, with every experience logged and filed into parts of a life, and links showing where each thing came from. I rebuilt it as a terminal app, renamed it huhu, and gave it a quiet voice that only answers from what I’ve written. Each version changed my mind about what it should be. This is where it stands now.
huhu is an operating system for a person, built from the life they record. I write what happens and what I think. huhu keeps my exact words, connects them across time and across parts of my life, and lets me ask how things came about.
It runs locally. There’s no telemetry and nothing to perform for anyone. The record belongs to the person who writes it.
Today it’s a terminal app on my computer. I write to keep a thought. ? asks about my entries, ?? explores further, and * marks a spark. Most of the time it stays quiet. When it answers, it points back to the entries behind the answer, and it asks questions rather than telling me what something means.
See the terminal prototypeA capture of the running terminal with fictional entries. No generated answer is shown. Open the image to see it at full size.
Everything starts with an entry: something I wrote, experienced or kept. Its original wording never changes. huhu keeps when I wrote something down and, when my words say so (“yesterday”, “on tuesday”), when it actually happened. Those often differ, and I can correct the second.
A spark is a special kind of entry: one that set off a chain reaction. Every spark is an entry, but most entries aren’t sparks. I can mark one when I write it, or notice it later when many things trace back to it.
Connections point to exact entries:
derived_from
This entry develops from one or more earlier entries.
linked_to
These entries belong together, without one coming from the other.
involves
This entry concerns a person, place or object.
A connection can be one I made, one a model proposed, or one I confirmed. Those never blur, and I can correct a connection without touching the entry. Together, entries and connections form the hive.
The entry table
The prototype stores entries locally in SQLite and saves the text before any model looks at it.
Fields in the prototype’s entry schema
Field
What it keeps
uuid
A permanent identifier for this exact entry.
body
The original wording.
created_at
When I recorded it, which can differ from when it happened.
source
Where the entry came from, such as a capture or an import.
origin_type
Its role: spark, derived, linked, or unclassified.
spark_uuid
The spark this chain traces back to, when known.
derived_from
The entries this one develops from.
linked_to
Other connected entries.
Connections between entries, people and places are stored separately, each with its own identifier, endpoints and type. A proposed cause is not just another connection: it needs its own supporting entries, alternatives and missing information.
My first version split a person into five pillars. Some held up, some didn’t. The version huhu uses now borrows from the way medicine and psychology describe people, as body, mind and social world, and adds what huhu cares about.
An entry can sit under several lenses at once
Lens
What it covers
body
sleep, energy, health, movement, food
mind
thinking, feeling, memory, attention
self
identity, beliefs, spirituality, how I see myself
direction
goals, values, decisions
others
relationships, other people’s decisions
surroundings
places, circumstances, events outside my control
making
building, creating, output
Lenses are views, not folders. The interesting connections are the ones that cross them: a pain in my foot and a stressful week at work, a song idea and the walk where it started.
A model proposes the lenses for each entry and I can correct them. I treat them as something to test, not a truth about people: a blind check compares my own tags with the model’s. If a model and I can’t agree on them, or they never help find anything, they change.
A lot of a life is decided by other people. Someone moves, cancels, invites, leaves. One person’s decision becomes another person’s turning point, and two separate histories have to cross for two people to meet.
So every entry in huhu records who made it happen: me, someone else, or circumstances. A model proposes it, and I can correct it. Without that, a record quietly turns a whole life into one person’s choices.
huhu only knows someone else’s part through what I write about them. To capture more of it, huhu can ask the same simple question to everyone who switches it on, one a day: “what happened today that you didn’t choose?” or “who changed your plans this week?” Asking everyone the same thing also makes different people’s records comparable. Asking changes what people notice, though, so every question huhu asks is recorded too, answered or not.
This is the part I care about most. I want to be able to ask three kinds of question about my own life:
Before: how likely is this to happen?
Because: what’s the chance this happened because of that?
Without: what’s the chance it wouldn’t have happened without that?
The first is a prediction. huhu writes it down with a timestamp before the outcome is known. For now the predictions are mine; a model’s will be scored the same way. Later, the outcome arrives on its own, as a new entry. Then the prediction gets a score. Over many predictions, I can check whether the things huhu called 70% likely actually happened about seven times in ten. If they didn’t, its numbers don’t deserve trust yet. That’s how probabilities stop being made up.
The second and third are about explanation, and they’re different. Something can contribute to an outcome, by speeding it up or changing its direction, even if the outcome would have happened anyway. Whether it would have happened without that event is a harder question. Sometimes the honest answer is a range, or no number at all.
This is where my idea of a game of life comes in. In a choice-based game, you can replay the same moment and watch different endings. Real life only runs once. But many people living many lives, recorded through the same lenses and asked the same questions, start to look like many playthroughs. Across them, I could learn how often a kind of situation leads where. That gives a starting guess for one person, and that person’s own record then adjusts it. Many lives give the first estimate, your life corrects it.
A worked example of “what if it hadn’t happened?”
A fictional chain: a conversation gives me a different route home, I notice a workshop, visit it, and start a device project by 1 October. An older sketch could also have led to the project.
Without that conversation, how likely is it that I would not have started the project by 1 October?
For this example I supplied six yes-or-no background factors, each something the story doesn’t settle. These probabilities are assumptions, not measurements.
Assumed input probabilities, from 0 to 1
Background factor
Probability
r · Conversation changes route
0.70
u · Other reason for route
0.20
w · Route leads to workshop
0.60
q · Workshop found another way
0.10
d · Workshop prompts project
0.80
k · Sketch prompts project independently
0.25
Six yes-or-no factors give 2⁶ = 64 combinations. I assumed they’re independent, so each combination’s weight is the product of its factors.
Keep the combinations that reproduce the recorded story: conversation, route, workshop visit, older sketch and project.
In each one, remove the conversation, keep everything else fixed, and recalculate what follows.
Add up the weight where the project no longer starts in time, and divide by the total weight kept.
Weight where the project no longer starts ÷ weight matching the recorded story
0.1814 ÷ 0.4134 ≈ 0.44
This is a probability of necessity under these assumptions. 0.44 doesn’t mean the conversation was 44% responsible. It answers whether the project would have been missing without it.
PN = P(Y₀=0 | A=1, Y=1, E). A is the conversation, Y is starting the project by the deadline, Y₀ is that outcome without the conversation, and E is the recorded history. This follows Pearl’s definition of necessity. R is taking the route, W the workshop visit and K the older sketch; 1 means present.
A = K = 1R = (A AND r) OR uW = (R AND w) OR qY = (W AND d) OR (K AND k)
Tian and Pearl show why observational records alone usually can’t pin this number down exactly. That’s one more reason to report ranges when the evidence is thin.
Explore the hive
Choose a fictional story and imagine it without one event. Switch to “Explore the hive” to follow the connected entries, look through one lens at a time, move them around and rotate the sphere.
The probabilities here come from rules and assumptions I supplied. They demonstrate the question, not measured causes.
The terminal stores entries, connects them, finds them by meaning and by keyword, and answers from them. I’m still choosing which local language model does the proposing and answering. The hive and the worked example run on fictional stories. It also proposes lenses and who made something happen, which I can correct, asks an optional shared question once a day, and keeps a log of predictions that get scored when the outcome arrives. Model predictions and comparing many people’s records come next.
After that, the plan is simple: use it for months and let the record show what’s worth asking. Every prediction will already be on file, so whatever question comes out of it can be tested against what actually happened.
Other directions I want to explore
Entries could carry photos, recordings, documents and data from other apps, such as a run exported from Strava, with their sources kept.
A name, a feeling or a photo could bring back a forgotten record. That could matter for memory care, including Alzheimer’s disease, but only with clinical partners and careful testing. Finding a record is not the same as remembering.
I also want to know whether a model can learn how a person connects ideas, beyond copying their words.
