I Almost Didn't Go to Harvard. Then We Built STRATUM.

2026-08-12T00:00:00+00:00

I Almost Didn’t Go to Harvard. Then We Built STRATUM.</h1>
I almost didn’t go.
That is probably the strangest part of this entire story.
The Harvard Crimson Business Competition had been sitting on my calendar for weeks. I knew it was coming. I knew the Global Championship Round was going to be held in Cambridge. I knew teams from around the world would be there.
And still, for a while, I was ready to just skip it.
There was a lot going on, and at some point the idea of travelling for a competition started feeling less like an opportunity and more like another thing I had to somehow fit into an already crowded schedule.
My teammate talked me out of it.
I’m really glad they did.
Because a week later, I was in Cambridge.

From Stanford to Cambridge</h2>

I’ve been spending a lot of time studying AI/ML and deep mathematics through Stanford, particularly the parts of the field that sit underneath the models rather than just around them.

The more I study machine learning, the more I find myself interested in the mathematical side of it.

Not just:

Can this model make a prediction? </blockquote>
But:

Why does it work? </blockquote>

What assumptions are we making? </blockquote>

How certain are we? </blockquote>

What happens when those assumptions stop holding? </blockquote>
That curiosity had also been pulling me increasingly toward quantitative finance.
Finance is an interesting place for someone who likes mathematics and engineering because uncertainty isn’t something you can simply ignore.
It is the problem.
You have noisy data, incomplete information, changing conditions, probability, risk and decisions that have consequences.
So when the opportunity to go to the Harvard Crimson Business Competition Global Championship Round came through Stanford, I decided to build something around that intersection.
For the case, I built STRATUM.

Why STRATUM?</h1>
The name came from the architecture.
A stratum is a layer.
And that is essentially what the system became: several layers stacked on top of each other, each responsible for a different part of the problem.
The three layers I cared about most were:
Machine Learning
Deep Mathematics
DevOps
The interesting part wasn’t building three separate components.
It was getting them to actually talk to each other.
That turned out to be much harder.
And much more interesting.

