In the earlier development note, I wrote about how KabuForge grew from a collection of Colab notebooks into a local research project. The architecture article discussed how to connect data, factors, strategies, and subsequent decisions so that changing the way an experiment is operated does not change what it means.
Those two articles explain how the project came about and what it is today. There is another question I want to answer separately: why make it open source?
Quantitative research is often associated with secrecy. If a set of tools can help uncover investment opportunities, why not keep it for yourself? If a research method has value, why help other people acquire it?
I understand these questions. For me, though, building KabuForge began with a specific need: I wanted to test my understanding of markets without having to repeat the data engineering and software development every time I asked a new question.
AI and data services gave me a chance to turn these ideas into something I could use. Open source gives the reusable parts of that work a chance to become someone else's starting point.
We can study different questions while sharing part of the foundation.
You do not have to become a professional quant before studying markets
For an individual, quantitative research begins with a need.
An investor may know an industry well and want to find out whether that experience can be translated into explicit stock-selection criteria. They may have a longstanding preference for a certain kind of company and want to understand what that preference has actually contributed. Sometimes there is no complete strategy at all—just a desire to check whether a few memorable market reactions really follow a pattern.
These questions do not inherently belong to institutions. But asking a question and actually investigating it require different abilities.
Suppose I want to compare a financial characteristic with subsequent stock performance. Beyond defining the question, I need to obtain data, standardize stock identifiers, handle the timing of information releases, calculate metrics, organize experiments, and put the results into a form that allows comparison.
What began as an interest in a market phenomenon becomes a whole set of engineering tasks.
In a team, those tasks can be divided up or handled by an existing system. A person working alone often has to do all of them. Over time, it becomes easy to mistake the ability to build a system for a prerequisite for quantitative research.
Professional training certainly matters. Understanding statistical methods, identifying data problems, and assessing whether a result is credible all take learning. But studying a market phenomenon you know something about and building an institution's complete trading capabilities are goals on different scales.
What I want to reduce is the preparation that tools can take care of.
A person's question should not stop before the research begins simply because they are not yet good at building research systems.
AI makes it easier to turn ideas into experiments
The early development of KabuForge was straightforward: I described an idea, asked Gemini to help implement it, ran it in Colab, encountered errors, and continued making changes.
There was no complete architectural plan at that point. When I had an idea, I tried to build it first.
The change this experience brought went well beyond faster coding.
Previously, whether an idea could become an experiment depended heavily on whether the person proposing it could complete the entire implementation. Now I can use AI to help write programs and gradually understand them as I run, inspect, and modify them.
Learning and research can alternate. Encountering a concrete problem and then learning about the relevant code, methods, and limitations is another route into research.
Data is another part of the equation. In my own project, after moving to J-Quants and building a local cache, I began accumulating research that could be run repeatedly through a relatively stable data entry point.
I see this change as an expansion of the opportunity to put knowledge to use.
There used to be a great deal of preparation between reading a formula and using it to test your own question. When barriers to implementation and data access fall, more people gain not only explanations of methods but also opportunities to use them.
This does not mean that the resource gap between individuals and institutions has disappeared, or that everyone will obtain reliable results. It means that a person can begin turning a question into an experiment without first becoming an expert in every technical step.
For me, that ability is more appealing than receiving an automatically generated investment answer.
There are reasons for secrecy, and value in openness
Researchers have understandable reasons for keeping factors, strategies, and even tools private.
Some trading opportunities depend on limited capacity in the market. When more capital acts according to the same rules, the original trading conditions can change. A person who finds an opportunity naturally needs to consider whether sharing it will weaken their advantage.
Tools can also be part of that competitive chain. An efficient data pipeline can accelerate experiments; a distinctive way of organizing data may reveal where a researcher is looking. Even without publishing buy and sell rules, releasing an implementation can transfer some research capability.
There is also the cost of maintenance. Code that works for its author and software that others can install, understand, and extend are different deliverables. Documentation, examples, compatibility issues, and user feedback all take time.
So I do not believe researchers are obliged to make their work public.
For KabuForge, however, I am willing to bear the costs of openness because much of the work can be shared: organizing data, recording experimental conditions, separating research components, saving results, and checking for errors along the way.
These tasks serve my research, and they can serve entirely different research as well.
When a timing error is discovered, other users have a chance to avoid the same problem. When a module's inputs and outputs are clearly explained, others can build on it and change it. New questions from users may also expose limitations I have never encountered myself.
Openness does not automatically improve software. But it gives improvement a chance to reach beyond the original author's experience.
Shared tools can still support different strategies
I do not expect everyone who uses KabuForge to adopt my strategies.
Looking at the same manufacturer, one person may focus first on orders and production capacity, another on cash flow and capital allocation, and another on how quickly the market reacts after an announcement. They can see the same data without considering the same thing most important.
Even when they agree that a phenomenon exists, they may make different choices. One person may be willing to wait for a thesis that plays out slowly; another may care more about capital efficiency. One can tolerate substantial short-term volatility; another needs a process that is easier to sustain over time.
I sometimes say that a strategy is a kind of personality. More precisely, it contains the researcher's experience, attention, and tradeoffs.
The industries we understand, the ways we habitually explain markets, how long we are willing to wait, and the costs we can bear all shape the strategies we develop. Code can record rules, but it cannot transfer the entire background that produced the judgment.
These differences cannot protect a public signal from crowding. A rule can still be copied, and identical trades can still occur.
But they show that sharing a research framework does not automatically make everyone ask the same questions. Common tools can support different directions.
At the same time, personal experience needs to be examined. In ArcaViso's philosophy article, we discussed the noise observers themselves bring in: familiar explanations are easy to trust, and a model that has taken a long time to build can be difficult to let go of.
I can retain my own preferences, but I cannot use “this is my style” to defend a judgment that evidence has already challenged.
Questions can be personal; judgments still need to be tested.
One purpose of sharing the research foundation is to let these different questions be expressed clearly and examined carefully.
If AI can generate code, why do we still need a framework?
If AI can already help write programs, why not let everyone generate a system of their own?
Because being able to generate something does not mean it is worth generating it from scratch every time.
Ten people studying ten different questions may still need similar data organization, configuration management, experiment records, and result outputs. Even if AI helps write the code, those common problems have simply been implemented ten times over.
After generation, the code still needs to be understood, validated, and maintained.
I want completed work to accumulate. A fix can carry forward into later experiments, a clear interface description can help the next user, and a checked module can serve as the foundation for a new implementation.
This is also the value I hope to preserve as KabuForge moves from notebooks to a framework.
The division of responsibilities in its architecture lets researchers change their own factors or strategies without rewriting the surrounding common processes. It also gives users room to go deeper gradually.
At first, someone may simply run an example. Later, they may change the conditions and compare hypotheses. Further along, they may find that an existing module cannot express their idea and add a new implementation, with AI's help or by writing code themselves.
They do not need to learn everything before starting, and they can keep going deeper as their research requires.
This is how far I hope the spread of technology can go: users can understand and modify their tools, eventually conducting research that the original author never designed in advance.
Easier operation still requires understanding what happened
As I let agents take on more of the work of operating the research system, I encountered another problem: the mechanical work decreased, but sometimes I also became more distant from the research process.
Commands were running, parameters were changing, and results appeared. Yet I did not always have a clear grasp of what happened in between.
That made me reconsider what lowering the barrier should accomplish.
I want to reduce repetitive operations while making the relationship between questions, methods, and results easier to understand. After delegating implementation and operation, I still need to know what data the experiment used, what the program did, and why the result deserves confidence.
That is why, in KabuForge's architecture, an agent is a client of the research system. The GUI, CLI, and MCP should follow the same research and decision semantics. Changing the entry point should not quietly change the meaning of an experiment.
Open source also provides a route to that understanding. Users can inspect implementations, trace results, replace modules, or investigate a particular step when they find an anomaly.
Of course, visible code does not mean the process is already clear. Documentation, experiment records, and explanations of results still need to be built. This work determines whether users can reconnect software outputs with their own research questions.
As implementation becomes easier to obtain, understanding the process becomes more important work.
Give more people the means to form their own judgments
ArcaViso's philosophy is to let evidence, calculation, and reasoning constrain judgment, and to help us discover our mistakes sooner.
KabuForge is one attempt to put that requirement into practice in my work.
If someone lacks the means to obtain data, implement ideas, and organize experiments, “let evidence test your judgment” can easily remain a principle on paper. AI and data services improve some of those conditions; a reusable research framework gives those improvements a chance to accumulate.
That is why I am willing to continue building KabuForge as an open-source project.
I understand why specific strategies may need to remain private, and I accept the competitive and maintenance costs that open tools can bring. For this project, I want the parts that different researchers all need to be reusable.
Users may pursue directions I never considered, reject one of my assumptions, or find a problem in the framework. As long as that process can be understood, inspected, and improved, it fulfills part of the value of openness.
I want them to have the means to form their own answers, and to discover when those answers are wrong.
Research can begin with each person's own questions, without each person having to rebuild the tools.
KabuForge is software for research and simulation. This article discusses the motivation for opening research tools and is not investment advice.