When I started building the system, I assumed most of the difficult problems would eventually turn into engineering problems.
If the system did not know enough, I would give it more information. If it made a mistake, I would improve the logic. If the output was weak, I would change the implementation.
Over time, I realized that some of the most important problems were happening earlier than that.
Sometimes the system was not failing because the code was wrong. It was failing because the question I had asked the system to solve was still too simple.
Uncertainty was mostly a problem of missing information, not yet two different problems. An important technology was not yet an investable opportunity. A finished research conclusion was not yet a decision. A convincing methodology had not yet proven that it actually worked.
Those weren't implementation bugs. They were distinctions the system eventually forced me to make explicit.
And once I saw that, the way I built the system changed.
I stopped asking only, “How do I make this work?”
I started asking, “What am I assuming has to be true for this to work at all?”
Much of the system's architecture grew out of finding those assumptions and making them explicit.
Good Research Does Not Need to End in One Answer
The first distinction that became important was between two different kinds of uncertainty.
At first, uncertainty mostly looked like a problem of missing information — gather enough evidence, and a confident answer would eventually be there to find. The more I worked on it, the more I had to separate that kind of uncertainty from a second kind: uncertainty that stays even after the evidence improves, because the future itself hasn't been decided yet.
Sometimes the problem is not that the numbers change. Sometimes the rules underneath them change too — and a system built only to track numbers has no way to notice when the rules themselves have shifted.
So instead of one forecast, the system began producing a small set of plausible paths forward, each with its own reasoning attached — a range with named conditions, instead of one number dressed up as certainty.
The rule I kept coming back to was simple: the confidence in an answer should never be higher than the confidence in the evidence behind it.
A decisive-sounding answer built on thin evidence isn't more useful than an honest range. It's just better at hiding how little is actually known.
An Important Technology Is Not the Same as a Good Investment
The next question was what had to happen between an important technological change and an actual investable opportunity.
“This technology will change the world” can be completely true and still tell you nothing about where to put money, because it skips the part where that change turns into someone's profit.
Answering that meant tracing a real chain: what becomes scarce or hard to replace because of this technology, who controls that scarce thing, and whether they can actually keep the profit it produces once everyone else notices too.
Checking that chain backward mattered as much as building it forward — a good-sounding story that fell apart once questioned in reverse was never really a thesis. It was just a narrative.
And once that chain was taken seriously, a new outcome had to be allowed to exist: sometimes the honest answer is that there is no good investment here at all.
A system that always finds something to recommend isn't doing research. It's manufacturing justification.
A Research Conclusion Is Not the Same as a Decision
I already understood that reaching a research conclusion and making a real investment decision were not the same thing. Building the system forced me to define that difference precisely.
Where does the research stop? What belongs to the decision? What happens when the decision differs from the conclusion? And how should both be preserved without one later rewriting the other?
The system can finish researching something and reach a conclusion. What I actually do with that conclusion depends on things the research was never meant to weigh — timing, what else I already hold, how much conviction I actually feel, plain appetite for risk that day.
If the system ever collapsed those two steps into one, it would have quietly started making decisions on my behalf without anyone deciding that should happen. Keeping them separate meant its own history had to record both, honestly: what the research concluded, and what I actually chose to do about it, even on the times those two didn't match.
That distinction is still unfolding into something larger — a place where a conclusion and a decision can sit side by side without either one pretending to be the other.
A Good Thesis Is Not the Same as a Safe Bet
Building this part exposed another problem, and this one had nothing to do with research quality at all.
Two theses can be equally well-researched, equally correct, and still deserve completely different position sizes — because the cost of being wrong isn't the same for both of them.
Once the research process became clearer, another problem became impossible to ignore: understanding an opportunity and deciding how much exposure it deserves are not the same task.
That meant taking margin for error seriously — financial, operational, and psychological — and separating a risk worth taking from one that risks real ruin, regardless of how sound the reasoning behind it sounds.
Research forms a belief. It should not also decide how much of anything to risk on that belief.
Once that was clear, exposure and risk needed their own boundary inside the system, answerable to their own logic, instead of living quietly inside the research process as an afterthought.
A Methodology Has to Prove Itself, Too
Once there was a methodology worth using, a new question appeared: how would I know whether it was actually getting better at forming beliefs?
It's one thing to build a system that evaluates companies, sectors, and ideas. It's a separate thing to ask whether the way it evaluates them is actually any good — and that second question doesn't ask itself.
If nothing checks the method, it could be wrong in the same consistent way for years and nothing would ever catch it, because a method that's wrong the same way every time still looks internally consistent.
So the methodology itself had to become a hypothesis, not a settled fact — something whose track record gets checked against what actually happened over time, not something installed once and quietly trusted forever after.
An outcome only really counts once it's been checked against what actually happened, not against how convincing it sounded at the time.
My Beliefs Cannot Become the System's Conclusions
Once that boundary existed, another one became visible — and this one was about me, not about the system.
I have my own views on where AI, robotics, and energy are heading, and how those shifts might reshape the economy. Those views are a large part of why I started building this in the first place.
They are also exactly the views most likely to quietly become the system's own assumptions if I'm not careful — not through any dramatic failure, just through the ordinary gravity of a founder's convictions leaking into what gets built.
So I drew a hard line: my own beliefs can point the system toward a question. They cannot answer it on the system's behalf.
Anywhere one of my hunches touches the research, the system now has to go looking for the evidence that would prove it wrong — not only the evidence that would confirm it.
If it can't do that, it isn't researching anything. It's decorating something I already believed with the appearance of analysis.
I used to think I was building a research system.
Increasingly, I think I'm building a system for forming beliefs under uncertainty — one that keeps enough of its own history to later show where those beliefs came from, where they broke down, and whether the way they're formed is actually getting better over time.
None of this happened because the original ideas were simply wrong. Most of them became more specific as the system forced me to define what had previously been left implicit.
The hard part was never only implementing the system. It was deciding what the system should mean by uncertainty, evidence, a thesis, a decision, risk, and learning.