STRATUM: a quantitative system, not just a model</h1>
I didn’t want STRATUM to be another machine learning model sitting inside a Jupyter notebook.
There is nothing inherently wrong with notebooks. I’ve written enough of them.
But a notebook is not a production system.
You can train something, get a promising graph, print a few metrics and convince yourself that you’ve solved the problem.
Then six months later the notebook sits untouched in a folder called final_model_v7_REAL_final.ipynb</code>.
Humanity has created many sophisticated technologies. Naming files remains undefeated.
I wanted STRATUM to be different.
The basic architecture looked something like this:
Market Data | v +-------------------+ | Data Processing | | & Feature Pipeline | +-------------------+ | +----------+----------+ | | v v Machine Learning Mathematical Layer | | | Risk / Optimization | | +----------+----------+ | v Signal Generation | v Quantitative Output | v DevOps Pipeline </code></pre> The important part is that none of these layers exists in isolation. Layer 1: Machine Learning</h1> The first layer is the part most people probably expect when they hear that an AI system is involved. The ML layer looks for structure in financial data that a purely rules-based system might miss. The basic idea is straightforward: Take historical observations, transform them into useful features, train models against those patterns, and use the resulting outputs as part of the quantitative signal. But the goal wasn’t to make the ML model the final authority. That’s important. Financial markets are noisy, and a prediction is still a prediction. So instead of building: Data → ML Model → "Buy" </code></pre> I wanted something closer to: Data ↓ Features ↓ ML Model ↓ Prediction ↓ Mathematical & Risk Evaluation ↓ Quantitative Signal </code></pre> The machine learning layer finds patterns. The rest of the system decides how much those patterns should actually matter. Layer 2: the mathematics underneath</h1> This was the part I enjoyed the most. Machine learning can sometimes feel like magic when you only look at the output. Mathematics removes some of that mystery. Underneath the ML layer, STRATUM uses mathematical and statistical ideas to model the actual quantitative problem. The system incorporates concepts around: Probability</li> Statistical analysis</li> Stochastic processes</li> Volatility</li> Correlation</li> Covariance</li> Risk</li> Optimization</li> Portfolio construction</li> </ul> The stochastic-process side is particularly relevant because financial variables evolve over time and are inherently uncertain. The optimization layer then turns the problem into something more concrete: Given a set of possible assets, expected behavior and associated risk, how should the portfolio be allocated? That is a very different question from simply asking a machine learning model what happens next. And I wanted STRATUM to understand that difference. Why I didn’t want a black box</h1> One of the things I cared about most was making sure the system wasn’t simply: Here’s a prediction. Trust me. </blockquote> That doesn’t satisfy me technically. If a model produces a signal, I want to understand what information contributed to it. If the mathematical layer says the risk has changed, I want the system to account for that. If the optimization layer produces a different allocation, I want to know why. The result is a system where the ML component is one part of the reasoning process rather than the entire reasoning process. That was the philosophy behind STRATUM. Layer 3: DevOps</h1> This is the layer that I think gets skipped in a lot of student projects. You can build a great model. You can have impressive accuracy. You can make a beautiful visualization. But eventually someone asks: How do you actually run this again? That’s where DevOps comes in. I wanted STRATUM to behave like an actual software system. The pipeline was designed around the idea that the model should be able to go through the full lifecycle: Code ↓ Data ↓ Preprocessing ↓ Training ↓ Testing ↓ Evaluation ↓ Deployment ↓ Retraining </code></pre> Instead of manually opening a notebook every time something changed, the system could treat the model as part of an automated pipeline. That meant thinking about: Reproducible environments</li> Automated testing</li> Model retraining</li> Pipeline automation</li> Deployment</li> Version control</li> Monitoring</li> Repeatability</li> </ul> This was probably the most important engineering distinction between STRATUM and a simple ML prototype. The model wasn’t the product. The system was the product. Getting the three layers to work together</h1> This is where most of our nights disappeared. On paper, the architecture looked clean. In practice? Not quite. Machine learning has its own requirements. Mathematical models have their own assumptions. The data pipeline has to keep everything consistent. The DevOps layer has to make the whole thing reproducible. And suddenly you’re not just debugging Python. You’re debugging the boundary between different disciplines. A change in the data pipeline can affect the ML features. A change in the mathematical assumptions can affect the quantitative signals. A change in the model can affect the deployment pipeline. Everything is connected. That is why I called it STRATUM. Not because it sounded impressive. Because the architecture genuinely became a collection of layers that depended on one another. The quant side of STRATUM</h1> At a high level, STRATUM takes financial data and moves it through several stages of analysis. First comes preprocessing and feature engineering. Then the ML layer evaluates patterns in the data. At the same time, mathematical models provide statistical and risk information. Those outputs are combined into quantitative signals. The portfolio layer can then evaluate potential allocations using optimization and risk constraints. The result isn’t supposed to be a crystal ball. It is a quantitative decision-support system. That’s an important distinction. The purpose isn’t to pretend that markets are predictable. The purpose is to build a better framework for reasoning about uncertainty. Three days at Harvard</h1> Then we actually had to present it. And that changes everything. When you build a project alone, you can keep staring at the same architecture until eventually everything looks reasonable. Then someone else asks a question. And suddenly you discover the one assumption you hadn’t thought about. That was one of the best parts of the competition. The Global Championship Round brought teams together from different places and backgrounds, with workshops, talks from industry speakers, mentorship and the competition itself taking place over several days around Harvard’s campus in Cambridge. Presenting STRATUM to mentors and judges who actually work in this space was very different from submitting a university assignment. There was no answer key. No professor was going to circle something in red and tell me exactly what I got wrong. We had to explain the decisions ourselves. Why this architecture? Why this mathematical approach? Why use machine learning here? What happens when the assumptions change? How does the system deal with risk? How would you actually deploy it? Those conversations were probably more valuable than any grade could have been. The part I didn’t expect</h1> I expected the competition to be mostly about the project. It wasn’t. It was also about learning how other people think. You could walk into a room convinced that your approach was obvious and leave realizing that someone else had looked at the same problem from a completely different direction. That’s one of the reasons I enjoy these environments. A competition gives you a deadline, but it also gives you people who can challenge your thinking. And sometimes that’s exactly what a project needs. We completed the Global Championship Round</h1> We walked away having completed the Global Championship Round. More importantly, we walked away with a much better understanding of the problem we had been trying to solve. And honestly, I was more interested in quantitative finance when I left Cambridge than when I arrived. That wasn’t necessarily the outcome I expected. I went in wanting to build a system. I came out wanting to understand the field more deeply. What I learned from STRATUM</h1> The biggest lesson wasn’t a particular machine learning algorithm. It wasn’t a specific mathematical equation. It wasn’t even DevOps. It was the integration of all three. I’ve spent a lot of time learning different areas of technology separately. AI. Machine learning. Mathematics. Software engineering. DevOps. Quantitative finance. Projects like this make you realize that the interesting problems don’t respect those boundaries. A financial model needs mathematics. The mathematics needs good data. The data needs engineering. The ML model needs infrastructure. The infrastructure needs automation. And the final result needs to be understandable by an actual human being. That last part is surprisingly difficult. Why this matters to me</h1> This project also reinforced something I’ve been gradually realizing about the direction I want to take. I’m increasingly interested in problems where software engineering, mathematics and intelligence overlap. Not just building applications. Not just training models. Not just studying equations. But building systems where all three become part of the same thing. Quantitative finance happens to be an incredibly interesting place for that. There is uncertainty everywhere. The data is imperfect. The mathematics matters. The engineering matters. And the consequences of bad assumptions are very real. That makes it difficult. Which is exactly why I like it. Looking back</h1> The funny thing is that I almost didn’t go. If my teammate hadn’t pushed me to make the trip, this entire chapter might not exist. No Cambridge. No three days around Harvard. No STRATUM presentation. No conversations with mentors and judges. No photograph with the certificate. No team photograph. Just another event on a calendar that I decided I was too busy to attend. I’m glad I went. Not because Harvard is a magical place where all your problems disappear. It isn’t. And not because a certificate suddenly proves that you understand quantitative finance. It doesn’t. I am glad I went because I built something I cared about, put it in front of people who knew more than me, got challenged on it, learned from those conversations, and came home wanting to build more. That’s a much better outcome. Stanford → Cambridge → STRATUM</h1> The journey started with studying. It turned into an opportunity. The opportunity became a competition. The competition became a project. And the project became a deeper interest in quantitative finance. That’s probably the simplest way I can describe the whole experience. Stanford gave me the learning environment. Harvard gave me the arena to test it. STRATUM became the thing that connected the two. And somewhere between the mathematics, the models, the pipelines and the late nights, I realized that this is exactly the kind of work I want to keep doing. What’s next?</h2> STRATUM is not something I consider finished. There are plenty of things I want to explore further: Better time-series modeling</li> More rigorous backtesting</li> Improved uncertainty estimation</li> More advanced portfolio optimization</li> Stronger risk modeling</li> Better experiment tracking</li> More sophisticated ML architectures</li> Larger and cleaner datasets</li> More automated model evaluation</li> Better deployment and monitoring</li> </ul> The more I learn, the more obvious it becomes that there is no final version. There is only the next version. And that’s probably the part I enjoy most. Acknowledgements</h2> I’m grateful to Stanford for the learning and opportunity that led me here, to the Harvard Crimson team for organizing the Global Championship Round, and especially to my teammate for convincing me not to skip the trip when I was very close to doing exactly that. Sometimes the most important decision in a project is simply deciding to show up. I almost didn’t. I’m glad I did. STRATUM was just the beginning.

Rajnikant Dhar Dwivedi - Harvard

I Almost Didn't Go to Harvard. Then We Built STRATUM.