Rajnikant Dhar Dwivedi - Stanford

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.



How I Got Accepted into Stanford's AI & Deep Mathematics Research Program
2026-06-17T00:00:00+00:00
I’m going to be honest — when the email arrived on June 15 at 7:30 in the morning, I had just woken up. Still groggy, phone in hand, I almost scrolled past it. The subject line read: “Congratulations! You’ve been selected for the Stanford AI & Deep Mathematics Research Program.”</em> I read it three times before it actually registered.</p>
This post is for everyone who asked me “how?” — for every student from a small town who wondered if the big doors were actually open for them, and honestly, for myself. Writing this down makes it feel real.</p>

Where It All Started</h2>
I grew up in Siddharth Nagar, Uttar Pradesh. Not exactly a city people associate with Stanford. My parents aren’t researchers or professors — my father runs a small business, and my mother has always been my loudest supporter. Internet was patchy, opportunities were few, but curiosity was something nobody could take away from me.</p>
I got hooked on computers early. By the time I was 16, I was writing scripts to automate things at home just for fun. At 17, I cleared TCS CodeVita and landed a DevOps engineer role at TCS — something I never really shouted about, but it validated something deep inside me: the work was real, and I was capable of it.</p>

“If you’re from a place people have never heard of, your job isn’t to apologize for it. It’s to make them remember it.”</p>
</blockquote>
Fast forward: Chandigarh University for my B.Tech, the MIT Professional Education Applied Data Science Program, a HackMIT finalist badge, and winning the Qualcomm ArkLOL Hackathon 2025 as Lead Developer of Team Invincibles with our AI-powered AR education platform ArkEDU. Each of these built the profile — but more importantly, each of them built the conviction.</p>

Finding the Program</h2>
I first came across the Stanford AI & Deep Mathematics Research Program in late March 2026, deep in a research rabbit hole. I was reading about the mathematical foundations of neural networks — specifically geometric deep learning and how Riemannian manifolds show up in transformer architectures. One of the papers I found was co-authored by faculty running this exact program.</p>
The program runs July 1 through August 30, 2026, at Stanford University in California. It’s intensive: actual research, not coursework. The intersection of AI and deep mathematics was precisely what I had been gravitating toward in my own side projects.</p>
I almost didn’t apply. The imposter syndrome was loud that week. I texted Shikha about it. She said, in her characteristically no-nonsense way: “Apply first. Spiral later.”</em> So I did.</p>

The Application</h2>
The application had three main components: a statement of purpose, a technical portfolio, and two recommendation letters. There was also a short research proposal describing a problem you’d want to work on during the program.</p>
Statement of Purpose</h3>
I spent nearly two weeks on mine. The first draft was too formal, trying too hard to sound “Stanford-worthy.” My mentor read it and said it didn’t sound like me. So I scrapped it and started over — writing about the night I stayed up until 4 AM debugging an edge case in ArkEDU’s spatial mapping algorithm, and how that frustration turned into a genuine question about whether our mathematical tools for representing 3D space were even the right ones.</p>
Technical Portfolio</h3>
I submitted a curated selection: ArkEDU (Qualcomm Hackathon), HeroTrack — a full-stack AI productivity app built with React, TypeScript, Express.js, PostgreSQL, and GPT-4o — plus CTF and web security research, including my top-3 finish in the openECSC write-up competition.</p>
Research Proposal</h3>
“Towards Topology-Aware Attention: Applying Persistent Homology to Transformer Self-Attention Patterns.”</em> The core idea: attention heads seem to learn latent geometric structure that classical linear algebra doesn’t fully describe — and tools from algebraic topology might give us a better lens. Speculative, yes. But genuinely mine.</p>

  14</div>days writing the SOP</div></div>
  3</div>full drafts scrapped</div></div>
  ~40h</div>spent on the proposal</div></div>
  2</div>recommendation letters</div></div>
</div>

The Interview</h2>
About three weeks after submitting, I got a calendar invite for a 45-minute video interview with two faculty members.</p>
The interview was nothing like I expected. No quiz, no gotcha questions. The first 10 minutes were almost conversational. Then one faculty member pushed back hard on a claim I made about persistent homology being “computationally tractable” for large-scale transformers. He was right. Instead of crumbling, I acknowledged the gap, proposed a workaround involving approximation schemes, and said: “This is exactly why I want to be in a research environment — to stress-test ideas with people who can see the holes I can’t.”</em></p>

Knowing what you don’t know — and being unafraid of it — might be the most important thing you can demonstrate in a research interview.</p>
</blockquote>
They ended with a beautiful question: “If you could change one thing about how machine learning is currently taught, what would it be?”</em></p>
I said we teach optimization before intuition — we teach people to minimize loss functions before they understand what loss actually means in the real world. They smiled. That felt good.</p>

The Wait, and the Morning Everything Changed</h2>
Two and a half weeks of checking email compulsively. I kept working. Late-night calls with Shikha about everything except</em> Stanford, because talking about it too much felt like tempting fate.</p>
Then June 15 arrived.</p>

  Received — June 15, 2026  ·  7:30 AM</p>

Rajnikant Dhar Dwivedi - Stanford

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

How I Got Accepted into Stanford's AI & Deep Mathematics Research Program

The Application</h2> The application had three main components: a statement of purpose, a technical portfolio, and two recommendation letters. There was also a short research proposal describing a problem you’d want to work on during the program.</p>

The Application</h2>
The application had three main components: a statement of purpose, a technical portfolio, and two recommendation letters. There was also a short research proposal describing a problem you’d want to work on during the program.</p>