Skip to content
articles

article

The end of a development era. VECTOR.

Where I stopped, stood, and started to run.

published
23 August 2026
reading
5 min

I stopped today.§

Not because I wanted to, but because I was forced to. I was shackled. Chained down. Against my will. My oppressor was none other than my greatest ally since the past 1 month. Claude.

Let me take you aback. Last month, on the 23ʳᵈ of July, my father bought me calude code as his birthday gift to me. It was his birthday and he bought me a gift. Some world we live in 😅. The subscription was for Claude pro for one month. Enough to finish my school project: VECTOR lite and OVERKILL (graphing calculator). I did finish my school project. Along the way, I utilized the subscription, hitting every 5 hour session limit by making my website from scratch.

More recently (Since 2 days), I started fulfilling my true motive for Claude. Despite it helping me tremendously in the making of my website and Vector Lite and OVERKILL, I always, deep down felt that claude was meant to help in VECTOR development.

I tried it out (Getting Claude's help me testing and validation of VECTOR). The results? They shocked me to say the least.

Let me explain with a simple analogy.

I spent months of my time, and millions of credits developing the most high end Formula one car. The best suspension, DRS, Cockpit, body, everything. I built all that, but I used to test and audit it with my team and my team only, no external auditor. Thus, my team was biased, and gave me what I wanted to hear.

Claude on the other hand, had no clue that I owned the team. He came to my workshop, saw my car, tapped the body slightly with its foot and there appeared 20 cracks in the carbon, and 5 screws fell out.

Oh yeah, and not to mention, the engine, the one that costed millions of tokens, and weeks of effort, turned out to be that of an inline-four-cylinder which blows up even if there is a spec of dust within a 500 foot vicinity of it...

I realized that I had been measuring the wrong thing. I had been so wrapped around making VECTOR better than Alibaba CityMind and Miovision in terms of architecture and complexity (Modules, ML, AI, PREDICTION, and POWER), that I forgot what mattered the most. Validity. How it works in the real world. A system that is the most advance, powerful, and sound on paper, will almost never be that in the real world on the first try, nor the second, or third, or 300ᵗʰ time. It requires patience, time, and discipline. None of which I had. I was determined to transform EXTREMIS into VECTOR, the most powerful system, all within the time period of 1 year. I soon realized that this was impossible, based on the parameters that I had to operate in. I had limited storage, compute, and money. Which severely caused me to hallucinate (metaphorically not really lol).

To get more info on what went wrong and what we audited, go to the VECTOR tab.

But this article is dedicated to where we go now. What I am going to do after my exams are over.

After the exams are over, my roadmap exists as such:

  1. Reopen the battlefield Re-enter the repository from the verified forensic state. Reproduce the current results and vehicle-actuated baseline. Confirm what is working, broken, disconnected, or dormant. Fix foundational defects before adding new intelligence.
  2. Finish the control loop Verify the actuation semantics fix. Confirm actions produce the intended transient effects. Fix remaining timing, state, or action/effect attribution problems. Stress-test failures and abnormal conditions.
  3. Build the real data foundation Establish proper traffic datasets and pipelines. Define training, validation, and held-out data properly. Build repeatable dataset generation and versioning. Collect the data required for the forecasting stack.
  4. Train the intelligence

Start selectively:

Classical forecasting baselines LSTM/GRU Temporal Transformers GNN traffic models Other candidates only where experiments justify them Every model gets tested independently before it can influence control. 5. Start the model tournaments

Train → test → compare → reject/promote. Evaluate models on:

Prediction quality Different traffic regimes Uncertainty Latency Compute cost Robustness Some models will lose. That's fine. They get documented, not promoted. 6. Activate SENTRY / PREDATOR / APEX properly

Make the tiers empirically meaningful:

SENTRY: ordinary, predictable situations. PREDATOR: difficult or uncertain situations. APEX: extreme uncertainty, emergencies, anomalies, conflicting predictions, unusual network behavior, and situations requiring deeper reasoning. Then test whether adaptive escalation actually beats simply running the largest model everywhere. 7. Build PRE-INFERENCE

VECTOR should determine how difficult a situation is and how much computation it deserves using evidence such as uncertainty, model disagreement, novelty, regime changes, prediction error, consequences, available compute, and time constraints. The goal is adaptive intelligence, not maximum compute.

  1. Give APEX counterfactual reasoning

Move from:

“What is likely to happen?” to: “What happens if we do this?” Generate and compare possible futures for candidate actions. This is where world models, Monte Carlo, causal reasoning, and multi-fidelity simulation can start earning their complexity.

  1. Run serious adversarial testing

Try to break VECTOR:

Sensor failures Model failures Stale predictions Conflicting models Impossible states Extreme demand Emergencies OOD traffic Inference timeouts Simulation failures Bad actuation The intelligence should be allowed to fail. The safety layer shouldn't. 10. Re-run the benchmark honestly

Compare VECTOR against proper baselines across increasingly difficult scenarios. If VECTOR still loses: document it and find out why. If VECTOR wins: prove it. No benchmark gymnastics.

  1. Build the closed learning loop

Observe → Estimate → Predict → Act → Observe outcome → Compare prediction vs reality → Update belief. This is where VECTOR starts becoming genuinely adaptive rather than simply being an inference pipeline.

  1. Push toward real-world validation

Only after the simulation evidence is strong enough: Simulation → controlled testing → increasingly realistic environments → real-world validation. Never confuse simulation performance with real-world proof.

I am scared. I am nervous. There is no denying that. Not even in the slightest. This will cost a hefty sum of money, this will be tiring, there will be countless sleepless nights and countless 3am dev sessions.

Will I stop?

Absolutely not.

As I once said while fighting the Vercel and Resend demons at 1 am in the morning while making this very website:

We rawdoggin this shit.

-Vihaan Vaghela

No tracking pixels, no sharing, and one click to leave. Confirmation required.

state
active
build
6e6ee8b